Mi error de 500 millones de dólares con un rover marciano

• En febrero de 2003, en una sala limpia del JPL, el Mars Rover Spirit estaba a dos semanas de ser trasladado al sitio de lanzamiento, y un solo error de conexión del break-out-box pudo haber arruinado una nave espacial de 500 millones de dólares
• Spirit y Opportunity eran una misión de rovers marcianos gemelos en la que la NASA había invertido casi 1,000 millones de dólares, y el cronograma dejaba muy poco margen para recuperarse de una falla importante
• Justo después de que un pulso eléctrico entrara hacia la nave espacial en vez de hacia el motor, se perdió la telemetría, pero no se pudo determinar de inmediato si había daños ni cuál era la causa
• Al día siguiente se confirmó que la pérdida de telemetría se debió a que se habían retirado las puntas de prueba de un multímetro Fluke 87III, mientras que el pico real quedó como objeto de análisis del canal del driver de motor H-Bridge
• Tras varias semanas de análisis, el proyecto determinó usar el hardware Use As Is, corrigió el procedimiento y siguió realizando la misma prueba; el motor correspondiente de Spirit funcionó con normalidad en Marte

---

El accidente de prueba en Spirit justo antes del lanzamiento

• En febrero de 2003, en la sala limpia Building 179 High Bay 1 del NASA JPL, el Mars Rover Spirit estaba a 2 semanas de ser trasladado a Cape Canaveral
• Spirit y Opportunity eran una misión de rovers marcianos gemelos, naves espaciales complejas en las que la NASA había invertido casi 1,000 millones de dólares en ese momento
• Durante la etapa de ensamblaje y pruebas, antes de cerrar la nave por última vez en la Tierra, había que probar a fondo todos los sistemas y confirmar que funcionaran correctamente
• Entre los dos rovers había un total de 62 motores brushed-type
  • Tracción y dirección de las ruedas
  • Control del brazo robótico
  • Apuntado de la cámara
  • Orientación de la antena hacia la Tierra
  • Despliegue y operaciones de apertura después del aterrizaje
• Esa noche, el objeto de la prueba era el motor RAT-Revolve dentro del Rock Abrasion Tool(RAT) en el extremo del brazo robótico de Spirit
  • El motor RAT-Revolve se encarga de hacer girar el grinder y el brush sobre las rocas marcianas

Procedimiento para verificar el estado del motor mediante señales eléctricas

• Después de cada prueba ambiental, no era práctico desarmar los motores para inspeccionar su interior
• En su lugar, se desconectaba el motor de la nave y se lo conectaba a una fuente de alimentación externa y a un strip chart recorder para verificar su desempeño eléctrico
• En un motor normal, la corriente durante el spin-up disminuye suavemente con forma exponencial; si hay una anomalía, aparece un blip en la señal
• En la prueba se usaba un break-out-box, y una conexión incorrecta podía enviar una gran corriente al lugar equivocado y causar daños catastróficos
• En la verificación previa, se confirmó que la interfaz de conexión, la configuración de la fuente de alimentación, la configuración del strip chart y un breve pulso de prueba sobre un motor de referencia estaban todos correctos

El pulso eléctrico que entró en la dirección equivocada

• En el momento de enviar energía al motor RAT-Revolve, el strip chart mostró una señal desconocida, distinta también de la señal típica de un motor averiado
• Al seguir el cableado, se confirmó que, por un error en el break-out-box, el pulso eléctrico había entrado hacia la nave espacial, es decir, en la dirección opuesta de la interfaz del conector, en vez de hacia el motor
• Spirit estaba a dos semanas de su traslado para preparar el lanzamiento, así que si surgía un problema grande no habría tiempo para recuperarse
• El accidente se informó de inmediato al conductor de pruebas Leo, y al mismo tiempo llegó la respuesta de que se había perdido la telemetría de la nave espacial
• El equipo ejecutó de inmediato el procedimiento de apagado de emergencia y recibió la orden de salir de la sala limpia para investigar lo ocurrido y evaluar los daños

Pérdida de telemetría y evaluación inicial

• Justo después del accidente se confirmaron dos hechos
  • Un gran pulso eléctrico había entrado en un lugar distinto al previsto
  • La telemetría de la nave espacial se había interrumpido
