Mesmo durante um desastre há sempre tempo para uma xícara de chá
DRP (plano de recuperação de desastres) é algo que idealmente nunca será necessário. Mas se de repente os castores migrando durante a época de acasalamento roerem a fibra óptica do backbone ou um administrador júnior abandonar a base produtiva, você definitivamente quer ter certeza de que terá um plano pré-elaborado sobre o que fazer com toda essa desgraça.
Enquanto os clientes em pânico começam a desligar os telefones do suporte técnico, o júnior procura cianeto, você abre sabiamente o envelope vermelho e começa a colocar tudo em ordem.
Neste post quero compartilhar recomendações sobre como escrever um DRP e o que ele deve conter. Também veremos o seguinte:
- Vamos aprender a pensar como um vilão.
- Vejamos os benefícios de uma xícara de chá durante o apocalipse.
- Vamos pensar em uma estrutura DRP conveniente
- Vamos ver como testá-lo
Para quais empresas isso pode ser útil?
É muito difícil definir limites quando o departamento de TI começa a precisar dessas coisas. Eu diria que você definitivamente precisa do DRP se:
- Parar um servidor, aplicação ou perder algum banco de dados acarretará perdas significativas para o negócio como um todo.
- Você tem um departamento de TI completo. No sentido de um departamento na forma de uma unidade completa da empresa, com orçamento próprio, e não apenas alguns funcionários cansados montando rede, limpando vírus e recarregando impressoras.
- Você tem um orçamento realista para redundância pelo menos parcial em caso de emergência.
Quando o departamento de TI implora há meses por pelo menos alguns HDDs em um servidor antigo para backups, é improvável que você consiga organizar uma mudança completa de um serviço com falha para reservar capacidade. Embora aqui a documentação não seja supérflua.
Documentação é importante
Comece com a documentação. Digamos que seu serviço seja executado em um script Perl escrito há três gerações por administradores, mas ninguém sabe como funciona. A dívida técnica acumulada e a falta de documentação vão inevitavelmente dar um tiro não só no joelho, mas também em outros membros, é mais uma questão de tempo.
Depois de ter uma boa descrição dos componentes do serviço, consulte as estatísticas de acidentes. É quase certo que serão completamente típicos. Por exemplo, seu disco fica cheio de tempos em tempos, o que faz com que o nó falhe até que seja limpo manualmente. Ou o serviço do cliente fica indisponível porque alguém novamente se esqueceu de renovar o certificado e o Let's Encrypt não conseguiu ou não quis configurar.
Pensamentos como um sabotador
A parte mais difícil é prever aqueles acidentes que nunca aconteceram antes, mas que podem travar completamente o seu serviço. Aqui meus colegas e eu costumamos interpretar vilões. Pegue muito café e algo gostoso e tranque-se em uma sala de reuniões. Apenas certifique-se de que, nas mesmas negociações, você inclua os engenheiros que desenvolveram o serviço de destino ou trabalham regularmente com ele. Aí, seja no quadro ou no papel, você começa a desenhar todos os possíveis horrores que podem acontecer ao seu serviço. Não é necessário entrar em detalhes sobre uma determinada faxineira e retirada de cabos, basta considerar o cenário de “Violação da integridade da rede local”.
Normalmente, as situações de emergência mais típicas se enquadram nos seguintes tipos:
- Falha na rede
- Falha nos serviços do sistema operacional
- Falha no aplicativo
- Falha de ferro
- Falha de virtualização
Basta passar por cada tipo e ver o que se aplica ao seu serviço. Por exemplo, o daemon Nginx pode cair e não subir - isso significa falhas no sistema operacional. Uma situação rara que causa falha em seu aplicativo da web é uma falha de software. Ao trabalhar nesta fase, é importante elaborar o diagnóstico do problema. Como distinguir uma interface congelada na virtualização de uma unidade cis caída e uma falha de rede, por exemplo. Isso é importante para encontrar rapidamente os responsáveis e começar a puxar o rabo até que o acidente seja resolvido.
Depois de anotados os problemas típicos, servimos mais café e começamos a considerar os cenários mais estranhos, quando alguns parâmetros começam a ir muito além do normal. Por exemplo:
- O que acontece se o tempo no nó ativo retroceder um minuto em relação aos outros no cluster?
- E se o tempo avançar, e se 10 anos?
- O que acontece se um nó de cluster perder repentinamente sua rede durante a sincronização?
- O que acontecerá se dois nós não compartilharem a liderança devido ao isolamento temporário um do outro na rede?
Nesta fase, a abordagem inversa é muito útil. Você pega o membro mais teimoso da equipe e com uma imaginação doentia e dá a ele a tarefa de organizar no menor tempo possível uma sabotagem que irá derrubar o serviço. Se for difícil de diagnosticar, melhor ainda. Você não vai acreditar nas ideias estranhas e legais que os engenheiros apresentam se lhes der a ideia de quebrar alguma coisa. E se você prometer a eles uma bancada de testes para isso, tudo bem.
O que é esse seu DRP?!
Então você definiu seu modelo de ameaça. Eles também levaram em consideração moradores locais que cortam cabos de fibra óptica em busca de cobre e um radar militar que desliga uma linha retransmissora de rádio estritamente às sextas-feiras às 16h46. Agora precisamos entender o que fazer com tudo isso.
Sua tarefa é escrever aqueles envelopes bem vermelhos que serão abertos em caso de emergência. Espere imediatamente que quando (não se!) tudo acabar, apenas o estagiário mais inexperiente estará por perto, cujas mãos tremerão violentamente de horror do que está acontecendo. Veja como a sinalização de emergência é implementada em consultórios médicos. Por exemplo, o que fazer em caso de choque anafilático. A equipe médica sabe de cor todos os protocolos, mas quando uma pessoa próxima começa a morrer, muitas vezes todos se agarram impotentes a tudo que está à vista. Para isso, há instruções claras na parede com itens como “abrir a embalagem de tal e tal” e “administrar tantas unidades do medicamento por via intravenosa”.
É difícil pensar em uma emergência! Deve haver instruções simples para análise da medula espinhal.
Um bom DRP consiste em vários blocos simples:
- Quem avisar sobre o início de um acidente. Isto é importante para paralelizar ao máximo o processo de eliminação.
- Como diagnosticar corretamente - execute um rastreamento, procure no systemctl status servicename e assim por diante.
- Quanto tempo você pode gastar em cada etapa? Se você não tiver tempo para corrigi-lo manualmente dentro do prazo do SLA, a máquina virtual será encerrada e revertida do backup de ontem.
- Como ter certeza de que o acidente acabou.
Lembre-se de que o DRP começa quando o serviço falha completamente e termina quando o serviço é restaurado, mesmo com eficiência reduzida. A simples perda de uma reserva não deve acionar o DRP. Você também pode escrever uma xícara de chá no DRP. Seriamente. De acordo com as estatísticas, muitos acidentes passam de desagradáveis a catastróficos devido ao fato de a equipe, em pânico, correr para consertar algo, matando simultaneamente o único nó vivo com dados ou finalmente acabando com o cluster. Via de regra, 5 minutos com uma xícara de chá lhe darão algum tempo para se acalmar e analisar o que está acontecendo.
Não confunda DRP e passaporte do sistema! Não o sobrecarregue com dados desnecessários. Basta possibilitar o uso de hiperlinks de forma rápida e conveniente para acessar a seção desejada da documentação e ler em formato expandido sobre as seções necessárias da arquitetura do serviço. E no próprio DRP existem apenas instruções diretas sobre onde e como conectar com comandos específicos para copiar e colar.
Como testar corretamente
Certifique-se de que qualquer funcionário responsável seja capaz de concluir todos os itens. No momento mais crucial, pode acontecer que o engenheiro não tenha direitos para acessar o sistema necessário, não haja senhas para a conta necessária ou ele não tenha ideia do que “Conecte-se ao console de gerenciamento de serviço por meio de um proxy no sede” significa. Cada ponto deve ser extremamente simples.
Errado — “Vá para a virtualização e reinicie o nó morto”
Corretamente - “Conecte-se através da interface web a virt.example.com, na seção de nós, reinicie o nó que está causando o erro.”
Evite ambiguidade. Lembre-se do estagiário assustado.
Certifique-se de testar o DRP. Este não é apenas um plano de exibição - é algo que permitirá que você e seus clientes saiam rapidamente de uma situação crítica. É melhor fazer isso várias vezes:
- Um especialista e vários estagiários trabalham em uma bancada de testes que simula ao máximo um serviço real. O perito interrompe o serviço de diversas formas e permite aos formandos restaurá-lo de acordo com o DRP. Todos os problemas, ambiguidades de documentação e erros são registrados. Depois que os trainees são treinados, o DRP é ampliado e simplificado em áreas pouco claras.
- Testando em um serviço real. Na verdade, você nunca poderá criar uma cópia perfeita de um serviço real. Portanto, algumas vezes por ano é necessário desligar rotineiramente alguns servidores, cortar conexões e causar outros desastres da lista de ameaças para avaliar a ordem de recuperação. Uma falha planejada de 10 minutos no meio da noite é melhor do que uma falha repentina de várias horas durante picos de carga com perda de dados.
- Solução de problemas reais. Sim, isso também faz parte do teste. Caso ocorra um acidente que não constava na lista de ameaças, é necessário complementar e finalizar o DRP com base nos resultados de sua investigação.
Pontos chave
- Se alguma merda puder acontecer, não só acontecerá, mas acontecerá no cenário mais catastrófico possível.
- Certifique-se de ter recursos para transferência emergencial de carga.
- Certifique-se de ter backups, eles são criados automaticamente e verificados regularmente quanto à consistência.
- Pense em cenários típicos de ameaças.
- Dê aos engenheiros a oportunidade de apresentar opções não padronizadas para a prestação do serviço.
- O DRP deve ser uma instrução simples e direta. Todos os diagnósticos complexos são realizados somente após a restauração do serviço dos clientes. Mesmo que na capacidade de reserva.
- Forneça os principais números de telefone e contatos no DRP.
- Teste regularmente a compreensão dos funcionários sobre o DRP.
- Organize acidentes planejados em locais de produção. Os estandes não podem substituir tudo.
Fonte: habr.com