Mesmo durante um desastre, sempre há tempo para uma xícara de chá
DRP (plano de recuperação de desastres) - um pedaço que idealmente nunca precisa. Mas se de repente os castores migrando durante a época de acasalamento roerem a fibra do backbone ou o administrador júnior perder a base produtiva, você definitivamente quer ter certeza de que terá um plano pré-feito do que fazer com essa bagunça.
Enquanto os clientes em pânico começam a desligar seus telefones de suporte técnico, o jovem está procurando por cianeto, você sabiamente abre o envelope vermelho e começa a colocar tudo em ordem.
Nesta postagem, 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 de DRP conveniente
- Vamos ver como fazer o teste.
Para quais empresas pode ser útil
É muito difícil estabelecer limites quando o departamento de TI começa a precisar dessas coisas. Eu diria que você precisa do DRP se:
- Parar um servidor, um aplicativo ou a perda de uma base resultará em uma perda significativa do negócio como um todo.
- Você tem um departamento de TI completo. No sentido de um departamento na forma de uma unidade de pleno direito da empresa, com orçamento próprio, e não apenas alguns funcionários cansados montando uma rede, limpando vírus e reabastecendo impressoras.
- Você tem um orçamento realista para, pelo menos, redundância parcial em caso de emergência.
Quando o departamento de TI por meses implora por pelo menos alguns HDDs para um servidor antigo para backups, é improvável que você consiga organizar uma transferência completa do serviço interrompido para reservar capacidade. Embora a documentação aqui não seja supérflua.
A documentação é importante
Comece com a documentação. Digamos que seu serviço seja baseado em um script Perl que foi escrito três gerações de administradores atrás, e ninguém sabe como funciona. O débito técnico acumulado e a falta de documentação vão inevitavelmente atirar 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 de serviço disponíveis, abra as estatísticas de falha. Eles quase certamente serão completamente típicos. Por exemplo, você tem um disco cheio de vez em quando, o que leva a uma falha do nó antes de ser limpo manualmente. Ou o serviço de cliente fica indisponível devido ao fato de que alguém novamente se esqueceu de renovar o certificado e o Let's Encrypt não pôde ou não quis configurá-lo.
Pensamentos como um sabotador
A parte mais difícil é prever acidentes que nunca aconteceram antes, mas que podem matar seu serviço completamente. Aqui costumamos brincar de vilão com os colegas. Pegue muito café e algo gostoso e se tranque em uma sala de reuniões. Apenas certifique-se de que na mesma sala de reunião você trancou os engenheiros que criaram o serviço desejado ou que trabalham regularmente com ele. Então, no quadro ou no papel, você começa a desenhar todos os horrores possíveis que podem acontecer ao seu serviço. Não é necessário detalhar para um limpador específico e puxar cabos, basta considerar o cenário “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 de serviços do sistema operacional
- Falha de aplicativo
- Falha de ferro
- Falha de virtualização
Basta percorrer cada visualização e ver o que se aplica ao seu serviço. Por exemplo, o daemon Nginx pode falhar e não subir - isso é uma falha por parte do sistema operacional. Uma situação rara que torna seu aplicativo da web inutilizável é uma falha de software. Ao trabalhar nesta fase, é importante elaborar o diagnóstico do problema. Como distinguir uma interface travada na virtualização de um tsiska caído e um travamento de rede, por exemplo. É importante encontrar rapidamente os responsáveis e começar a puxar pela cauda até que o acidente seja consertado.
Depois que os problemas típicos são anotados, servimos mais café e começamos a considerar os cenários mais estranhos quando alguns parâmetros começam a ir 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 em 10 anos?
- O que acontece se um nó de cluster perder repentinamente sua rede durante a sincronização?
- E o que acontecerá se dois nós não compartilharem a liderança devido ao isolamento temporário um do outro na rede?
A abordagem reversa ajuda muito nesta fase. Você pega o membro mais teimoso da equipe com uma imaginação doentia e dá a ele a tarefa de providenciar uma sabotagem no menor tempo possível, o que irá colocar o serviço fora do ar. Se for difícil diagnosticar, melhor ainda. Você não vai acreditar nas ideias estranhas e legais que os engenheiros apresentam se der a eles uma ideia para quebrar alguma coisa. E já se você prometer a eles uma bancada de teste para isso, é muito bom.
O que é esse seu DRP ?!
Então você definiu o modelo de ameaça. Também levaram em conta os moradores que cortam cabos de fibra ótica em busca de cobre e o radar militar, que desliga a linha de retransmissão de rádio estritamente às sextas-feiras às 16h46. Agora precisamos entender o que fazer com tudo isso.
Sua tarefa é escrever os envelopes muito vermelhos que serão abertos em uma emergência. Imediatamente espere que quando (não se!) Tudo estiver bem, apenas o estagiário mais inexperiente estará por perto, cujas mãos estarão tremendo violentamente de horror do que está acontecendo. Veja como os sinais de emergência são implementados em consultórios médicos. Por exemplo, o que fazer em caso de choque anafilático. A equipe médica conhece todos os protocolos de cor, mas quando uma pessoa próxima a ela começa a morrer, muitas vezes todos se agarram a tudo impotentemente. Para isso, há uma instrução clara na parede com itens como “abrir a embalagem disso” e “injetar tantas unidades do medicamento por via intravenosa”.
É difícil pensar em uma emergência! Deve haver instruções simples para analisar a medula espinhal.
Um bom DRP consiste em alguns blocos simples:
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
Lembre-se de que o DRP começa quando o serviço falhou completamente e termina sendo reconstruído, mesmo com eficiência reduzida. Simplesmente perder uma reserva não deve ativar o DRP. Você também pode adicionar uma xícara de chá ao DRP. Seriamente. Segundo as estatísticas, muitos acidentes desagradáveis tornam-se catastróficos devido ao fato de que a equipe em pânico corre para consertar algo, simultaneamente matando o único nó vivo com dados ou finalmente finalizando o cluster. Normalmente, 5 minutos para uma xícara de chá lhe dará 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. Apenas torne possível usar hiperlinks de forma rápida e conveniente para ir para a seção necessária da documentação e ler em um formato estendido sobre as seções necessárias da arquitetura de serviço. E no próprio DRP, existem apenas instruções diretas onde e como se conectar a comandos específicos para copiar e colar.
Como testar corretamente
Certifique-se de que qualquer pessoa responsável seja capaz de completar todos os pontos. No momento mais crucial, pode acontecer que o engenheiro não tenha direitos de acesso ao sistema necessário, não haja senhas para a conta exigida ou ele não tenha ideia do que significa "Conecte-se ao console de gerenciamento de serviço por meio de um proxy na matriz". Cada ponto deve ser extremamente simples.
Errado - "Vá para a virtualização e reinicie o nó morto"
Correto - "Conecte-se por meio da interface da web a virt.example.com, na seção de nós, reinicie o nó que causa o erro."
Evite ambigüidade. Lembre-se do estagiário assustado.
Certifique-se de testar o DRP. Este não é apenas um plano a ser assinalado - é aquele que permitirá que você e seus clientes saiam rapidamente de uma situação crítica. É ideal fazer isso várias vezes:
- Um especialista e vários estagiários trabalham em uma bancada de teste que simula um serviço real tanto quanto possível. O especialista quebra o serviço de várias maneiras e dá aos estagiários a oportunidade de restaurá-lo de acordo com o DRP. Todos os problemas, ambigüidades na documentação e erros são registrados. Após treinar os trainees, o DRP é complementado e simplificado em locais obscuros.
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