• La conexión entre ambos eventos no fue evidente de inmediato
• El equipo consideró probable que el pico eléctrico hubiera entrado en el circuito driver de motor H-Bridge
  • El H-Bridge se trataba como un circuito que controla el flujo eléctrico
  • Debido al back-EMF, era una de las partes del rover diseñadas para soportar energía adicional
• La nave espacial ya estaba apagada, y el equipo decidió verificar si volver a energizarla resolvía el problema
• Cerca de la medianoche, el reporte del accidente llegó incluso hasta el gerente de proyecto Pete, y estaba en juego la posibilidad de replanificar un proyecto de aproximadamente 1,000 personas

El reinicio fallido y la causa real descubierta al día siguiente

• Se volvió a ejecutar el procedimiento estándar de encendido de la nave espacial, pero aun después de que arrancaran la electrónica y el software, la telemetría no regresó
• En el rack de equipos de soporte en tierra había una luz indicadora roja que se encendía al recibir un pulso en cada ciclo de reloj, usada como una especie de latido robótico de 8 veces por segundo
• La fuente de alimentación mostró los pasos de voltaje y cambios de corriente familiares, pero la luz indicadora no se encendió y tampoco apareció la telemetría
• Al revisar nuevamente la secuencia de eventos al día siguiente, el multímetro digital Fluke 87III se convirtió en la pista clave
• Mientras se buscaba el multímetro necesario para la prueba del día anterior, se habían retirado las puntas de prueba de un multímetro que parecía estar monitoreando el voltaje de bus cerca de la nave espacial
  • En realidad, ese multímetro estaba completando el circuito de alimentación de la telemetría de pruebas en tierra de la nave espacial
  • En el momento en que se retiraron las puntas de prueba, se interrumpió la conexión de alimentación de la telemetría

Spirit estaba vivo, y el hardware se usó tal cual

• El equipo devolvió el multímetro a su función original y volvió a encender la nave espacial
• La telemetría volvió a la vida y se confirmó que Spirit no había muerto
• La pérdida real fue de solo unas horas, y las pruebas se reanudaron
• Durante las semanas siguientes se analizó el canal H-Bridge del motor RAT-Revolve, y continuaron discusiones detalladas sobre la posibilidad de thin-film demetallization
• Finalmente, el proyecto determinó usar ese hardware Use As Is
• La preparación del rover para el lanzamiento continuó, y después de que Spirit llegó a Marte, el motor RAT-Revolve funcionó con normalidad

Cómo lidiar con una experiencia de fracaso

• Este episodio llevó a la convicción de que compartir experiencias de fracaso puede ser una oportunidad de aprendizaje tanto para quien las cuenta como para quien las escucha
• En Planetary Resources, durante el proceso de contratación y en la cultura del equipo, se pedía a los candidatos que compartieran su propia failure story
• En medio de la crisis, Ernie dejó una frase: “La próxima vez que tengas que aprobar que algo está bien, recuerda esta sensación”
• Después del accidente, algunos pensaron que debían suspenderse las pruebas riesgosas, pero las pruebas continuaron por la importancia de verificar si el motor funcionaría correctamente en Marte
• El gerente de proyecto Pete decidió que la misma persona siguiera liderando la prueba, con el razonamiento de que “pagamos por su educación y él es la persona con menos probabilidades de volver a cometer este error”
• Luego se corrigió el procedimiento para que no se repitiera el mismo error, y la misma prueba se volvió a realizar varias veces
• Esta experiencia se convirtió en un punto de referencia que hacía recordar el miedo y el arrepentimiento de aquel momento al dar aprobaciones o garantías importantes

[GN⁺]

Comentarios de Hacker News

