🥇Preparando o DRP — não se esqueça de considerar o meteoro

Mesmo em tempos de desastre, sempre há tempo para uma xícara de chá

DRP (plano de recuperação de desastres) é algo que idealmente nunca será necessário. Mas se, por acaso, castores em período de migração cortarem a fibra óptica principal ou um administrador júnior derrubar uma base de dados produtiva, você com certeza quer ter um plano pré-estabelecido sobre o que fazer com toda essa confusão.

Enquanto os clientes em pânico começam a inundar a central de atendimento, o júnior procura cianetos, você, com uma expressão sábia, abre 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 vamos discutir as seguintes questões:

Aprenderemos a pensar como um vilão.
Discutiremos a utilidade de uma xícara de chá durante o apocalipse.
Elaboraremos uma estrutura conveniente para o DRP
Veremos como ele deve ser testado

Para quais empresas isso pode ser útil

É muito difícil estabelecer limites quando o departamento de TI começa a precisar de tais coisas. Eu diria que você definitivamente precisa de um DRP se:

A parada de um servidor, aplicativo ou a perda de qualquer base resultará em perdas significativas para o negócio como um todo.
Você tem um departamento de TI completo. Quero dizer, um departamento que funcione como uma unidade completa da empresa, com seu próprio orçamento, e não apenas alguns funcionários cansados consertando a rede, limpando vírus e recarregando impressoras.
Você tem um orçamento real, pelo menos para um backup parcial em caso de emergência.

Quando o departamento de TI pede há meses pelo menos alguns HDDs para um servidor antigo para backups, é improvável que você consiga organizar uma realocação completa do serviço caído para as capacidades reserva. Embora mesmo nesse caso, a documentação não seja demais.

A documentação é importante

Comece com a documentação. Suponha que seu serviço funcione com um script em Perl, que foi escrito três gerações de administradores atrás, e ninguém sabe como ele funciona. A dívida técnica acumulada e a ausência de documentação inevitavelmente causarão problemas sérios, e não apenas no seu joelho, mas também em outros membros. É apenas uma questão de tempo.

Depois de ter uma boa descrição dos componentes do serviço em mãos, analise as estatísticas de falhas. Quase com certeza, serão totalmente típicas. Por exemplo, de vez em quando, o disco se enche, levando à falha do nó até que seja limpo manualmente. Ou o serviço ao cliente fica inacessível porque alguém esqueceu novamente de renovar o certificado, e não conseguiu ou não quis configurar o Let’s Encrypt.

Pense como um sabotador

A parte mais difícil é prever aquelas falhas que nunca ocorreram, mas que potencialmente podem derrubar completamente seu serviço. Aqui, normalmente, eu e meus colegas fazemos um jogo de vilões. Pegue muito café e algo gostoso e se trancafie na sala de reuniões. Apenas certifique-se de que, nessa mesma sala, você trancou os engenheiros que levantaram o serviço-alvo ou que trabalham regularmente com ele. Em seguida, seja no quadro branco ou em papel, comece a desenhar todos os possíveis horrores que podem acontecer com seu serviço. Não é necessário detalhar até a faxineira específica e o puxão de cabos, basta considerar o cenário de “Violação da integridade da rede local”.

Normalmente, a maioria das situações de falha típicas se encaixa nas seguintes categorias:

Falha de rede
Falha dos serviços do sistema operacional
Falha do aplicativo
Falha de hardware
Falha de virtualização

Simplesmente passe por cada tipo e veja o que se aplica ao seu serviço. Por exemplo, o daemon do Nginx pode cair e não reiniciar – isso se refere a falhas do sistema operacional. Uma situação rara que coloca seu aplicativo web fora de operação é uma falha de software. Ao trabalhar nesta etapa, é importante desenvolver o diagnóstico do problema. Como distinguir uma interface travada na virtualização de uma falha de equipamento e uma falha na rede, por exemplo. Isso é importante para encontrar rapidamente os responsáveis e começar a puxá-los para resolver a situação antes que a falha seja corrigida.

Depois que os problemas típicos estão anotados, sirva mais café e comece a considerar os cenários mais estranhos, quando alguns parâmetros começam a sair muito do normal. Por exemplo:

O que acontece se o tempo em um nó ativo for ajustado um minuto para trás em relação aos outros do cluster?
E se o tempo for ajustado para frente, e se for por 10 anos?
O que acontecerá se, durante a sincronização, um nó do cluster perder a rede repentinamente?
E o que acontece se dois nós não chegarem a um acordo sobre a liderança devido à isolamento temporário na rede?

Nesta fase, uma abordagem reversa é muito útil. Pegue o membro mais obstinado da equipe, com uma imaginação fervorosa, e dê a ele a tarefa de organizar uma sabotagem que derrube o serviço em um curto espaço de tempo. Se for difícil diagnosticar, ainda melhor. Você não vai acreditar em quão estranhas e criativas são as ideias que os engenheiros têm quando recebem a missão de quebrar algo. E se prometer um ambiente de testes para isso — ainda melhor.

O que é esse seu DRP?!

