🥇Preparando DRP — no olvide considerar un meteorito

Incluso en tiempos de catástrofe, siempre hay tiempo para una taza de té

DRP (plan de recuperación ante desastres) es algo que, en teoría, nunca debería ser necesario. Pero si, de repente, los castores en periodo de apareamiento cortan una fibra óptica principal o un junior admin derriba una base de datos en producción, definitivamente querrás asegurarte de tener un plan previamente elaborado sobre qué hacer con todo ese desorden.

Mientras los clientes, en pánico, comienzan a inundar a soporte técnico con llamadas, el junior busca cianuros, tú, con mirada sabia, abres el sobre rojo y comienzas a poner todo en orden.

En esta publicación, quiero compartir recomendaciones sobre cómo redactar un DRP y qué debería contener. Además, analizaremos las siguientes cosas:

Aprenderemos a pensar como un villano.
Analizaremos el beneficio de una taza de té durante el apocalipsis.
Pensaremos en una estructura cómoda para el DRP.
Veremos cómo debe ser testeado.

Para qué empresas puede ser útil.

Es muy complicado establecer un límite cuando el departamento de TI comienza a necesitar cosas como estas. Yo diría que necesitas un DRP garantizado si:

La detención del servidor, la aplicación o la pérdida de alguna base de datos causarán pérdidas significativas para el negocio en general.
Tienes un departamento de TI completo. Me refiero a un departamento como una unidad completa de la empresa, con su propio presupuesto, y no simplemente algunos empleados cansados, tendiendo redes, limpiando virus y reponiendo impresoras.
Tienes un presupuesto real, aunque sea solo para una parte de la reserva en caso de emergencia.

Cuando el departamento de TI lleva meses pidiendo al menos un par de discos duros en un servidor viejo para copias de seguridad, es poco probable que puedas organizar un traslado completo de un servicio caído a recursos de reserva. Aunque, incluso en este caso, la documentación no estará de más.

La documentación es importante.

Comienza con la documentación. Supongamos que tu servicio funciona con un script en Perl que fue escrito hace tres generaciones de administradores, y nadie sabe cómo funciona. La deuda técnica acumulada y la falta de documentación inevitablemente te dará problemas, no solo en la rodilla, sino en otras extremidades, es solo cuestión de tiempo.

Una vez que tenga una buena descripción de los componentes del servicio, revise las estadísticas de fallos. Casi con toda seguridad serán totalmente típicas. Por ejemplo, de vez en cuando se llena el disco, lo que provoca la caída del nodo hasta que se realice una limpieza manual. O el servicio al cliente se vuelve inaccesible porque alguien se olvidó de renovar el certificado, y no pudo o no quiso configurar Let’s Encrypt.

Piensa como un saboteador

La parte más complicada está en predecir aquellas averías que nunca han ocurrido, pero que potencialmente pueden derribar su servicio por completo. Aquí, normalmente, nos sentamos con mis colegas a hacer de villanos. Se toma mucho café y algo sabroso y se cierra en la sala de reuniones. Solo asegúrate de que en esa misma sala de reuniones estén encerrados aquellos ingenieros que levantaron el servicio objetivo o que trabajan regularmente con él. Luego, ya sea en la pizarra o en papel, comienzas a trazar todos los posibles horrores que pueden ocurrir con tu servicio. No es necesario detallar hasta una limpiadora específica y cables desconectados, es suficiente con considerar el escenario de “Violación de la integridad de la red local”.

Normalmente, la mayoría de las situaciones de emergencia típicas se agrupan en las siguientes categorías:

Fallo de red
Fallo de servicios del sistema operativo
Fallo de la aplicación
Fallo de hardware
Fallo de virtualización

Simplemente revisa cada tipo y observa cuáles son aplicables a tu servicio. Por ejemplo, puede que se caiga y no se levante el demonio Nginx, lo que se relaciona con fallos del sistema operativo. Una situación rara que pone tu aplicación web fuera de servicio es el fallo del software. Durante este proceso, es importante trabajar en la diagnostica del problema. Cómo distinguir una interfaz congelada en virtualización de un switch caído y una avería en la red, por ejemplo. Esto es crucial para encontrar rápidamente a los responsables y empezar a presionarlos, antes de que la emergencia se solucione.

Después de que se hayan registrado los problemas típicos, servimos más café y comenzamos a considerar los escenarios más extraños, cuando algunos parámetros comienzan a salir drásticamente de lo normal. Por ejemplo:

¿Qué sucederá si el tiempo en un nodo activo se retrasa un minuto respecto a otros en el clúster?
¿Y si el tiempo avanza, y si se retrasa 10 años?
¿Qué pasará si durante la sincronización un nodo del clúster pierde repentinamente la conexión a la red?
¿Qué pasará si dos nodos no comparten el liderazgo debido a un aislamiento temporal entre ellos por la red?

En esta etapa, es muy útil adoptar un enfoque inverso. Toma al miembro más obstinado del equipo con una imaginación desbordante y dale la tarea de causar una interrupción en el servicio en el menor tiempo posible. Si es difícil de diagnosticar, mejor aún. No creeras las ideas extrañas y geniales que surgen entre los ingenieros si se les da la idea de romper algo. Y si les prometes un banco de pruebas para hacerlo, mucho mejor.

¿Qué es eso de su DRP?

Entonces, has definido el modelo de amenaza. Has considerado a los lugareños que cortan los cables de fibra óptica en busca de cobre, así como un radar militar que derriba una línea de microondas estrictamente los viernes a las 16:46. Ahora debes entender qué hacer con todo esto.