• El texto está realmente muy bien escrito
  Como ingeniero de software, todavía me acuerdo de algo parecido que me pasó al inicio de mi carrera. Hace unos 10 años, para un cliente de consultoría, pasé meses construyendo la nueva versión de un servicio web y el día del lanzamiento me encargué del despliegue; en ese entonces, el proceso de desarrollo y despliegue era casi totalmente manual. Automaticé lo posible con scripts y SQL, y justo cuando presioné Enter para hacer la última prueba antes del despliegue, me di cuenta de que acababa de cambiar a las credenciales de producción
  Cuando empezaron a acumularse errores y el servicio dejó de responder, me convencí de que había destruido la base de datos, pero por suerte unas horas antes alguien había terminado un respaldo por el lanzamiento y se pudo recuperar casi todo. Desde entonces, cuando trabajo con bases de datos y sistemas de producción, la palabra cuidado se queda corta, y me juré no volver a hacerlo

  • Nosotros también usamos una arquitectura de event sourcing, así que rara vez accedemos directamente a la base de datos de producción. Cuando hace falta, abrimos un túnel por medio de un bastion host con un script de shell y exponemos variables de entorno estándar para la configuración del cliente de Postgres
    La suite de pruebas elimina y vuelve a crear tablas, o las vacía, durante la ejecución. Un día, el desarrollador líder estuvo investigando un bug en la base de datos de producción y luego ejecutó make test. El código de pruebas siguió las variables de entorno tal como estaban y se conectó a producción en vez de Docker, y enseguida eliminó y recreó esas tablas de producción decenas de veces
  • Hace unos 10 años, en una consultoría donde trabajaba, un empleado interno encargado de otro producto inició sesión al mismo tiempo en la base de desarrollo y la de producción en ventanas distintas, y por error borró la base de datos de producción. Al intentar recuperarla descubrieron que los respaldos llevaban meses fallando, y así quedó claro por qué habían contratado consultores para ayudar con el nuevo producto
    Por suerte, cada sitio de cliente tenía una base local que se sincronizaba con la base central, así que el producto seguía funcionando aun con la conexión caída, y él pasó 3 o 4 días de jornadas largas reconstruyendo la base maestra con una combinación de un respaldo antiguo y datos de los clientes
  • Una vez ejecuté una migración contra la base de datos de producción desde Visual Studio. Viéndolo en retrospectiva, era algo recuperable, pero en el momento en que empecé a ver desaparecer todas las tablas en la vista de árbol de VS, sentí que se me paraba el corazón
    Un segundo después volvieron a aparecer; solo se había refrescado la vista. Era una UI realmente horrible
  • Hace unos 15 años, justo antes de un fin de semana largo, me estaba preparando para salir de la oficina cuando una colega de marketing, con quien me llevaba bien, pidió un cambio rápido en un sitio de cliente. Éramos una empresa pequeña, de unas 15 personas, y teníamos más clientes de los que podíamos manejar, así que yo tenía acceso a la base de datos de producción que no debería haber tenido
    Escribí un UPDATE corto para cambiar un texto de marketing del producto, y en el instante en que no terminó de inmediato supe que la había arruinado: había actualizado todo sin condición y cambié miles de descripciones de productos. El administrador de base de datos con acceso a los respaldos estaba en otra zona horaria y ya había salido, y después de más de una hora de llamadas por fin pudimos restaurarlo
    Lo que iba a ser un cambio rápido al salir terminó convirtiéndose en varias horas de contención. Mi amiga de marketing no dejaba de disculparse, pero el error fue mío. Creo que no escuchamos quejas de clientes porque eran las 5 de la tarde de un viernes antes de un fin de semana feriado
  • En un lugar donde trabajé hace unos 20 años, había una política de que, al ejecutar el comando sudo, otra persona debía revisar el comando antes de presionar Enter. Se puede aplicar una política o costumbre parecida a todo lo que se hace en producción

