Space DevOps

Soyuz-TM drawing

Hace unos días, a raíz de un incidente en la Estación Espacial Internacional (ISS), decidí publicar algunas ideas relacionadas con el espacio y el desarrollo de software. Si alguien quiere usarlas en sus charlas públicas o privadas sobre DevOps y temas relacionados, tiene mi total bendición.

El contexto

A principios de junio de este año, se lanzó la misión Soyuz MS-09 desde el Roscosmos, con destino la ISS. Estas misiones se usan para enviar y recoger personas y cosas de la estación, por lo que se hacen de forma regular y muy programada. Es como un camión espacial de reparto de SEUR… si SEUR funcionase bien.

Esta misión completamente rutinaria envió la típica cápsula rusa Soyuz, construida en tierra, que quedó acoplada a la ISS como un habitáculo más.

Lo interesante del asunto es que hace unos días los sistemas de monitorización de la estación detectaron una bajada de la presión superior a la esperada. Siempre hay pérdidas, pero estas eran demasiado grandes, por lo que la tripulación buscó la fuga con un micrófono que tienen específicamente para esa labor (detecta el silbido que produce un escape de aire pequeño). Aunque todo el mundo esperaba encontrar el origen de la fuga en un micro meteorito (aka: Micro Meteoroid and Orbital Debris), resultó que el origen de la fuga era un tosco agujero de taladro.

A partir de ahí se generó un pequeño drama, donde nadie estaba libre de sospecha y cada declaración se veía como una acusación. Podría haber sido un astronauta desequilibrado, un saboteador americano a bordo, un sabotaje en las instalaciones de construcción de la Soyuz o que la los procesos de calidad rusos fuesen una mierda. Hasta la NASA estaba retirando de internet las fotos del agujero para evitar más problemas.

Por el momento todo apunta a que un técnico en tierra la cagó taladrando (y muy mal) donde no debería, tapó el agujero con pegamento permitiendo que pasase las pruebas de vacío en Tierra y que todo fuera bien. Lo que en efecto funcionó hasta casi 3 meses después, cuando el pegamento se deterioró y soltó, provocando la pérdida de aire en la estación.

Finalmente los rusos dijeron haber encontrado y despedido al responsable del fiasco, como no podía ser de otra manera, pero queda la duda de si los controles de calidad de las cápsulas son todo lo fiables que deberían o si esto se habrá producido más veces o habrá dejado elementos “parcheados” que puedan fallar en cualquier momento.

El paralelismo

La historia en sí me resulta interesante, no solo porque soy fan de las ciencias del espacio, sino porque como desarrollador de software veo un gran paralelismo entre este problema de la Soyuz MS-09 y un despliegue típico de software en una plataforma de producción.

Voy a reescribir el caso de la Soyuz en términos de un teórico proyecto de software para hacerlo más claro.

  1. El equipo de desarrollo tenía el sprint MS-09 para desplegar en junio en producción.
  2. Uno de los desarrolladores introduce un bug durante el sprint y en lugar de pedir ayuda o arreglar el problema correctamente, hace un apaño para pasar los tests introduciendo un segundo bug.
  3. Como nunca le dijo nada a nadie para evitarse problemas, quedar bien y no hay revisión de pull requests, nadie ve el segundo bug.
  4. Ese código llega a producción habiendo pasado los test y se despliega en el servidor ISS correctamente, pero pasados unos meses el equipo de operaciones empieza a recibir alertas en la monitorización.
  5. Comienzan creyendo que se trata un intento de hackeo o un fallo en la infraestructura, pero tras realizar un diagnóstico completo, encuentran el bug.
  6. Como no hay ramas para hotfix y un redespliegue ahora sería muy caro y complejo, los chicos de Operaciones del sistema en producción hacen modificaciones del código en caliente que durará unos cuantos meses, hasta el próximo despliegue programado y esperemos libre de apaños.
  7. Durante todo este tiempo, hay un cruce de acusaciones mútuas (finger-pointing de libro) entre personas dentro del propio equipo de Operaciones (“alguien ha roto algo y no he sido yo”, “te dije que tendríamos que…”), entre equipos (Operaciones Vs Desarrollo VS Management) y por supuesto un escalado a los proveedores de fuera de la casa (“han sido los de Kap-Geminy fijo”, “el becario…”).
  8. Finalmente revisando los datos (no las opiniones de los equipos), y los logs de builds y despliegues, se localiza el apaño del técnico en el historial de versiones del repositorio y se toman medidas disciplinarias.

