"Si bien esta anomalía se corrigió en vuelo, si no se hubiera corregido, habría provocado un disparo erróneo del propulsor y un movimiento incontrolado durante la separación SM por desorbita, con el potencial de una falla catastrófica de la nave espacial", dijo Paul Hill durante la reunión.
|
etiquetas: boeing , starliner , bugs , software
Bueno, la que se saldría, de la ruta sería la Starliner, no Boeing.
Yo la última vez me compré un BMW, vendiendo los diamantes que se crearon en mi culo por la presión.
Gente llevandose las manos a la cabeza con lo que es lo mas normal del mundo en ingenieria cuando tratas con sistemas complejos ¿Es una mierda? Si ¿Pasa? Tambien ¿Incluso cuando a priori has sido metodico y procedimental? Tambien
De hecho, que pienses que uno debe ser "metodico y procedimental" para evitar esos problemas es precisamente lo que provoca esos fallos.
Recomiendo que explores otras formas de trabajo, más orientadas a continuous delivery y reducir el riesgo de llevar algo a producción.
Move Fast Break things!
Como decia mi ex CTO "Everything fails all the time"
A ver quién bate esto.
No pienses que todo desarrollo se comporta igual que en tu sector (que puede ser verdad)
#12 #15
En teoría tampoco habría que hacer eso, haces un rollback a la anterior (que debería ser siempre posible), parcheas, pruebas en prepro, y redespliegas. Todo esto el viernes a las cinco, por supuesto.
Hay proyectos en los que no se puede permitir ni un solo fallo en producción, nunca. De lo que conozco, software médico. Pero el software de manejo de aviones espaciales también me parece que entra en la definición.
Por eso este tipo de empresas suelen tener un grupo de betatesters en nómina, al menos todas las que he conocido.
Los sistemas complejos solo son operables si resisten un estado de fallo parcial donde sus componentes puedan dejar de funcionar en cualquier momento/circustancia.
Durante una temporada de mi vida me trabaje justo en este tema. Si quieres leer sobre el sistemas complejos en el sector de aeronautica y medicina una referencia clasica: Drift into Failure [1]. Y sobre sistemas complejos y seguridad. Engineering a Safer World: Systems Thinking Applied to Safety [2] y Thinking in Systems: A Primer [3]
[1] www.amazon.com/Drift-into-Failure-Sidney-Dekker/dp/1409422216
[2] www.amazon.com/Engineering-Safer-World-Systems-Thinking/dp/0262533693
[3] www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557
Yo trabajé casi dos años como tester en la industria del videojuego. Me parece escandaloso que existan servicios vitales que no muestren a máxima preocupación a los errores en producción.
LLegados a cierta escala uno tiene que dejar de pensar en errores y pasarse a pensar en resilience. Por ejemplo, la vida media de un disco duro es de poco mas de tres años, dado el tamaño de AWS hay que medir la media de discos duros que fallan por minuto y pasarlo por distintos modelos estadisticos (AKA machine learning) para poder saber si existe una anomalia, de cualquier forma el sistema tiene que seguir funcionando al menos de una forma degradada.
Funtimes!