Incluso durante un desastre, siempre hay tiempo para una taza de té
DRP (plan de recuperación de desastres), una pieza que idealmente nunca necesita. Pero si de repente los castores que migran durante la temporada de apareamiento roen la fibra de la columna vertebral o el administrador junior abandona la base productiva, definitivamente querrá asegurarse de tener un plan prefabricado de qué hacer con todo este lío.
Mientras los clientes en pánico comienzan a cortar sus teléfonos de soporte técnico, el junior está buscando cianuro, usted abre sabiamente el sobre rojo y comienza 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.
- Pensaremos en una estructura conveniente de DRP
- Veamos cómo probarlo.
Para que empresas puede ser de utilidad
Es muy difícil trazar la línea cuando el departamento de TI comienza a necesitar estas cosas. Yo diría que está garantizado que necesitará DRP si:
- Detener el servidor, la aplicación o la pérdida de alguna base conducirá a pérdidas significativas de la empresa en su conjunto.
- Tiene un departamento de TI completo. En ese sentido, el departamento tiene la forma de una unidad completa de la empresa, con su propio presupuesto, y no solo unos pocos empleados cansados instalando la red, limpiando virus y cargando impresoras.
- Tiene un presupuesto realista para al menos un despido parcial en caso de emergencia.
Cuando el departamento de TI durante meses pide al menos un par de HDD para un servidor antiguo para copias de seguridad, es poco probable que pueda organizar una transferencia completa de un servicio caído a la capacidad de reserva. Aunque la documentación aquí no será superflua.
La documentación es importante
Comience con la documentación. Digamos que su servicio se basa en un script de 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 te dispararán inevitablemente no solo en la rodilla, sino también en otras extremidades, es más bien cuestión de tiempo.
Una vez que tenga una buena descripción de los componentes del servicio, suba las estadísticas de fallas. Es casi seguro que serán completamente típicos. Por ejemplo, tiene un disco lleno de vez en cuando, lo que provoca una falla en el nodo antes de que se limpie manualmente. O el servicio del 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 accidentes que nunca antes habían ocurrido, pero que potencialmente podrían acabar con su servicio por completo. Aquí solemos jugar a los villanos con nuestros compañeros. Toma mucho café y algo sabroso y enciérrate en una sala de reuniones. Solo asegúrate de que en la misma sala de reuniones encerraste a los ingenieros que ellos mismos plantearon el servicio objetivo o trabajan regularmente con él. Luego, ya sea en la pizarra o en el papel, comienzas a dibujar todos los posibles horrores que pueden ocurrirle a tu servicio. No es necesario detallar hasta un limpiador específico y desconectando cables, basta con considerar el escenario "Violación de la integridad de la red local".
Por lo general, las situaciones de emergencia más típicas se incluyen en los siguientes tipos:
- Falla de red
- Falla de los servicios del SO
- Fallo de la aplicación
- Fallo de hierro
- Fallo de virtualización
Simplemente revise cada vista y vea qué se aplica a su servicio. Por ejemplo, el demonio Nginx puede fallar y no subir; esto es una falla por parte del sistema operativo. Una situación poco común que inutiliza su aplicación web es una falla de software. Mientras se trabaja en esta etapa, es importante llegar a un diagnóstico del problema. Cómo distinguir una interfaz colgada en la virtualización de un tsiska caído y un bloqueo de red, por ejemplo. Es importante encontrar rápidamente a los responsables y empezar a tirar de su cola hasta que se solucione 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 más allá del rango normal. Por ejemplo:
- ¿Qué sucede si el tiempo en el nodo activo retrocede un minuto en relación con los demás en el clúster?
- ¿Y si el tiempo avanza, y si en 10 años?
- ¿Qué sucede si un nodo del clúster pierde repentinamente su red durante la sincronización?
- ¿Y qué pasará si dos nodos no comparten el liderazgo debido al aislamiento temporal entre sí en la red?
El enfoque inverso ayuda mucho en esta etapa. Tomas al miembro más terco del equipo con una imaginación enfermiza y le das la tarea de organizar un sabotaje lo antes posible, lo que acabará con 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 promete un banco de pruebas para esto, es muy bueno.
¿Qué es este DRP tuyo?
Entonces ha definido el modelo de amenazas. También tomaron en cuenta a los residentes locales que cortan cables de fibra óptica en busca de cobre, y al radar militar, que deja caer una línea de relevo de radio estrictamente los viernes a las 4:46 pm. Ahora necesitamos entender qué hacer con todo esto.
Su tarea es escribir los sobres muy rojos que se abrirán en caso de emergencia. Inmediatamente espere que cuando (¡no si!) Todo esté bien, solo el aprendiz más inexperto estará cerca, cuyas manos estarán temblando violentamente por el horror de lo que está sucediendo. Vea cómo se implementan las etiquetas 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 a su lado comienza a morir, muy a menudo todos se aferran impotentes a todo. Para ello, hay una instrucción clara en la pared con elementos como “abrir el paquete de esto” e “inyectar tantas unidades de la droga por vía intravenosa”.
¡Es difícil pensar en una emergencia! Debe haber instrucciones sencillas para analizar por médula espinal.
Un buen DRP consta de unos pocos bloques simples:
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
Recuerde que DRP comienza cuando el servicio ha fallado por completo y termina reconstruyéndose, incluso con una eficiencia reducida. Simplemente perder una reserva no debería activar DRP. También puede agregar una taza de té a DRP. Seriamente. Según las estadísticas, muchos accidentes desagradables se vuelven catastróficos debido al hecho de que el personal en pánico se apresura a arreglar algo, matando simultáneamente el único nodo vivo con datos o finalmente terminando el clúster. Por lo general, 5 minutos por una taza de té le darán algo de tiempo para calmarse y analizar lo que está sucediendo.
¡No confunda DRP y pasaporte del sistema! No lo sobrecargue con datos innecesarios. Simplemente haga posible el uso rápido y conveniente de hipervínculos para ir a la sección requerida de la documentación y leer en un formato extendido sobre las secciones necesarias de la arquitectura del servicio. Y en el propio DRP, solo 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 persona responsable pueda completar todos los puntos. En el momento más crucial, puede resultar que el ingeniero no tenga derechos de acceso al sistema requerido, no haya contraseñas para la cuenta requerida o no tenga idea de lo que significa "Conéctese a la consola de administración de servicios a través de un proxy en la oficina central". Cada punto debe ser extremadamente simple.
Incorrecto : "Vaya a la virtualización y reinicie el nodo muerto"
Correcto : "Conéctese a través de la interfaz web a virt.example.com, en la sección de nodos, reinicie el nodo que causa el error".
Evite la ambigüedad. Recuerda al interno asustado.
Asegúrese de probar DRP. Este no es solo un plan para completar, es uno que le permitirá a usted y a sus clientes salir rápidamente de una situación crítica. Es óptimo hacer esto varias veces:
- Un experto y varios aprendices trabajan en un banco de pruebas que simula un servicio real tanto como sea posible. El experto interrumpe el servicio de varias maneras y brinda a los aprendices la oportunidad de restaurarlo de acuerdo con el DRP. Se registran todos los problemas, ambigüedades en la documentación y errores. Después de capacitar a los aprendices, el DRP se complementa y simplifica en lugares oscuros.
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