Para reflexionar

¿Qué se hizo bien?

En el caso de la Soyuz, está claro que la monitorización fue clave para detectar el problema. También contar con herramientas de diagnóstico y gente preparada para usarlas y realizar un troubleshooting efectivo.

Por supuesto la comunicación es importante: ocultar un problema en producción no beneficia a nadie. Da igual si lo ha provocado tu compañero, coméntalo.

La documentación exahustiva obviamente es importante para saber cómo resolver ciertos issues y para seguir el problema hasta el origen real. En este caso se conocen todos los parámetros de todo lo que se sube a órbita.

Hay muchos otros temas como personal capacitado en el sitio para poder tocar las tripas del sistema, o la existencia procesos de gestión de problemas de varios niveles, que evitaron despertar a los astronautas por el escape simplemente porque al ritmo de la pérdida no lo convertía en algo urgente: tener gente descansada y no sacar el látigo al primer signo de problemas es bueno para todos, pero en particular para problemas complejos.

¿Qué podría mejorarse o cambiarse para evitar este tipo de problemas?

Aunque la NASA y la FKA (Agencia Espacial Rusa) tienen planes de contingencia para casi todo (este problema incluido), en ambos casos, tanto en el espacio como en el software, aumentar la frecuencia de lanzamientos es algo que mitigaría muchos problemas y reduciría riesgos. A esto en software lo llamamos CI/CD (integración y despliegue continuo), en la exploración aeroespacial eso se llama SpaceX.

Obviamente la NASA también lo sabe, porque canceló el sumidero de pasta que era el muy limitado Transbordador Espacial de Nixon, para meterla en la empresa de Elon Musk.

Y es que a veces se toman malas decisiones por razones de presupuesto, plazos, promesas y compromisos que cumplir. En software también pasa. Por eso es importante revisar nuestras decisiones regularmente y tratar de evitar tomar alguna que nos hipoteque durante mucho tiempo.

Mientras cambian del STS a SpaceX, los americanos cumplen con su parte de la ISS apoyándose en herramientas de terceros como las Soyuz y el Roscosmos.
En software también es crítico para el éxito el estar dispuesto abandonar herramientas y procesos obsoletos o desarrollados in-house lo antes posible y emplear algunas ajenas o incluso subcontratar, para mejorar nuestros procesos y resultados a medio y largo plazo.

Por último, el técnico de la Soyuz debería haber comunicado el problema y nada de esto habría pasado. No tengo ni idea de qué tipo de dinámica de trabajo tienen en la FKA, pero en general, si cada vez que alguien dice que hay un problema o que ha metido la pata, se le echa en cara, la dinámica va a ser la de no dar parte de los problemas, tapándolos hasta que suceda una desgracia.

Una sola “mala” persona en un puesto clave puede hacer mucho daño a la cultura del equipo. Pero usualmente el problema no es de una sola persona, sino del grupo o del contexto. Hay dinámicas muy complejas pero eso es algo más para comentar en un artículo sobre Hordas, en un libro de Zimbardo o en un documental de Ariely.
Dudo que el caso de la Soyuz sea este, pero en entornos de oficina (como el de software), en general, cuanto menos lucha de egos, finger-pointing y cuanto mejor sea la gestión de conflictos entre los individuos, mejor para todos.
El foco debe estar puesto, no en castigar a quien hizo qué, o en quedar bien para la próxima revisión salarial, sino en buscar formas de mejorar nuestros procesos y revisarlos regularmente y para eso una comunicación sana y efectiva es clave.
Y es que las personas cometemos errores, pero podemos evitar el efecto de muchos de ellos con algo de esfuerzo de todos.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s