LM> 1202…

MCC> 1202 Alarm…

LM> It’s a 1202.

MCC> Standby…

…

LM> Give us a reading of the 1202 program alarm

Asi, la interacción entre el centro de control de misión en Houston, y el módulo lunar del famoso Apollo 11, en 1969.

Nadie entendía qué era lo que estaba pasando, pero lo que estaba pasando era lo esperado en un sistema de misión crítica.

Recordé acerca de este incidente hace poco, mientras en el trabajo estabamos hablando sobre cómo debe de reaccionar el sistema operativo que estamos desarrollando cuando haya una falla de Hardware; puntualmente, una falla en el medio de almacenamiento persistente.

La alarma del programa 1202, en la computadora guía Apollo (AGC) era una decisión de diseño, a grandes rasgos, y explicando muy escueta y llanamente, la alarma indicaba que la memoria se había llenado de datos y que la computadora se estaba reiniciando. La computadora tenía una misión única, que era calcular la trayectoria de descenso para que el módulo lunar pudiera alunizar, asistiendo de información a los astronautas a bordo.

Reiniciando… remarco esto puntualmente… un reinicio en estos sistemas era lo más rápido para ejecutar para empezar a hacer calculos de nuevo con una memoria limpia y continuar procesando. Los sistemas de misión crítica siguen teniendo ésto en común.

En sistemas con un hardware reducido donde corres aplicaciones de tiempo real duro, toma mucho menos tiempo reiniciar el sistema que tratar de cubrir todos los escenarios que pudieran pasar para corregirlos al momento. Pensar en posibilidades puede llegar a ser peor el remedio que la enfermedad.

Los sistemas de misión crítica tienen que resistir a escenarios ambientales extremos, sin intervención humana, y en ejecución que puede durar décadas, hay que diseñar pensando en diferentes aristas y casos incluso extremos que no se ven en aplicaciones Cloud Native. Son sistemas que no tienen redundancia de Hardware, que no corren en centros de datos refrigerados y con sistemas anti incendios, por lo que considerar las potenciales fallas de ejecución correcta se ponen en la mesa de diseño desde el principio.

La forma en que lo resolvieron los programadores de Apollo, con la tecnología que tenían disponible en ese momento, fue brillante. Tan brillante, que se sigue usando actualmente en sistemas de este tipo de propósito.

Todo lo contrario con Tesla, donde han tenido que aprender a la mala.

Algunos tips rápidos que he aprendido

  • Reducir las operaciones de escritura persistente a lo mínimo imprescindible
  • Usar un sistema de archivos diseñado para explotar el tiempo de vida del sistema de almacenamiento
  • Poner el sistema de archivos en Sólo Lectura al primer error grave en el sistema de archivos, para evitar más escrituras subsecuentes y posible corrupción
  • Ejecutar un Pánico de Kernel cuando la falla es aún mayor
  • Tener un Watchdog con un temporizador corto para que se reinicie el sistema lo más rápido posible

Don Eyles fue aquel programador que tuvo la idea de la alarma 1202, escribió un libro con sus aventuras.

Sobre esto: