El documento del DRP es estrategia: qué recuperar, en qué orden, con qué RTO. Pero el día que arde, a las tres de la mañana, quien está de guardia no necesita estrategia —necesita instrucciones. Ese es el runbook: el paso a paso ejecutable, tan concreto que lo pueda correr alguien que no lo escribió, bajo presión y sin la persona que "sabe cómo va". Y al final del camino hay un movimiento que casi nadie planea: el regreso.
Qué hace bueno a un runbook
Un runbook no es prosa explicativa, es una receta a prueba de pánico. Los buenos comparten cinco cosas:
- Precondiciones claras: qué debe ser cierto antes de empezar (incidente contenido, respaldo verificado, autorización dada).
- Pasos numerados y atómicos: una acción por paso, sin "y luego configura todo lo demás". Si un paso necesita un comando o una ruta exacta, va escrito.
- Puntos de verificación: cómo saber que un paso funcionó antes de pasar al siguiente, no al final cuando ya es tarde para descubrir el error.
- Plan de reversa (rollback): qué hacer si un paso sale mal, para no quedar peor que al empezar.
- Contactos y escalamiento: a quién llamar cuando el runbook no alcanza.
La prueba de fuego es sencilla y cruel: ¿podría ejecutarlo alguien del equipo que no lo redactó, sin llamar al autor? Si la respuesta es no, no es un runbook, son notas personales.
Failover: pasar al sitio de recuperación
El failover es el movimiento que todo el mundo tiene en mente: pasar la operación del sitio primario caído al sitio de recuperación. Aquí es donde se juega el RTO, donde el tipo de DR site (hot, warm o cold) decide si son minutos u horas, y donde el runbook debe ser más impecable. Es la mitad que todos ensayan.
Failback: el paso que casi nadie planea
Y aquí está el hueco. Una vez que el sitio primario se reconstruye o vuelve a estar disponible, hay que regresar: eso es el failback. Suena trivial y no lo es, porque durante el desastre el negocio siguió operando en el DR site y generó datos nuevos —ventas, registros, transacciones. Regresar mal significa volver al primario con su estado viejo y perder todo lo que se hizo durante la contingencia. El failback tiene que ser ordenado: sincronizar de vuelta los datos generados en el sitio alterno, verificar integridad, elegir una ventana de baja actividad y solo entonces conmutar. Es, en cierto modo, un mini-failover en reversa —y merece su propio runbook, no una improvisación con el equipo ya agotado tras días de contingencia.
La pregunta que conviene hacerse
Dos preguntas, en realidad. Una: si la persona que más sabe está de vacaciones y sin señal, ¿alguien más puede recuperar con lo que está escrito? Y dos, la que casi nunca se hace: cuando el sitio primario vuelva, ¿tenemos escrito cómo regresar sin perder lo que el negocio generó durante el desastre? Si el plan se detiene en el failover y no dice nada del failback, está a medias. Escribir runbooks que cualquiera del equipo pueda ejecutar —ida y vuelta— y probarlos con simulacros antes de necesitarlos es parte de lo que hacemos. Porque el día que arde, la diferencia no la hace el plan más elegante, sino el que alguien puede seguir sin dudar.