Tu tarea es redactar esos famosos sobres rojos que se abrirán en caso de una emergencia. Desde ya, calcula que cuando (no si) todo se complica, solo estará a tu lado el becario más inexperto, que tendrá las manos temblorosas por el miedo a lo que está sucediendo. Observa cómo se implementan las señales de emergencia en las clínicas médicas. Por ejemplo, qué hacer en caso de un shock anafláctico. El personal médico conoce de memoria todos los protocolos, pero cuando alguien comienza a morir, a menudo todos buscan desesperadamente lo que puedan. Para eso, en la pared hay una instrucción clara con puntos como «abrir el paquete de tal» y «introducir intravenosamente tantas unidades del medicamento».

¡Es difícil pensar en una situación de emergencia! Deben haber instrucciones simples para procesar con el instinto.

Un buen DRP consiste en varios bloques simples:

A quién avisar sobre el inicio de la emergencia. Esto es importante para paralelizar al máximo el proceso de solución.
Cómo diagnosticar correctamente: hacemos un trazado, miramos en systemctl status servicename, y así sucesivamente.
Cuánto tiempo se puede gastar en cada etapa. Si no puedes repararlo a mano en el tiempo del SLA, la máquina virtual se elimina y se restaura desde la copia de seguridad de ayer.
Cómo asegurarse de que la emergencia ha finalizado.

Recuerde que el DRP comienza cuando el servicio ha fallado por completo y termina con la restauración de la operatividad, incluso si es con una eficiencia reducida. Simplemente perder la reserva no debería activar el DRP. Además, puede incluir en el DRP una taza de té. En serio. Según las estadísticas, muchos incidentes desagradables se convierten en catastróficos debido a que el personal, en pánico, intenta arreglar algo, lo que a menudo mata la única nodo viva con datos o termina por destruir el clúster. Generalmente, 5 minutos para una taza de té le darán un poco de tiempo para calmarse y analizar lo que está sucediendo.

No confunda el DRP con el pasaporte del sistema. No lo sobrecargue con datos innecesarios. Simplemente permita que la gente acceda rápida y cómodamente, a través de hipervínculos, a las secciones necesarias de la documentación y lea en un formato más amplio sobre las partes relevantes de la arquitectura del servicio. En el propio DRP, sólo debe haber indicaciones directas sobre a dónde y cómo conectarse con comandos específicos para copiar y pegar.

Cómo probar correctamente

Asegúrese de que cualquier empleado responsable esté capacitado para realizar todos los puntos. En el momento más crítico, podría ocurrir que el ingeniero no tenga acceso al sistema necesario, le falten las contraseñas de la cuenta necesaria o no tenga idea de lo que significa “Conéctese a la consola de gestión del servicio a través de un proxy en la oficina central”. Cada punto debe ser extremadamente claro.

Incorrecto — “Acceda a la virtualización y reinicie la nodo muerta”
Correcto: lo principal es encontrar un servidor dedicado realmente de calidad, cuyo costo no sea desproporcionado y cuyo nivel de fiabilidad, equipamiento y funcionalidad no decepcione. ¿Crees que se puede encontrar un servidor dedicado que sea al mismo tiempo barato y bueno? — “Conéctese a través de la interfaz web a virt.example.com, en la sección de nodos realice el reinicio de la nodo que está causando el error”.

No permita ambigüedades. Recuerde al pasante asustado.

Es esencial probar el DRP. No es solo un plan para cumplir; es lo que permitirá a usted y a sus clientes salir rápidamente de una situación crítica. Lo ideal es hacerlo varias veces:

Un experto y varios pasantes trabajan en un entorno de prueba que imita al máximo el servicio real. El experto daña el servicio de varias maneras y permite a los pasantes restaurarlo de acuerdo con el DRP. Se registran todos los problemas, ambigüedades en la documentación y errores. Tras la formación de los pasantes, el DRP se complementa y simplifica en los lugares que resultan confusos.
Pruebas en un servicio real. En realidad, nunca se puede crear una copia perfecta de un servicio auténtico. Por lo tanto, un par de veces al año es necesario apagar planificadamente parte de los servidores, cortar conexiones y provocar otros incidentes de la lista de amenazas para evaluar el proceso de recuperación. Es mejor un incidente planificado de 10 minutos en medio de la noche que una falla inesperada durante varias horas en pico de carga con pérdida de datos.
Resolución real de incidentes. Sí, eso también es parte de las pruebas. Si ocurre un incidente que no estaba en la lista de amenazas, es necesario complementar y revisar el DRP según los resultados de su investigación.

Puntos clave

Si algo puede salir mal, no solo saldrá mal, sino que lo hará de la manera más catastrófica posible.
Asegúrese de que tiene recursos para el desvío de carga en caso de emergencia.
Asegúrese de que tiene copias de seguridad, que se crean automáticamente y se verifican regularmente por consistencia.
Piense en los escenarios típicos de amenazas.
Permita que los ingenieros ideen opciones no típicas para caer el servicio.
El DRP debe ser una instrucción simple y clara. Todo diagnóstico complejo solo después de que el servicio de los clientes se haya restablecido. Aunque sea en capacidades de reserva.
Proporcione números de teléfonos y contactos clave en el DRP.
Pruebe regularmente a los empleados sobre su comprensión del DRP.
Realice incidentes planificados en producción. Los entornos de prueba no pueden reemplazar todo.