• Me vino a la mente la frase de que si un pasante borró la base de datos de producción, no es un mal pasante, sino un mal proceso
  No es tan fácil decidir si esto es un problema de proceso o de la persona, porque naturalmente se espera más de un empleado de tiempo completo, pero al ponerme en su lugar sentí el terror y el dolor del momento en que se dio cuenta de lo que había pasado. Incluso esa sensación de ver renacer una chispa de esperanza después del fracaso. Nunca he estado a cargo de un proyecto del que dependiera tanta gente
  Para mí, todos son héroes

  • En una gran firma bursátil, un script de pruebas tocó producción por accidente y creó operaciones de prueba de forex falsas por valor de varios millones de dólares
    En la llamada de postmortem, lo primero que se dijo fue: “No vamos a culpar a la persona que creó esas operaciones. Fue un error honesto. En cambio, hablemos de por qué un desarrollador podía golpear la API de transacciones de producción sin autenticación”
  • En este tipo de falla organizacional no se debe culpar al individuo. Aquí se ven dos problemas de proceso: si era posible conectar el enchufe al revés, entonces debió haberse hecho imposible desde el inicio, o al menos haberse identificado el riesgo y requerido que dos o más personas confirmaran la orientación; además, una herramienta como el multímetro en uso nunca debería poder separarse
    Si culpas a una persona, solo despides a esa persona y debilitas a toda la organización. Es como echar al único que aprendió una lección carísima. Solo hay que responsabilizar personalmente a alguien cuando hubo intención de hacer daño, y en ese caso puede intervenir la ley
  • En mi primer trabajo de desarrollo web después de salir de la escuela, tiré abajo el sitio web de producción desde el primer día. Afectó a decenas de miles de visitantes y detuvo todos los leads de ventas, pero lo levantamos de nuevo en pocos minutos y superé ese momento durísimo con todo el equipo y el CEO del cuarto de al lado mirando
    Años después, cuando ya estaba por irme, había convertido ese sitio frágil e inestable en un sistema con pruebas automatizadas, respaldos en varias etapas, failover entre varios centros de datos, capacitación para desarrolladores nuevos y onboarding. Eran los primeros tiempos de AWS, no la época en que un sitio de producción se desplegaba con un clic
    Gracias a esa experiencia aprendí sobre control de versiones adecuado, entornos de desarrollo, Redis, sharding y clustering, VM, replicación de Postgres y MySQL, wikis, monit, DNS, balanceadores de carga, proxies inversos y demás. Porque nunca más quería volver a tirar abajo un sitio
    Era una empresa pequeña que le pagaba 15 dólares la hora a un desertor de preparatoria con algo de experiencia en WordPress para encargarse de un sitio web de producción, pero después del error no me despidieron y me dieron la libertad y la confianza para aprender en el trabajo y mejorar el sistema. Todavía lo agradezco
  • Este caso es distinto. Era un rover único hecho a medida, que acababa de recibir su nombre, y ya existían toda clase de procesos, pero no se puede prever todo. Seguramente ajustaron el proceso después, pero también hay que recordar que para ellos era la primera vez
    Tener más reglas y mejores procesos no siempre es algo bueno. A veces la burocracia vuelve todavía más lenta a una NASA que ya de por sí es lenta. En misiones del tipo “primera de su clase”, a veces hay que depender de las personas y asumir riesgos, no del proceso
  • No puedo evitar pensar qué habría pasado si el rover realmente hubiera sido destruido. Parece que se salvó puramente por suerte, y bien podría haber quedado conectado a otro cable incorrecto sin circuito de protección
    Es decir, hubo partes decididas fuera de la capacidad del autor, y también existía la misma posibilidad de que quedara recordado para siempre como la persona que destruyó el rover, justo como temía

