No hace mucho tiempo atrás sobre finales de agosto, United Airlines estuvo en la prensa y el análisis de casi todo el mundo.

¿El motivo? Una falla de hardware produjo que se cancelen 9 vuelos y se demoren 580 vuelos.

La explicación de United;

«La falla fue causada por un equipo de comunicaciones en uno de nuestros centros de datos y corto las comunicaciones en los aeropuertos con nuestro sitio web. Tenemos sistemas completamente redundantes y estamos trabajando con los proveedores para determinar porque el equipo de respaldo no funcionó como se suponía lo debería hacer«

Ayer fue el turno de Aerolíneas Argentinas;

Una falla técnica dejó sin vuelos a Aerolíneas y Austral

«El problema se dio por “la caída del sistema que rige los planes de vuelo de las aeronaves. Impidió la carga de combustible y la salida de los mismos”

Que no sea tú caso

Una cosa es tener los equipos y sistemas redundantes y otra muy diferente es que funcionen cuando se los necesita, United, Aerolíneas Argentina y muchas otras empresas lo están viviendo con un costo económico y de imagen cada vez más grande.

Acordate;

1. Simulación de funcionamiento del plan de continuidad de negocio.
   A diferencia de lo que estamos acostumbrados a realizar – pruebas planeadas con una frecuencia determinada – sorprende al proveedor con frecuencias al azar y que no tengan preparación alguna, será la única forma que no te engañen.
   Prueba de extremo a extremo, no solo la recuperación de los servicios del proveedor, también tus procesos.
2. Cuando estés por firmar el contrato, establece claramente;
   1. El punto en el tiempo al que deben recuperarse los datos (Recovery Point Objective).
      Acordar cual es la perdida de datos soportada por mi organización ante un incidente del proveedor.
   2. El tiempo en el que deben recuperarse los servicios (Recovery Time Objective).
      Este tiempo es el que nos debe evitar las consecuencias no deseadas de un incidente como le pasó a @Zynga, @BlackBerry o @United
   3. Pídele al proveedor de servicios su análisis de impactos y riesgos.
      Busca evidencias que el proveedor ha realizado el análisis de impacto y pide que te muestren las acciones de mitigación de riesgo, no te engañes cuando te hacen la recorrida por el magnífico centro de datos que tienen, pide las evidencias.
      Muchos centros de datos que operan en zonas propensas a terremotos, no lograron reaccionar hasta después de pasados 3 días del incidente.
   4. Acordar con el proveedor los tiempos de respuesta al incidente y en qué momento tendrán que declarar que hay que invocar el plan de recuperación.
      Recuerda que muchas veces los técnicos creen solucionar los problemas en minutos y, como en el caso de BlackBerry y muchos otros, ese tiempo son días.
      Creo que este es uno de los aspectos determinantes en muchos planes, no solo acordar el tiempo, sino quienes son las personas con responsabilidad y autoridad tanto en el proveedor como en tu organización de declarar la emergencia y disparar un plan de acción.