Incluso durante un desastre sempre hai tempo para unha cunca de té
DRP (plan de recuperación ante desastres) é algo que idealmente nunca será necesario. Pero se de súpeto os castores que migran durante a época de apareamento roen a fibra óptica da columna vertebral ou un administrador junior deixa caer a base produtiva, definitivamente queres estar seguro de que terás un plan predefinido sobre o que facer con toda esta desgraza.
Mentres os clientes aterrorizados comezan a cortar os teléfonos de soporte técnico, o júnior busca cianuro, abres sabiamente o sobre vermello e comezas a poñer todo en orde.
Neste post quero compartir recomendacións sobre como escribir un DRP e o que debe conter. Tamén veremos as seguintes cousas:
- Aprendamos a pensar como un vilán.
- Vexamos os beneficios dunha cunca de té durante o apocalipse.
- Pensemos nunha estrutura DRP conveniente
- A ver como probalo
Para que empresas pode ser útil isto?
É moi difícil trazar a liña cando o departamento de TI comeza a necesitar tales cousas. Eu diría que definitivamente necesitas DRP se:
- Parar un servidor, aplicación ou perder algunha base de datos levará a perdas importantes para o negocio no seu conxunto.
- Tes un departamento de TI completo. No sentido dun departamento en forma de unidade completa da empresa, con orzamento propio, e non só uns poucos empregados cansados colocando unha rede, limpando virus e enchendo impresoras.
- Ten un orzamento realista para polo menos un despedimento parcial en caso de emerxencia.
Cando o departamento de TI leva meses pedindo polo menos un par de discos duros para poñer nun servidor antigo para facer copias de seguridade, é improbable que poidas organizar un movemento completo do servizo fallido para reservar capacidade. Aínda que aquí a documentación non será superflua.
A documentación é importante
Comeza coa documentación. Digamos que o teu servizo funciona cun script Perl que foi escrito hai tres xeracións polos administradores, pero ninguén sabe como funciona. A débeda técnica acumulada e a falta de documentación inevitablemente dispararánche non só no xeonllo, senón tamén noutros membros, é máis cuestión de tempo.
Unha vez que teña unha boa descrición dos compoñentes do servizo, busque as estatísticas de accidentes. Case seguro que serán completamente típicos. Por exemplo, o disco está cheo de cando en vez, o que fai que o nodo falle ata que se limpe manualmente. Ou o servizo ao cliente non está dispoñible debido ao feito de que alguén se esqueceu de novo de renovar o certificado e Let's Encrypt non puido ou non quixo configuralo.
Pensamentos como un saboteador
A parte máis difícil é prever aqueles accidentes que nunca ocorreron antes, pero que poderían bloquear o teu servizo por completo. Aquí os meus compañeiros e máis eu adoitamos facer de viláns. Toma moito café e algo saboroso e encércate nunha sala de reunións. Só asegúrate de que nas mesmas negociacións bloquees aqueles enxeñeiros que eles mesmos desenvolveron o servizo de destino ou que traballan regularmente con el. Despois, xa sexa no encerado ou no papel, comezas a debuxar todos os posibles horrores que poidan ocorrer co teu servizo. Non é necesario entrar en detalles ata unha muller de limpeza específica e tirar cables; basta con considerar o escenario de "Violación da integridade da rede local".
Normalmente, as situacións de emerxencia máis típicas divídense nos seguintes tipos:
- Fallo da rede
- Fallo dos servizos do sistema operativo
- Fallo da aplicación
- Fallo de ferro
- Fallo de virtualización
Só tes que revisar cada tipo e ver o que se aplica ao teu servizo. Por exemplo, o daemon Nginx pode caer e non subir; isto significa fallos por parte do sistema operativo. Unha situación rara que fai que a súa aplicación web falle é unha falla de software. Mentres se traballa nesta fase, é importante elaborar o diagnóstico do problema. Como distinguir unha interface conxelada na virtualización dunha unidade cis caída e un accidente de rede, por exemplo. Isto é importante para atopar rapidamente aos responsables e comezar a tirar da cola ata que se resolva o accidente.
Despois de anotar os problemas típicos, botamos máis café e comezamos a considerar os escenarios máis estraños, cando algúns parámetros comezan a ir moito máis alá da norma. Por exemplo:
- Que ocorre se o tempo no nodo activo retrocede un minuto en relación aos demais do clúster?
- E se o tempo avanza, e se en 10 anos?
- Que ocorre se un nodo do clúster perde de súpeto a súa rede durante a sincronización?
- Que pasará se dous nodos non comparten o liderado debido ao illamento temporal entre si na rede?
Nesta fase, o enfoque inverso é moi útil. Colles ao membro máis teimudo do equipo cunha imaxinación enferma e encárgase de organizar no menor tempo posible unha sabotaxe que derrube o servizo. Se é difícil de diagnosticar, mellor aínda. Non creerás as ideas estrañas e xeniais que se lles ocorren aos enxeñeiros se lles dás unha idea para romper algo. E se lles prometes un banco de probas para iso, está absolutamente ben.
Cal é este teu DRP?!
Así que definiches o teu modelo de ameaza. Tamén tiveron en conta os veciños da zona que cortan cables de fibra óptica en busca de cobre, e un radar militar que deixa caer unha liña de relé de radio estritamente os venres ás 16:46. Agora temos que entender que facer con todo isto.
A súa tarefa é escribir eses sobres moi vermellos que se abrirán en caso de emerxencia. Agardar inmediatamente que cando (non se!) todo chegue ao seu fin, só estará preto o interno máis inexperto, cuxas mans tremerán violentamente polo horror do que está a suceder. Vexa como se implementan os sinais de emerxencia nos consultorios médicos. Por exemplo, que facer en caso de shock anafiláctico. O persoal médico coñece todos os protocolos de memoria, pero cando unha persoa cercana comeza a morrer, moitas veces todo o mundo está impotente agarrando todo o que está á vista. Para iso, hai instrucións claras na parede con elementos como "abrir o paquete de tal ou tal" e "administrar tantas unidades do medicamento por vía intravenosa".
É difícil pensar nunha emerxencia! Debe haber instrucións sinxelas para analizar a medula espiñal.
Un bo DRP consta de varios bloques sinxelos:
- A quen avisar sobre o inicio dun accidente. Isto é importante para paralelizar o proceso de eliminación na medida do posible.
- Como diagnosticar correctamente: realice un rastrexo, busque en systemctl status servicename e así por diante.
- Canto tempo podes pasar en cada etapa? Se non tes tempo para solucionalo manualmente dentro do tempo de SLA, a máquina virtual desaparece e retírase desde a copia de seguranza de onte.
- Como asegurarse de que o accidente rematou.
Lembra que o DRP comeza cando o servizo fallou completamente e remata cando se restablece o servizo, aínda que teña unha eficiencia reducida. Simplemente perder unha reserva non debería desencadear DRP. Tamén podes escribir unha cunca de té no DRP. En serio. Segundo as estatísticas, moitos accidentes pasan de desagradables a catastróficos debido ao feito de que o persoal se apresurou a arranxar algo, matando ao mesmo tempo o único nodo vivo con datos ou rematando finalmente o clúster. Como regra xeral, 5 minutos cunha cunca de té darache tempo para calmarte e analizar o que está a suceder.
Non confundas DRP e pasaporte do sistema. Non o sobrecargue con datos innecesarios. Só fai posible utilizar hipervínculos de forma rápida e cómoda para ir á sección desexada da documentación e ler nun formato ampliado sobre as seccións necesarias da arquitectura do servizo. E no propio DRP só hai instrucións directas sobre onde e como conectarse con comandos específicos para copiar e pegar.
Como probar correctamente
Asegúrese de que calquera empregado responsable poida completar todos os elementos. No momento máis crucial, pode resultar que o enxeñeiro non ten dereitos para acceder ao sistema requirido, non hai contrasinais para a conta requirida ou non ten idea de que "Conéctate á consola de xestión de servizos a través dun proxy no sede central” significa. Cada punto debe ser moi sinxelo.
Incorrecto - "Vaia á virtualización e reinicie o nodo morto"
Correctamente - "Conéctate a través da interface web a virt.example.com, na sección de nodos, reinicia o nodo que está a causar o erro".
Evita a ambigüidade. Lembra o interno asustado.
Asegúrese de probar DRP. Este non é só un plan para mostrar, é algo que permitirá a vostede e aos seus clientes saír rapidamente dunha situación crítica. É mellor facelo varias veces:
- Un experto e varios alumnos traballan nun banco de probas que simula o máximo posible un servizo real. O experto rompe o servizo de varias maneiras e permite aos alumnos restauralo segundo o DRP. Rexístranse todos os problemas, ambigüidades da documentación e erros. Despois de que os alumnos sexan adestrados, o DRP amplíase e simplifícase en áreas pouco claras.
- Proba nun servizo real. De feito, nunca podes crear unha copia perfecta dun servizo real. Polo tanto, un par de veces ao ano é necesario apagar de forma rutineira algúns dos servidores, cortar conexións e provocar outros desastres da lista de ameazas para poder avaliar o procedemento de recuperación. Un fallo planificado durante 10 minutos no medio da noite é mellor que un fallo repentino durante varias horas durante a máxima carga con perda de datos.
- Resolución de problemas real. Si, isto tamén forma parte das probas. Se se produce un accidente que non figuraba na lista de ameazas, é necesario complementar e finalizar o DRP en función dos resultados da súa investigación.
Puntos clave
- Se pode pasar unha merda, non só pasará, senón que o fará no escenario máis catastrófico posible.
- Asegúrate de ter recursos para a transferencia de carga de emerxencia.
- Asegúrate de ter copias de seguridade, créanse automaticamente e compróbase regularmente a súa coherencia.
- Pense en escenarios de ameaza típicos.
- Ofrécelle aos enxeñeiros a oportunidade de ofrecer opcións non estándar para ofrecer o servizo.
- DRP debe ser unha instrución sinxela e contundente. Todos os diagnósticos complexos realízanse só despois de que o servizo dos clientes foi restaurado. Aínda que a capacidade de reserva.
- Proporcione números de teléfono clave e contactos no DRP.
- Proba a comprensión dos empregados do DRP regularmente.
- Organizar accidentes planificados nos lugares de produción. Os soportes non poden substituír todo.
Fonte: www.habr.com