Una de las cosas que me fastidia de mi trabajo son las notificaciones de incidencia que recibimos, indicando que tal o cual sistema no funciona: Exchange, Blackberries, Intranet, web publica, VPNs, etc. No por la incidencia en sí misma, si no porque todos los correos acaban con una frase del tipo: "Estamos investigando la causa raíz de la incidencia y ya daremos más detalles".

Tal notificación nunca se produce, y como usuario de esos servicios, se queda uno con la sensación de oscurantismo, de incertidumbre y un cierto grado de desconfianza hacia la gente que opera dichos servicios. Además, como ingeniero de sistemas, quiero saber qué ha fallado, cómo ha fallado y cómo se va a evitar que eso pase en el futuro.

Empresas tan importantes como Google o Amazon AWS hacen públicos análisis post mórtem con unos elevados niveles de detalle que permiten aprender alguna cosa que otra:

Estos informes son especialmente interesantes de cara a evaluar distintos proveedores de servicio: cuando contratas algo, deseas saber el grado de transparencia de la empresa que hay detrás, si son capaces de entender los servicios que ofrecen, su grado de madurez y experiencia operando los mismos y qué has de esperar de ellos cuando las cosas vayan mal. Por ejemplo:

Que no haya documentación clara de cómo tratar una incidencia o desastre.
Que esa documentación exista, pero no esté actualizada, sea incompleta o parcialmente incorrecta.
Que el personal que ha de tratar la incidencia no conozca al dedillo dicha documentación y se tenga que poner a buscarla y leerla en el momento.
Que, durante un cambio programado, no exista un guión detallado con los pasos a seguir.
Que dicho guión no se haya seguido correctamente porque la persona encargada llevaba trabajando 12h seguidas en un turno sin fin (O porque la noche anterior estuvo de guardia y le llamaron 4 veces).
Que un sistema que aporta "mejor disponibilidad" (HA, cluster, redundancia hardware, ...) no se pruebe suficientemente y no se active cuando lo deseamos.
Que si se activa, no lo haga en el tiempo que esperamos.
O que se active, pero haya otros elementos que fallen y haya una indisponibilidad de servicio.

Las posibilidades de fallo son tantas que hay toda una ciencia encargada de estudiar la resiliencia ó resistencia en infraestructuras IT: Resilience Engineering (parte 1) y parte 2 (ojo, el segundo enlace es bastante denso).

En otro post hablaré algo mas sobre resilience engineering... cuando tenga las ideas más claras :-)