• Se relaciona mucho con mi propia experiencia. Solía elegir y hacerme cargo de los proyectos más difíciles y arriesgados en una gran aerolínea, y uno de ellos fue implementar rápidamente un nuevo proveedor de pagos para el sitio web. Ese sitio vendía boletos por millones de euros cada día
  Unos segundos después del despliegue, se nos pasó una diferencia entre el entorno de pruebas y el de producción, y quedó claro que una variable clave estaba vacía en producción. Era algo que se podría haber previsto si hubiera leído más documentación y me hubiera preparado mejor, así que cuando las ventas se detuvieron por completo sentí que se me paraba el corazón. Tras un largo procedimiento de rollback, las ventas estuvieron interrumpidas durante varias horas, llegaron clientes furiosos y hubo pérdidas de millones de euros
  Detuve al CEO en el elevador y le dije que era totalmente mi culpa y que aceptaría cualquier consecuencia, incluido el despido. Él se rió y respondió algo como: “¿Por qué te despediría? Acabamos de gastar millones en capacitarte. Hoy haces tu trabajo mejor que ayer”. Esta experiencia fue decisiva en muchos sentidos, incluido lo que es el verdadero liderazgo, y después completé con éxito muchos proyectos de alto riesgo

  • La redacción es demasiado correcta, y detalles como haber ido directamente con el CEO, o la combinación de “máximo rendimiento” con “la empresa perdió millones”, suenan un poco poco creíbles; da la impresión de que lo escribió un LLM o al menos de que está adornado
  • A menudo siento que las páginas para reservar vuelos están rotas más de la mitad del tiempo. No necesariamente hasta el punto de quedar en blanco por completo, pero sí lo bastante como para que no se pueda reservar un boleto, y casi prefiero una pantalla vacía. Así no pierdo 30 minutos
    Internet en general también falla seguido. En pleno pago de Black Friday falla la tienda web de Nike, y la solución de la mesa de ayuda es algo como “usa la app”
  • Puede que la pérdida no haya sido tan grande como parece. Si nadie pudo comprar boletos durante unas horas, en teoría se perdieron varios millones en ventas de ese lapso, pero eso supone que la gente no vuelve a intentarlo después
    En la práctica, no creo que el tiempo de caída se convierta directamente en pérdidas. En sus inicios, Twitter se caía seguido por su popularidad y su arquitectura, pero la gente no dejó de usar Twitter por eso
    En los servicios en línea, una caída no es necesariamente un desastre ni el fin de la empresa. Sería distinto con equipo espacial o con software de trading de alta frecuencia donde la empresa podría quebrar, y por eso debería haber controles más estrictos. En teoría, claro; en la práctica, a veces es peor que un servicio web CRUD mediocre hecho con supuestas mejores prácticas aprendidas en la industria espacial o de alta frecuencia
  • Si yo fuera responsable en una aerolínea, habría preferido una reacción más cercana al espíritu de un análisis posterior a un incidente aeronáutico. Debería ser una forma de encontrar y corregir las causas sistémicas
    En un despliegue a producción quizá hace falta alguien que revise en conjunto, como un copiloto, y que tenga autoridad para detener el rollout, además de las protecciones habituales de DevOps
  • Me recordó el viejo chiste que termina con “¿Por qué te despediría? ¡Si acabamos de gastar millones en capacitarte!”
    Quienes se encargan de proyectos de alto riesgo suelen estar subvalorados. Muchos gerentes prefieren a un empleado que de forma estable no genere ningún valor, antes que a uno con valor esperado positivo pero con volatilidad

• Trabajo en la industria de la TV. Hace 30 años, en mi primer empleo en una pequeña estación regional, me entrenaron como operador de cintas para el noticiero. Las cintas de emisión estaban apiladas en grandes montones y había cuatro VTR de reproducción. Mi trabajo era meter cada cinta y dejarla lista en el punto de preroll de 1 segundo
  Cuando terminaba la reproducción de una cinta y llegaba el momento de sacarla, era muy fácil presionar el botón de expulsión no del VTR que acababa de terminar, sino del VTR que estaba al aire en ese momento. La persona que me entrenaba hacía un gran sonido de advertencia, apretando los dientes e inhalando, cada vez que yo estiraba la mano hacia el botón de expulsión; ese ruido hacía que me detuviera y revisara dos y tres veces antes de sacar la cinta
  Era realmente molesto, pero sí servía para condicionarme a ser cuidadoso. La política de la estación era: la primera vez que sacabas una cinta durante una transmisión en vivo, te ibas un día a casa sin sueldo; la segunda, quedabas en periodo de prueba; la tercera, despido. Algunos colegas perdieron el trabajo y arruinaron noticieros por descuido crónico. Gracias a ese entrenador tan fastidioso aprendí el hábito de revisar y volver a revisar, y nunca saqué una cinta durante una transmisión

  • Eso explica por qué aquellas viejas recopilaciones de bloopers de TV tan populares a inicios de los 80 eran así. El reportero decía una cosa, pero el video de fondo mostraba una escena completamente distinta

