El 26 de abril de 1986 se produjo una explosión que destruyó el reactor nuclear número 4 de tipo RBMK (Reaktor Bolshoy Moshchnosti Kanalnyy) en la central de Chernobyl. Recientemente, HBO ha puesto de moda el incidente con una miniserie. No voy a hacer aquí un spoiler de la serie ni a contar los hechos, ya que para eso es fácil recurrir a la página del accidente en Wikipedia o a libros como Midnight in Chernobyl o Chernobyl: The History of a Nuclear Catastrophe. Lo que voy explicar son los factores causantes de la catástrofe, aplicados como ejemplo al desarrollo de software, pero los principios subyacentes son los mismos para cualquier otra área de ingeniería.
Antes de empezar, conviene tener en cuenta el postulado fundamental de la teoría de desastres: si existe alguna posibilidad, por improbable que sea, de que suceda un desastre, entonces sucederá si se observa el sistema durante suficiente tiempo. Es por esto en parte que se ha paralizado en muchos países la construcción de centrales nucleares ya que, en el fondo, es imposible garantizar que nunca habrá ningún accidente.
No obstante lo anterior, hay formas de incrementar espectacularmente la probabilidad de un desastre, y voy a ellas.
Causa #1: La persona al mando no es quien debería ser.
La última palabra en decisiones operativas la tiene una persona que no comprende bien los fundamentos de la tecnología empleada. Además, está más preocupada por las implicaciones políticas del proyecto y por su propia carrera que por los daños que pudieren ser causados. También es posible que la persona responsable se encuentre demasiado cansada o ansiosa o distraída con otras cosas.
Causa #2: «Esto nunca ha pasado».
Otro principio aplicable a los desastres es que siempre son peores que el peor de los desastres anteriores. Hay dos razones posibles para ello, por la intensidad del suceso, o porque, en su ingenuidad, las personas a cargo piensan que el hecho de que algo no haya sucedido nunca en el pasado implica que nunca sucederá. Esto puede parecer un error de juicio muy tonto, pero, por ejemplo, existen emails de Mark Zuckerberg con el jefe de producto de Facebook en 2014 Sam Lessin en los que Zuckerberg cree imposible que suceda una fuga de datos como la que se produjo años después con el escándalo de Cambridge Analytica.
En general, soy escéptico de que haya tanto riesgo estratégico de fuga de datos como piensas. Estoy de acuerdo en que existe un claro riesgo en el lado del anunciante, pero no he descubierto cómo eso se conecta con el resto de la plataforma. Creo que filtramos información a los desarrolladores, pero no puedo pensar en ninguna instancia en la que los datos se hayan filtrado de un desarrollador a otro y nos hayan causado un problema real. ¿Tienes ejemplos de esto?
Causa #3: Las medidas de seguridad están por debajo del mínimo absoluto necesario.
En el caso de Chernobyl el edificio de contención estaba pésimamente fabricado con materiales de mala calidad. El tejado era débil y estaba fabricado con un material que no era ignífugo. Además faltaban barras de control en el núcleo del reactor.
En el caso de un proyecto software puede que la auditoría de seguridad contra intrusiones no se considere crítica o que nadie haya probado realmente a restaurar los backups.
Causa #4: Se ignoran pequeños defectos.
La investigación tras el desastre de Challenger en 1986 demostró que la causa de la explosión podía trazarse hasta unas juntas que no habían sido testeadas por debajo de 10 grados centígrados. Tanto la NASA cómo el proveedor de las juntas conocían el problema. Y los ingenieros advirtieron del peligro de programar el lanzamiento para un día de frío extraordinario.
En software, la dinámica es ignorar todo aquello que no está definitivamente roto. No se investigan los logs a menos que haya un reporte de error por parte de los usuarios. Se va posponiendo sine die el arreglo de partes potencialmente conflictivas. Los errores de redondeo y conversión de unidades han causado también algunos de los desastres de software más famosos.
Causa #5: Se presiona a los ingenieros para que se salten sus propios protocolos.
En el análisis de las causas del accidente fatal del vuelo 5022 de Spanair el 20 de agosto de 2008 se determinó que se produjo a una combinación de dos factores. Primero el sistema TOWS que alerta sobre la configuración inapropiada de los flaps estaba inoperante. El TOWS no es un sistema crítico (pequeño defecto). Además los pilotos omitieron la comprobación, probablemente porque el avión iba con más de una hora de retraso debido a un problema previo con la turbina de aire de impacto (RAT), otro pequeño defecto. El avión se estrelló porque intentó despegar con los flaps replegados.
Tras el accidente, y con los datos aportados por la CIAIAC, la Agencia Europea de Seguridad Aérea emitió la Directiva de Aeronavegabilidad AD 2008-0197, de fecha 29 de octubre de 2008, por la que se enmienda el manual de vuelo de los aviones del tipo DC-9 y MD, incorporando una comprobación obligatoria del TOWS antes del arranque de motores en cada vuelo.
En software, es tristemente habitual reducir o incluso prescindir de los tests. A veces doy una estimación de tiempo requerido y recibo la pregunta: «¿Y sin los unit tests cuanto tardarías?» ¡No! Idiota. Un entregable de software sin juego de pruebas es cómo un plato de bacalao con tomate, pero sin tomate y a veces incluso sin bacalao.
Causa #6: El sistema se somete a un stress inusual.
En el caso de Chernobyl la situación de stress fué que se decidió realizar una prueba tras un periodo en el cual la central había estado funcionando por debajo de su plena potencia, lo cual causa una acumulación indeseable de gas xenon y, además, de las treinta barras de control que el manual operativo del RBKM-1000 especificaba que debía haber cómo mínimo, habían sido retiradas todas menos seis.
En software las situaciones de stress se empiezan a producir aproximadamente cuando el sistema recibe una carga de trabajo que es 100 veces mayor de la normal. Aunque muchos sistemas fallan incluso antes con tan sólo 10 veces más carga de la normal.
Causa #7: Se acumula lentamente sobrecarga en el sistema.
Existe una página en Wikipedia con un listado de los puentes que se han caído desde 1800. En muchos casos el fallo estructural fué debido a una fatiga de materiales combinada con un peso puntual extraordinario sobre el puente (stress inusual).
En software es frecuente que las aplicación «pierdan» memoria con el paso del tiempo, y que se vaya agotando el espacio en disco o las conexiones disponibles contra la base de datos. Cuando se agota el pool de conexiones a la base datos todo el sistema deja de funcionar. Por separado, puede que todos los componentes estén bien: el servidor web, el servidor de aplicaciones y puede que hasta la propia base de datos, excepto porque no hay posibilidad de conectarse a ella.
Causa #8: Malentendidos y mala comunicación.
El peor accidente aéreo de toda la historia ocurrió el 27 de marzo de 1977 en el aeropuerto de Los Rodeos en Tenerife. Chocaron dos Boeing 747. El aeropuerto estaba saturado de tráfico debido a que un aviso de bomba en el aeropuerto de la cercana Gran Canaria había obligado a desviar vuelos a Los Rodeos. La causa fue que, en medio de una intensa niebla, el comandante de uno de los aviones estaba ansioso por despegar y recibió una comunicación: «you are clear» de la torre de control. Según las normas, el comandante debería haber esperado a recibir una segunda confirmación, pero sin esperarla se dirigió a la pista de despegue y aceleró encontrando en su camino al otro avión que iba camino de aparcar. Y hay otros muchos accidentes aéreos atribuidos a errores de comunicación: la colisión en pleno vuelo de Charkhi Dadri en 1996, el vuelo 152 de Garuda Indonesia Airlines en 1997, el vuelo 965 de American Airlines en 1995, el vuelo 182 de Pacific Southwest Airlines en 1978, el vuelo 1008 de Dan Air en 1980, el desastre en el aeropuerto de Linate en 2001, el vuelo 52 de Avianca en 1990.
En el desarrollo de software, creo que se pueden imputar más errores a especificaciones deficientes y mala comunicación que a ninguna otra causa singular. En 1962 hubo que destruir el cohete Mariner 1 con destino a Venus debido a que un programador implementó incorrectamente una fórmula matemática escrita a mano omitiendo una barra superior.
Que significa el enésimo valor suavizado de la derivada con respecto al tiempo de un radio R. Pero en la especificación del programa se omitió la función de suavizado que especifica la barra superior.
Causa #9: Se toman decisiones estúpidas fruto del pánico.
En Chernobyl el jefe de ingeniería envió dos ingenieros a que intentaran insertar manualmente las barras de control en el núcleo. Poco después de dar la orden se dió cuenta de que las barras ya eran en sí misma muy pesadas y si no estaban bajando por su propio peso sería inútil intentar empujarlas. Pero ya era demasiado tarde, los dos ingenieros recibieron una dosis letal de radiación y murieron pocos días después.
En software una buena parte de Black Monday del 19 de octubre de 1987 y el Flash Crash del 6 de mayo de 2010 se atribuyen a trading algorítmico operando en modo pánico.
Yo he presenciado en demasiadas ocasiones cómo se intentaba cambiar una versión de software de forma temeraria, o se apagaban sistemas de alerta y seguridad que impedían hacer algo o se introducían cambios no testeados para arreglar un bug crítico urgente que acabó siendo dóblemente crítico.
Causa #10: Se usan productos sin soporte del fabricante.
El caso más famoso de software no soportado es probablemente el bug que la CIA plantó en un software canadiense que los soviéticos estaban intentando adquirir cómo parte de un plan estratégico para hacerse con tecnología sensible estadounidense. El bug inducía premeditadamente un aumento de presión en un gaseoducto transiberiano y provocó en 1982 la mayor explosión no nuclear causada por el hombre en toda la historia.
