Todos pecamos de prisas (yo incluído) y la información vino en tromba. He leído su explicación y te resumo la verdad, breve y sencilla. Hoy, 24 de julio, CrowdStrike publica un PIR (Preliminary Post Incident Review). Es decir, una revisión de un incidente para identificar las causas y planificar acciones.
Medio mundo parado por una excepción mal manejada
que salta de un fichero mínimamente incorrecto
que no se detecta por un bug en un "Content Validator"
que ha pasado unos tests que justamente no comprobaban lo que falló.
Ya, pero eso no sirve como excusa, porque no es un fallo que el efecto fuera algo muy raro, o que necesitara una interacción con otro software para funcionar. Es un software que tumba la maquina. Que menos que hacer una prueba que coja una maquina fresca, instale el software, y verifique que funciona. Yo trabajo en software critico desplegado en muchos millones de maquinas y siempre se puede colar un bug, nadie es perfecto, pero uno que haga que no funcione nada? Ahí faltan unos sanity checks básicos.
No me he leído todo el tocho, pero parece una excusa. Una cosa es que un parche fallé en una o dos máquinas, pero ¿que falle en muchas? Mínimamente tendría que tener unos cuantos ambiente de staging y producción para hacer pruebas en ambiente lo más cercanos a los reales.
Yo sin tener remotamente idea de lo que hablo, por un envío de linkedin, gran parte del problema fue hacer desarrollos en un sys fuera del kernel para evitar el proceso de certificación de dichas modificaciones. Metieron la pata y como no hubo una detección debido a esa falta de certificación, la liaron parda.
Si hay algún experto en la sala igual lo corrobora, matiza o dice q no tengo ni idea, lo cual sería cierto.
Esta muy arraigado en demasiados programadores ignorar los errores o como mucho conducirlos por el camino genérico de las excepciones. Estructuras tipo "try"+"except/catch" no ayudan.
¿Poco pudo hacerse? Si es lo que explica con intentar validar ese contenido erróneo en un entorno de pruebas antes de distribuirlo se tendría que haber detectado el problema.
Comentarios
Medio mundo parado por una excepción mal manejada
que salta de un fichero mínimamente incorrecto
que no se detecta por un bug en un "Content Validator"
que ha pasado unos tests que justamente no comprobaban lo que falló.
Ya, pero eso no sirve como excusa, porque no es un fallo que el efecto fuera algo muy raro, o que necesitara una interacción con otro software para funcionar. Es un software que tumba la maquina. Que menos que hacer una prueba que coja una maquina fresca, instale el software, y verifique que funciona. Yo trabajo en software critico desplegado en muchos millones de maquinas y siempre se puede colar un bug, nadie es perfecto, pero uno que haga que no funcione nada? Ahí faltan unos sanity checks básicos.
#2 Y una mínima atención a los clientes y revertir rápidamente en cuanto sepas del fallo. Si retiran la actualización rápidamente esto no pasa
No me he leído todo el tocho, pero parece una excusa. Una cosa es que un parche fallé en una o dos máquinas, pero ¿que falle en muchas? Mínimamente tendría que tener unos cuantos ambiente de staging y producción para hacer pruebas en ambiente lo más cercanos a los reales.
Edito: En Reddit lo explican mejor, y sí, parece que los tarados no hicieron suficientes pruebas https://www.reddit.com/r/crowdstrike/comments/1easbmf/preliminary_post_incident_review_pir_content/
Yo sin tener remotamente idea de lo que hablo, por un envío de linkedin, gran parte del problema fue hacer desarrollos en un sys fuera del kernel para evitar el proceso de certificación de dichas modificaciones. Metieron la pata y como no hubo una detección debido a esa falta de certificación, la liaron parda.
Si hay algún experto en la sala igual lo corrobora, matiza o dice q no tengo ni idea, lo cual sería cierto.
Esta muy arraigado en demasiados programadores ignorar los errores o como mucho conducirlos por el camino genérico de las excepciones. Estructuras tipo "try"+"except/catch" no ayudan.
¿Poco pudo hacerse? Si es lo que explica con intentar validar ese contenido erróneo en un entorno de pruebas antes de distribuirlo se tendría que haber detectado el problema.