• Estoy de acuerdo en que alguien que comete ese tipo de error no vuelve a cometer el mismo error. Por eso, despedir a alguien que cometió un error técnico y está claramente sufriendo por ello suele ser una mala decisión.
  Pero no creo que esa sea la lección “real”. Dado el costo y el riesgo, la lección es que a los componentes que se prueban con grandes sobrecargas de energía se les deben dar conectores de prueba dedicados que no sean compatibles con componentes propensos a echar humo.
  No era un pequeño proyecto de protoboard, sino un proyecto enorme hecho por muchísimas personas en una agencia gubernamental, donde los procedimientos formales consumen mucho tiempo y dinero, y a veces incluso reciben burlas. La lógica de “confiémosle a una persona de 28 años un robot de 500 millones de dólares que podría explotar si se equivoca” suena muy extraña

  • Es cierto que debería estar diseñado para que no se pudiera conectar mal. De hecho, supongo que en su mayor parte sí estaba diseñado así, pero aun en la etapa de diseño pueden aparecer configuraciones incorrectas que no se previeron.
    Sobre todo durante las pruebas, es común trabajar con cables, conectores y circuitos personalizados que son distintos de la “configuración normal”. Creo que la lección es realizar el trabajo importante, en la medida de lo posible, bajo el principio de cuatro ojos. Que una persona haga el trabajo y otra verifique cada paso antes de continuar es muy efectivo para detectar “errores absurdos” como el del artículo.
    Claro, por la presión del calendario y otros factores, no siempre se puede tener a dos personas observando una sola prueba, así que en la práctica este tipo de errores ocurre. Hay que hacer que todo el sistema sea robusto
  • Yo también pensé eso al principio. Pero si se trata de equipo de un solo uso que atraviesa un ciclo de prueba irrepetible, tomar esa decisión sí se vuelve difícil.
    En computación también hay muchas tareas parecidas que se hacen una sola vez como parte de una actualización o migración de una base de datos de producción o de la configuración de un router. A veces, el costo de crear una protección es mayor que simplemente tener cuidado desde el principio. No siempre podemos ser perfectamente cuidadosos, pero tampoco siempre podemos construir protecciones perfectas, y a veces confiamos en protecciones defectuosas y terminamos cometiendo errores similares.
    En la situación de la historia, quizá debería haber habido un compañero, como una versión de hardware del pair programming, cuya única tarea fuera verificar que todo lo que hacía el autor era correcto. No alguien de apoyo que ayudara dividiendo el trabajo, como Mary, sino una persona cuyo único deber fuera seguir y comprobar
  • Si lo lees con atención, la energía entró por los cables de salida de potencia del puente H, y como el puente H era un circuito electrónico robusto, al final no se dañó nada. El apagado no tuvo relación.
    Si hubiera entrado por la línea de datos del controlador del motor, es muy probable que algo se hubiera quemado. No se puede descartar si el tipo de conector era distinto, pero sí parece correcto que los dos conectores mal enlazados eran del mismo tipo
  • Cuando la humanidad aterrizó por primera vez en la Luna, la edad promedio de los ingenieros de Mission Control era de 28 años
  • Trabajo en esta industria, así que puedo explicar cómo pasan estas cosas. Incluso en proyectos caros, no se puede imponer conectores únicos en todas partes, porque los requisitos compiten entre sí.
    En particular, con los conectores ya suele haber muchos requisitos conservadores: productos ya certificados, cierto derating, separación entre pines, backshell con conexión a tierra, etc. Al final, solo se usan y se mantienen en inventario unas cuantas series de conectores, y no es realista lograr que nunca se solapen, sin importar cuánto dinero se gaste. Normalmente se intenta estandarizar la misma señal o hacerlos únicos para que no se superpongan.
    Por ejemplo, los conectores externos de una nave espacial necesitan ser de tipo hembra para evitar cortocircuitos durante la manipulación, y un arnés intermedio que nunca se retira podría tener conectores macho acoplados de forma simétrica. Entonces, cuando hace falta una caja de breakout para pruebas, aparece la posibilidad de conectarla al revés.
    O puede que un lado de la caja de breakout tenga un conector de 100 pines, y el otro deba conectarse a 25 equipos de prueba distintos. No existen 25 conectores distintos para elegir, y tampoco se pueden imponer requisitos personalizados a todos los equipos de prueba.
    Las naves espaciales están moviéndose cada vez más hacia microcontroladores locales y diagnósticos locales, así que este tipo de equipo de prueba para todas las señales analógicas se está usando menos. Además, hoy en día el motor probablemente sería brushless, y en vez de una caja de breakout así, se habría dependido de la telemetría remota del driver del motor durante las pruebas y el vuelo.
    Los conectores aeroespaciales también se están volviendo más configurables al momento del pedido, como en otras industrias, y se les puede añadir keying para que, aunque haya 10 conectores “iguales”, cada uno solo pueda conectarse en su lugar. Aun así, sigue siendo poco realista exigir que todo el equipo de prueba se configure de esa manera

