Incluso durante un desastre siempre hay tiempo para una taza de té
DRP (plan de recuperación de desastres) es algo que idealmente nunca será necesario. Pero si de repente los castores que migran durante la temporada de apareamiento roen la fibra óptica de la columna vertebral o un administrador junior deja caer la base productiva, definitivamente querrás estar seguro de que tendrás un plan prefabricado sobre qué hacer con toda esta desgracia.
Mientras los clientes, presa del pánico, empiezan a cortar los teléfonos de soporte técnico, el joven busca cianuro, sabiamente abre el sobre rojo y empieza a poner todo en orden.
En esta publicación quiero compartir recomendaciones sobre cómo escribir un DRP y qué debe contener. También veremos las siguientes cosas:
- Aprendamos a pensar como un villano.
- Veamos los beneficios de una taza de té durante el apocalipsis.
- Pensemos en una estructura DRP conveniente
- Veamos cómo probarlo.
¿Para qué empresas podría ser útil esto?
Es muy difícil trazar el límite cuando el departamento de TI comienza a necesitar tales cosas. Yo diría que definitivamente necesitas DRP si:
- Detener un servidor, una aplicación o perder alguna base de datos provocará pérdidas importantes para la empresa en su conjunto.
- Tienes un departamento de TI completo. En el sentido de un departamento en forma de una unidad completa de la empresa, con su propio presupuesto, y no sólo unos pocos empleados cansados que tienden una red, limpian virus y recargan impresoras.
- Dispone de un presupuesto realista para un despido al menos parcial en caso de emergencia.
Cuando el departamento de TI ha estado pidiendo durante meses al menos un par de discos duros en un servidor antiguo para realizar copias de seguridad, es poco probable que pueda organizar un traslado completo de un servicio fallido para reservar capacidad. Aunque aquí la documentación no será superflua.
La documentación es importante
Comience con la documentación. Digamos que su servicio se ejecuta en un script Perl escrito hace tres generaciones por administradores, pero nadie sabe cómo funciona. La deuda técnica acumulada y la falta de documentación inevitablemente te dispararán no solo en la rodilla, sino también en otras extremidades, es más bien una cuestión de tiempo.
Una vez que tenga una buena descripción de los componentes del servicio, busque estadísticas de accidentes. Es casi seguro que serán completamente típicos. Por ejemplo, su disco se llena de vez en cuando, lo que hace que el nodo falle hasta que se limpia manualmente. O el servicio al cliente deja de estar disponible debido a que alguien nuevamente olvidó renovar el certificado y Let's Encrypt no pudo o no quiso configurarlo.
Pensamientos como un saboteador
La parte más difícil es predecir aquellos accidentes que nunca antes han ocurrido, pero que potencialmente podrían bloquear completamente su servicio. Aquí mis compañeros y yo solemos hacer de villanos. Toma mucho café y algo rico y enciérrate en una sala de reuniones. Solo asegúrese de incluir en las mismas negociaciones a aquellos ingenieros que desarrollaron ellos mismos el servicio objetivo o que trabajan regularmente con él. Luego, ya sea en la pizarra o en el papel, comienzas a dibujar todos los posibles horrores que podrían sucederle a tu servicio. No es necesario entrar en detalles sobre una señora de la limpieza específica y cómo sacar los cables, basta con considerar el escenario de "Violación de la integridad de la red local".
Normalmente, las situaciones de emergencia más típicas se clasifican en los siguientes tipos:
- Falla de red
- Fallo del servicio del sistema operativo
- Fallo de la aplicación
- falla del hierro
- Fallo de virtualización
Simplemente revise cada tipo y vea qué se aplica a su servicio. Por ejemplo, el demonio Nginx puede caer y no aumentar; esto significa fallas por parte del sistema operativo. Una situación poco común que hace que su aplicación web falle es una falla del software. Mientras se trabaja en esta etapa, es importante elaborar el diagnóstico del problema. Cómo distinguir una interfaz congelada en la virtualización de una unidad cis caída y una falla de red, por ejemplo. Esto es importante para encontrar rápidamente a los responsables y empezar a tirarles la cola hasta que se resuelva el accidente.
Después de anotar los problemas típicos, servimos más café y comenzamos a considerar los escenarios más extraños, cuando algunos parámetros comienzan a ir mucho más allá de la norma. Por ejemplo:
- ¿Qué sucede si el tiempo en el nodo activo retrocede un minuto en relación con otros en el clúster?
- ¿Y si el tiempo avanza, y si 10 años?
- ¿Qué sucede si un nodo del clúster pierde repentinamente su red durante la sincronización?
- ¿Qué pasará si dos nodos no comparten el liderazgo debido al aislamiento temporal de cada uno en la red?
En esta etapa, el enfoque inverso es muy útil. Coges al miembro más testarudo del equipo y con una imaginación enfermiza y le das la tarea de organizar en el menor tiempo posible un sabotaje que derribe el servicio. Si es difícil de diagnosticar, mejor aún. No creerás las ideas extrañas y geniales que se les ocurren a los ingenieros si les das una idea para romper algo. Y si les prometes un banco de pruebas para esto, está absolutamente bien.
¿Qué es ese DRP tuyo?
Entonces ha definido su modelo de amenaza. También se tuvieron en cuenta los residentes locales que cortan cables de fibra óptica en busca de cobre y un radar militar que deja caer una línea de retransmisión de radio estrictamente los viernes a las 16:46. Ahora necesitamos entender qué hacer con todo esto.
Tu tarea es escribir esos sobres rojos que se abrirán en caso de emergencia. Inmediatamente espere que cuando (¡no si!) todo llegue a su fin, solo el interno más inexperto estará cerca, cuyas manos temblarán violentamente por el horror de lo que está sucediendo. Vea cómo se implementan las señales de emergencia en los consultorios médicos. Por ejemplo, qué hacer en caso de shock anafiláctico. El personal médico se sabe todos los protocolos de memoria, pero cuando una persona cercana comienza a morir, muy a menudo todos se aferran impotentes a todo lo que ven. Para ello, hay instrucciones claras en la pared con ítems como “abrir el paquete de tal o cual” y “administrar tantas unidades del fármaco por vía intravenosa”.
¡Es difícil pensar en una emergencia! Debería haber instrucciones sencillas para el análisis de la médula espinal.
Un buen DRP consta de varios bloques sencillos:
- A quién avisar sobre el inicio de un accidente. Esto es importante para paralelizar al máximo el proceso de eliminación.
- Cómo diagnosticar correctamente: realice un seguimiento, busque en systemctl status servicename, etc.
- ¿Cuánto tiempo puedes dedicar a cada etapa? Si no tiene tiempo para solucionarlo manualmente dentro del tiempo del SLA, la máquina virtual se desactiva y se revierte desde la copia de seguridad de ayer.
- Cómo asegurarse de que el accidente haya terminado.
Recuerde que DRP comienza cuando el servicio ha fallado por completo y finaliza cuando se restablece el servicio, incluso con una eficiencia reducida. La simple pérdida de una reserva no debería activar DRP. También puedes escribir una taza de té en el DRP. En serio. Según las estadísticas, muchos accidentes pasan de desagradables a catastróficos debido al hecho de que el personal, presa del pánico, se apresura a arreglar algo, matando al mismo tiempo el único nodo vivo con datos o finalmente acabando con el clúster. Como regla general, 5 minutos con una taza de té te darán algo de tiempo para calmarte y analizar lo que está pasando.
¡No confunda DRP y pasaporte del sistema! No lo sobrecargues con datos innecesarios. Simplemente permita utilizar hipervínculos de forma rápida y cómoda para ir a la sección deseada de la documentación y leer en un formato ampliado las secciones necesarias de la arquitectura del servicio. Y en el propio DRP solo hay instrucciones directas sobre 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 pueda completar todos los elementos. En el momento más crucial, puede resultar que el ingeniero no tiene derechos para acceder al sistema requerido, no hay contraseñas para la cuenta requerida o no tiene idea de qué "Conéctese a la consola de administración de servicios a través de un proxy en el Sede central” significa. Cada punto debe ser extremadamente simple.
Неправилно — “Vaya a la virtualización y reinicie el nodo inactivo”
Derecho - “Conéctese a través de la interfaz web a virt.example.com, en la sección de nodos, reinicie el nodo que está causando el error”.
Evite la ambigüedad. Recuerda al interno asustado.
Asegúrese de probar DRP. Esto no es sólo un plan para mostrar, es algo que le permitirá a usted y a sus clientes salir rápidamente de una situación crítica. Lo mejor es hacer esto varias veces:
- Un experto y varios aprendices trabajan en un banco de pruebas que simula al máximo un servicio real. El experto interrumpe el servicio de varias maneras y permite a los alumnos restaurarlo de acuerdo con el DRP. Se registran todos los problemas, ambigüedades en la documentación y errores. Una vez capacitados los alumnos, el DRP se amplía y simplifica en áreas poco claras.
- Pruebas en un servicio real. De hecho, nunca podrás crear una copia perfecta de un servicio real. Por lo tanto, un par de veces al año es necesario apagar de forma rutinaria algunos de los servidores, cortar conexiones y provocar otros desastres de la lista de amenazas para poder evaluar el procedimiento de recuperación. Una falla planificada durante 10 minutos en medio de la noche es mejor que una falla repentina durante varias horas durante la carga máxima con pérdida de datos.
- Solución de problemas reales. Sí, esto también es parte de las pruebas. Si ocurre un accidente que no estaba en la lista de amenazas, es necesario complementar y finalizar el DRP con base en los resultados de su investigación.
Puntos clave
- Si algo puede pasar, no sólo sucederá, sino que lo hará en el escenario más catastrófico posible.
- Asegúrese de tener recursos para la transferencia de carga de emergencia.
- Asegúrese de tener copias de seguridad, se crean automáticamente y se verifica periódicamente su coherencia.
- Piense en escenarios de amenazas típicos.
- Brinde a los ingenieros la oportunidad de idear opciones no estándar para brindar el servicio.
- DRP debe ser una instrucción simple y contundente. Todos los diagnósticos complejos se llevan a cabo sólo después de que se haya restablecido el servicio de los clientes. Incluso si está en capacidad de reserva.
- Proporcione números de teléfono y contactos clave en el DRP.
- Pruebe periódicamente la comprensión de los empleados sobre el DRP.
- Organizar accidentes planificados en los sitios de producción. Los stands no pueden reemplazarlo todo.
Fuente: habr.com