Portada
mis comunidades
otras secciones
![Boeing corrigió un fallo de software de la Starliner un par de horas antes de la reentrada [ENG]](https://cdn.mnmstatic.net/cache/31/91/media_thumb_2x-link-3248634.jpeg?1581064686)
#3:
Un hotfix en producción implementado directamente en la rama main. Lo normal de toda la vida.
#2:
"Esto salió a la luz en la reunión del Aerospace Safety Advisory Panel (Comité Asesor de Seguridad Aeroespacial) de la NASA de ayer. Su presidenta habla de problemas sistémicos con el desarrollo de software en Boeing, no de fallos puntuales "
Wicho, de Microsiervos: https://twitter.com/wicho/status/1225693296032247808
Wicho, de Microsiervos: https://twitter.com/wicho/status/1225693296032247808
#6:
#3 #5 No he sufrido ningun arranque en productivo, ninguno (y ya van..) que no me haya tocado hacer esta mierda. Bola extra si es a las tantas de la mañana me sacan de cama porque algo está petando, se acaban de dar cuenta y hay que entrar a apagar el fuego.
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
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
#1:
Boeing está que se sale con los fallos en sus diseños.
Bueno, la que se saldría, de la ruta sería la Starliner, no Boeing.
Bueno, la que se saldría, de la ruta sería la Starliner, no Boeing.
Comentarios
Un hotfix en producción implementado directamente en la rama main. Lo normal de toda la vida.
#3 El que no lo haya hecho alguna vez no sabe lo que se pierde.
Yo la última vez me compré un BMW, vendiendo los diamantes que se crearon en mi culo por la presión.
#3 #5 No he sufrido ningun arranque en productivo, ninguno (y ya van..) que no me haya tocado hacer esta mierda. Bola extra si es a las tantas de la mañana me sacan de cama porque algo está petando, se acaban de dar cuenta y hay que entrar a apagar el fuego.
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
#6 Fallos en produccion es para llevarse las manos a la cabeza y que pase frecuentemente en tu entorno no significa que sea normal ni inevitable.
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.
#1 #3 #5 #6 #11 Boeing ha adoptado la mentalidad de Silicon Valley.
Move Fast Break things!
#11 No nos movemos en el mismo sector, en el mio un arranque es la puesta en marcha de 1 año de trabajo de desarrollo sobre un entorno cerrado lleno de modulos, interfases con otros sistemas y parametrizacion. Hay errores, los va a haber y es relativamente normal, gajes del oficio.
No pienses que todo desarrollo se comporta igual que en tu sector (que puede ser verdad)
#12 #15
#11 Pensar que CI/CD te va a salvar de que haya fallos en produccion deberia ser considerado un acto de fe.
Como decia mi ex CTO "Everything fails all the time"
#15 Espero que tu CTO no se dedicara a hacer software sensible.
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.
#32 Mi CTO era Werner Vogels responsable de Amazon Retail y Amazon Web Service .... yo diria que algo sensible si que era nuestro software.
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] https://www.amazon.com/Drift-into-Failure-Sidney-Dekker/dp/1409422216
[2] https://www.amazon.com/Engineering-Safer-World-Systems-Thinking/dp/0262533693
[3] https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557
#34 Qué cabrón. Por eso nos falla AWS
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.
#35 No falla, solo que funciona de forma degradada devolviendo un error 500
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!
#6 Hacen aviones, no páginas web. Y no, para hacer aviones no usas un "agile" ni tienes un "scrum master". Hay procesos muy serios de validación en cada paso. Este tipo de cosas no deberían pasar.
#5 Ba, eso es por la falta de costumbre. Yo lo hago todo el tiempo.
#3 Lo veo justificado si el error era importante. Cuando se cae producción primero se apaga el fuego y luego se hace un post-mortem
#7 Post Mortem y Boeing
#3 ¿Tu no has tenido que hacer eso nunca? Lo normal no es, pero es algo para lo que hay que estar preparado.
#9 Una vez en la que un evolutivo muy bien probado en preproducción falló en producción porque los entornos no eran exactamente idénticos.
#10 "¿En qué se va a diferenciar el Java x.y.z del Java x.y.z+1? ¡Si no hacemos nada raro!
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.
#3 ¿Existen mas ramas aparte de main?
#30 El PowerPoint del proyecto dice que si
"Esto salió a la luz en la reunión del Aerospace Safety Advisory Panel (Comité Asesor de Seguridad Aeroespacial) de la NASA de ayer. Su presidenta habla de problemas sistémicos con el desarrollo de software en Boeing, no de fallos puntuales "
Wicho, de Microsiervos:
Boeing está que se sale con los fallos en sus diseños.
Bueno, la que se saldría, de la ruta sería la Starliner, no Boeing.
#1 Yo les recomendaría que buscaran a los programadores de la voyager 2.
#14 https://www.popularmechanics.com/space/a17991/voyager-1-voyager-2-retiring-engineer/
#28 Mushas grasias.
Gensanta... no me montaba yo en eso ni jarto de vino.
Menos mal que la rama aeroespacial de Boeing era la buena...
Parchear en producción, the new frontier.
A ver quién bate esto.
#18 En producción y en caliente
#27 MUY caliente. Deadline: La atmósfera.
Boeing está quedando a la altura del betún
.
¡Esto sí que es desplegar en producción y lo demás son tonterías!
Qué tiempos aquellos del Apolo donde el software estaba en ROM y se lo probaba bien antes...
#17 El software estaba en un tejido de anillos de ferrita. Tejido a mano. La revisión era por pares, pero de señoras tejiendo.
#19 Sí... y el software se probaba en el simulador... ¿Me van a decir que no tienen simuladores ahora que puedan probar este software?
#17 Habia miedo a los rusos y no se escatimaba en recursos. Las cosas se hacian como dios manda. Ahora lo importante es sacar algo rapido y empezar a hacer pasta. Minimum Viable Product man! Y mejor si esta programado por Chandrupasiman Deniputaidea.
El mítico punto y coma.
Lo que se conoce en ingeniería del software como deadline
Real time live patching... love it