• Para dejar constancia, agrego también mi historia. Mi primer trabajo después de graduarme de la universidad fue en una startup de content marketing que usaba PHP y PerconaDB (MySQL), y aunque no tenía mucha experiencia con PHP, sí tenía la confianza infundada típica de un junior. Como además pasé 6 meses sin conseguir trabajo después de graduarme, también tenía muchas ganas de dar una buena impresión.
  Me encargaron actualizar un feature flag para activar una nueva función para todos los clientes, excepto aquellos que quisieran dejarla desactivada explícitamente. El flag estaba guardado en la base de datos como los enteros 4 y 5 dentro de un arreglo de strings.
  Para hacer lo necesario usé la función de PHP array_reverse, pero como no leí la documentación, no sabía que si no se pasa el segundo argumento, invierte solo los valores y no las claves. Como resultado, arruiné la base de datos exactamente en el sentido opuesto a lo que se necesitaba, y de alguna manera pasó QA.
  Me di cuenta unas horas después, y en esa época tenía un trayecto de casi 3 horas por tramo, así que para entonces la gerencia ya estaba involucrada. Se podía arreglar fácilmente con un script inverso, pero salieron a la luz varios problemas, como QA y un fallo en la copia de seguridad de la base de datos.
  Todavía recuerdo, y agradezco, que al día siguiente el arquitecto líder vino a decirme que ese tipo de error con PHP era casi un rito de iniciación y que él también había cometido algo parecido al principio de su carrera. Al final me despidieron, y aunque me ayudó a crecer como ingeniero, en ese momento y durante las semanas siguientes sin duda me quitó mucho ánimo

  • ¿Te despidieron por ese error con array_reverse?

• La historia está escrita de forma atrapante, pero también resulta confusa.
  Parece que este equipo no cometió un solo error, sino varios. Tampoco queda claro si eso realmente pudo haber causado daños a la nave, o si solo desperdiciaron tiempo y generaron confusión tratando de averiguar por qué la nave no encendía.
  El primer error fue no darse cuenta de que el multímetro no solo estaba midiendo, sino que estaba completando el circuito. Suena como un diseño realmente malo, y si de verdad tenía que ser así, ese multímetro jamás debió tocarse. No fue el error de una sola persona, sino un problema que involucró al menos a dos personas, a quienes las supervisaban y a quien permitió un sistema así.
  El segundo error fue del lado de la caja de breakout. Reportaron que enviaron energía incorrectamente hacia la nave y, como la nave no encendió, concluyeron que una sobretensión había dañado la nave, pero en realidad no tenían certeza de por dónde había fluido ni qué se había dañado, y al final estaban equivocados.
  La razón por la que la nave no encendía fue que habían quitado el multímetro del circuito antes del accidente. La frase sobre las semanas de análisis del canal H-bridge del motor RAT-Revolve y la discusión sobre la posible desmetalización de película delgada sigue siendo confusa: no queda claro si querían decir que concluyeron que una sobretensión incorrecta pudo haber pasado por ese canal y haberlo dañado.

  • También faltó mencionar que Leo, el encargado de la telemetría, no informó la pérdida de telemetría hasta que le dijo al narrador que se había equivocado. ¿No deberían haber cancelado todas las pruebas hasta que volviera la telemetría?
  • La nave en sí sí encendió correctamente. Lo que pasó fue que no pudieron recibir información hasta restaurar ese circuito, porque el multímetro estaba conectando el circuito de telemetría.
    La energía sí entró realmente a ese circuito, y estaban intentando determinar si se había dañado. Aun así, consideraban que probablemente el driver del motor no se había dañado, porque debería poder soportar la energía que regresa desde el motor.