Então você definiu o modelo de ameaças. Levou em consideração os moradores locais que cortam cabos de fibra óptica em busca de cobre, e o radar militar que derruba a linha de micro-ondas todas as sextas-feiras às 16h46. Agora, você precisa entender o que fazer com tudo isso.

Sua tarefa é escrever aqueles envelopes vermelhos que serão abertos em situações de emergência. Prepare-se para o fato de que quando (não se!) tudo der errado, a única pessoa ao seu lado será o estagiário mais inexperiente, com as mãos tremendo de medo. Veja como são implementadas as placas de emergência em consultórios médicos. Por exemplo, o que fazer em caso de choque anafilático. O pessoal médico conhece todos os protocolos de cor, mas quando uma pessoa começa a morrer, muitas vezes todos ficam desesperadamente tentando resolver a situação. Para isso, há uma instrução clara na parede com passos como "abrir a embalagem de tal" e "administrar intravenosamente tantas unidades do medicamento".

Em uma situação de emergência, é difícil pensar! Deve haver instruções simples que possam ser facilmente processadas pelo cérebro.

Um bom DRP consiste em vários blocos simples:

Quem deve ser notificado sobre o início da emergência. Isso é importante para maximizar a paralelização do processo de resolução.
Como diagnosticar corretamente — fazemos o rastreamento, verificamos o status do serviço com systemctl status servicename e assim por diante.
Quanto tempo pode ser gasto em cada etapa. Se você não conseguir consertar manualmente dentro do SLA — a máquina virtual será desligada e restaurada a partir do backup de ontem.
Como garantir que a emergência foi encerrada.

Lembre-se de que o DRP começa quando o serviço falha completamente e termina com a restauração do funcionamento, mesmo que com eficiência reduzida. A simples perda de reserva não deve ativar o DRP. E você pode até escrever sobre uma xícara de chá no DRP. Sério. Estatisticamente, muitos acidentes se tornam catastróficos devido à intensidade com que a equipe tenta consertar algo, muitas vezes comprometendo o único nó vivo com dados ou arruinando definitivamente o cluster. Normalmente, cinco minutos para uma xícara de chá lhe darão um tempo para se acalmar e analisar o que está acontecendo.

Não confunda DRP com o manual do sistema! Não o sobrecarregue com dados desnecessários. Apenas permita que se navegue rapidamente por hiperlinks para a seção desejada da documentação e leia em formato mais aprofundado sobre as partes necessárias da arquitetura do serviço. No próprio DRP, apenas instruções diretas de onde e como se conectar, com comandos específicos para cópia.

Como testar corretamente

Certifique-se de que qualquer funcionário responsável seja capaz de executar todos os itens. No momento mais crítico, pode acontecer que o engenheiro não tenha permissões para acessar o sistema necessário, não tenha senhas da conta necessária ou não tenha ideia do que significa 'Conecte-se ao console de gerenciamento do serviço através do proxy no escritório principal'. Cada item deve ser extremamente simples.

Incorreto — 'Acesse a virtualização e reinicie o nó morto'
Correto — 'Conecte-se via interface da web em virt.example.com, na seção de nós, reinicie o nó que está causando erro.'

Não permita ambiguidades. Lembre-se do estagiário assustado.

Certifique-se de testar o DRP. Este não é apenas um plano para cumprir uma formalidade — é o que permitirá que você e seus clientes saiam rapidamente de uma situação crítica. O ideal é realizar isso algumas vezes:

Um especialista e vários estagiários trabalham em um ambiente de teste que imita ao máximo o serviço real. O especialista quebra o serviço de várias maneiras e dá oportunidades aos estagiários para restaurá-lo de acordo com o DRP. Todos os problemas, incertezas na documentação e erros são registrados. Após o treinamento dos estagiários, o DRP é complementado e simplificado em pontos confusos.
Teste em um serviço real. Na verdade, nunca é possível criar uma cópia perfeita de um serviço verdadeiro. Por isso, algumas vezes por ano, é necessário desligar parte dos servidores, interromper conexões e causar outras falhas da lista de ameaças, para avaliar a recuperação. É melhor um incidente planejado de 10 minutos no meio da noite do que uma falha repentina por várias horas durante o pico de carga com perda de dados.
Eliminação real de falhas. Sim, isso também faz parte do teste. Se ocorrer uma falha que não estava na lista de ameaças, é preciso atualizar e revisar o DRP com base nos resultados da investigação.

Pontos chave

Se algo ruim pode acontecer, não apenas acontecerá, mas ocorrerá da forma mais catastrófica possível.
Assegure-se de que você tem recursos para redirecionamento de carga em caso de emergência.
Verifique se você tem backups, que são criados automaticamente e regularmente testados quanto à consistência.
Elabore cenários típicos de ameaças.
Dê aos engenheiros a oportunidade de pensar em maneiras não convencionais de derrubar o serviço.
O DRP deve ser um manual simples e direto. Toda a análise complexa deve ocorrer somente após a restauração do serviço para os clientes. Mesmo que seja em capacidade de backup.
Insira os números de telefone e contatos chave no DRP.
Teste regularmente os colaboradores quanto à compreensão do DRP.
Realize falhas programadas em produção. Plataformas de teste não podem substituir tudo.