• Como ingeniero mecánico y aeroespacial, ojalá mis historias más aterradoras fueran del nivel de que la computadora principal de un rover no tripulado de 500 millones de dólares casi se convierte en un ladrillo.
  Yo era el senior que daba la aprobación de seguridad crítica para cosas que transportan vidas humanas. Tenía que cargar con la sensación de mirar fotos de piezas destrozadas después de un accidente y pensar: “¿Y si eso fue porque mis cálculos estaban mal?”, “¿Y si fue porque mi junta se deslizó?”, “¿Y si fue por un procedimiento de prueba inadecuado para tratar la predicción de vida a fatiga por aceleración o el agrietamiento por corrosión bajo tensión?”, “¿Y si fue porque apresuramos la entrada a producción y no lo detectamos antes del envío?”.
  Leer historias de fallas en campos parecidos es interesante, pero las historias que se comparten públicamente en HN me hacen pensar que el PTSD provocado por el trabajo no es una competencia. Para algunas personas, simplemente sale mucho más caro en terapia.

  • Me recordó una frase de una novela de un autor que me gusta. La dice un instructor de soldadura después de contar una anécdota bastante literal de análisis post mortem relacionada con inspecciones de seguridad falsificadas.

    He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

    “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

    He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
    -- Lois McMaster Bujold, Falling Free

  • Yo pensé lo mismo sobre el último párrafo. La parte del original que dice “vuelvo inmediatamente a ese momento — la habitación, la iluminación, la silla en la que estaba sentado, la mesa, la sensación de vacío en el estómago…” sonaba como una respuesta traumática.
    Qué bueno que haya podido canalizar esa energía hacia hacerlo mejor, pero no todo el mundo reacciona al trauma de la misma forma, y tampoco es fácil comparar esas reacciones. Por ejemplo, siento que hay demasiadas variables sociales como para usar eso como pregunta de contratación.
  • Me pregunto si esa sensación de mirar fotos de piezas destrozadas después de un accidente y pensar “¿Y si eso fue porque mis cálculos estaban mal?” es, al final, algo que inevitablemente le toca a alguien.
    Aunque haya sido un detalle que los procedimientos no pudieron detectar, alguien tiene la responsabilidad de crear buenos procedimientos. Puede haber muchos factores, pero al final parece que termina habiendo una persona bastante directamente responsable.
    Es interesante pensarlo en contextos donde los errores individuales terminan atribuyéndose al grupo, como en la ingeniería de software o en la sociedad en general.
  • De verdad espero que haya más gente como tú en la industria aeroespacial, y menos personas como quienes concibieron, implementaron y aprobaron el MCAS del Boeing 737 MAX.
  • Me sorprende que no exista terapia grupal para ingenieros, o que si existe sea tan difícil de encontrar. Yo no trabajo en un campo de alto riesgo, pero a menudo me toca escuchar a gente de aviación o ferrocarriles hablar de estas cosas.
    Si tienes empatía y no adoptas una actitud de “a dónde caiga el cohete después de despegar ya no es problema de mi departamento”, creo que puede ser bastante duro. Estaría bien que hubiera grupos de apoyo entre pares para la gente que construye sistemas críticos para la seguridad o que lidia con sus consecuencias. Las empresas no siempre ofrecen buena atención psicológica.
    Tal vez asociaciones de ingeniería u organizaciones de ingenieros certificados podrían ofrecer este tipo de servicio con las cuotas, pero también es posible que la gente evite usarlo por miedo a perder su licencia o certificación. Antes quizá uno se desahogaba emborrachándose con colegas en un bar, pero la dependencia del alcohol o llegar mal al trabajo al día siguiente no son buena idea, y la cultura de bar ya no es lo que era.

• Esto me recuerda al incidente del satélite NOAA-N Prime, que se cayó porque no había suficientes pernos para fijarlo al banco de pruebas.
  La causa de fondo, corríjanme si no es exacto, fue que los pernos para inspección por rayos X usados para asegurar el satélite eran demasiado caros, así que se los “prestaron” a otro proyecto y no los devolvieron. Cuando dieron vuelta el satélite para ponerlo en posición horizontal, cayó al suelo, y la reparación costó 135 millones de dólares.
  https://en.m.wikipedia.org/wiki/NOAA-19

  • Si al erratum o apéndice del procedimiento de volteo le agregan “verificar pernos”, ¿se permite un poquito de sarcasmo?

• Es interesante que este problema podría haberse evitado si desde el principio hubieran ordenado mejor cronológicamente los hechos. Si hubieran comparado la marca de tiempo de las lecturas de prueba con la última marca de tiempo del sistema de telemetría, habrían sabido que la telemetría ya había fallado antes de ejecutar la prueba.
  También fue parte de la causa no usar marcas de tiempo exactas y recurrir en cambio a expresiones imprecisas como “parece que hace un rato se cortó toda la telemetría de la nave”. La lección es que hay que verificar bien cómo se conectaron exactamente los eventos durante el accidente. Al ver dos señales distintas, uno asume con facilidad una causalidad en cierta dirección, pero en la realidad puede ser al revés.