Plano de recuperação de desastres

O que o modelo contém

Um plano de recuperação não testado é uma hipótese. O cronograma abaixo é moldado pela sequência crescente de testes, porque cada teste custa uma janela de mudança e cada um encontra coisas que o anterior não conseguiria:

Análise de impacto no negócio, Inventário de aplicações e serviços, mapeamento de dependências, as oficinas de impacto, e as metas de RTO e RPO a que cada serviço fica sujeito. Tudo o que vem depois é precificado a partir desses números. Marco: linha de base de RTO/RPO aprovada.
Estratégia e arquitetura de contingência, Classificação dos serviços por camada de recuperação, escolha do site de contingência ou da região secundária, arquitetura de replicação e de backup, desenho de failover de rede e DNS, e a revisão de custo contra as metas. Marco: arquitetura aprovada.
Construção e replicação, Infraestrutura de contingência, replicação de storage e de banco de dados, mudanças na política de backup, controles de identidade e de segurança no site secundário, e monitoramento do atraso de replicação. Marco: replicação em regime estável verificada.
Runbooks e documentação, Um runbook de acionamento por camada de recuperação, procedimentos de retorno e de failback, a árvore de comunicação de crise, e os critérios de declaração que dizem quem tem alçada para acionar. Marco: runbooks publicados.
Sequência de testes, Exercício de mesa primeiro, depois uma contingência parcial das aplicações de camada 1 com retorno, e então uma contingência total com validação pelo negócio e failback, com tempo de correção orçado depois de cada uma. Marco: teste de contingência total aprovado.
Aprovação e manutenção, Relatório de teste e risco residual, aprovação pela diretoria, treinamento dos respondentes, o calendário anual de testes, e o gancho no processo de GMUD que impede que aplicações novas entrem em produção silenciosamente fora do plano. Marco: plano aprovado.

Quem usa este modelo

Líderes de resiliência de TI, equipes de infraestrutura e gestores de continuidade de negócios usam esta linha do tempo para construir e comprovar a capacidade de recuperação. Ela vai da análise de impacto no negócio e das metas de RTO/RPO à construção da replicação e dos runbooks, passando por testes de mesa, parciais e de failover completo, garantindo que a organização consiga se recuperar de fato dentro das metas, e não só no papel.

RTO e RPO não são aspirações, são uma fatura. Um RPO de quinze minutos significa replicação síncrona ou quase síncrona e o custo de storage que vem junto; um RTO de quatro horas significa infraestrutura morna parada sem fazer nada. Acorde os números com o negócio antes de desenhar qualquer coisa, depois mostre quanto custa cada camada e deixe que revisem. Times que definem as metas depois da arquitetura acabam com um plano que recupera mais devagar do que foi prometido ao negócio, e ninguém descobre isso até o teste de contingência.

Como adaptar

Defina RTO e RPO por serviço, e não por organização, um serviço de pagamentos e uma wiki interna não devem dividir a mesma camada.
Reserve as duas janelas de mudança cedo; a janela da contingência total normalmente exige aprovação da diretoria e um período de baixo movimento, que são restrições de calendário, não técnicas.
Mantenha a linha de retorno ao lado de cada teste, um teste sem caminho de volta ensaiado é uma indisponibilidade esperando um dia ruim.
Acrescente linhas por camada de aplicação se você vai acionar a contingência em grupos, e não tudo de uma vez.
Alongue a janela de correção depois do teste parcial; é ali que aparece a maior parte das constatações de verdade.
Coloque o reteste anual como linhas com data, para que o plano não vença silenciosamente doze meses depois da aprovação.

Dicas de cronograma

Teste o retorno, e não só o acionamento. Rodar no site de contingência é metade do exercício; a maioria das organizações descobre os problemas caros no caminho de volta.
Faça o exercício de mesa antes de qualquer coisa técnica. É barato, não precisa de janela de mudança, e revela com confiabilidade contatos desatualizados, alçada de declaração confusa e passos de runbook que presumem um conhecimento que ninguém escreveu.
Valide com o negócio, e não com um ping. Um serviço que responde não é um serviço que funciona; coloque usuários reais concluindo transações reais durante o teste de contingência total.
Acompanhe o atraso de replicação como métrica viva. Um RPO que você não mede continuamente é um RPO que você só vai conferir durante um incidente.
Amarre a contingência ao processo de gestão de mudanças. Cada aplicação nova que entra sem camada de recuperação alarga a distância entre o plano e a realidade, e essa distância só fica visível na hora do teste.

Este modelo está em português. Páginas relacionadas ainda não traduzidas abrem em inglês.

Perguntas frequentes

Quanto tempo leva construir e testar um plano de recuperação de desastres?

Normalmente de nove a quinze meses da análise de impacto até um plano testado e aprovado. O modelo usa cerca de quinze meses. A construção é previsível; o que estica é a sequência de testes no fim, porque cada teste precisa de uma janela de mudança e de um ciclo de correção depois.

Qual a diferença entre RTO e RPO?

RTO é quanto tempo você pode ficar fora do ar, o prazo para restabelecer o serviço. RPO é quanto dado você pode perder, a idade da última cópia utilizável. O RTO puxa a infraestrutura em espera, o RPO puxa a frequência de replicação, e juntos eles determinam a maior parte do custo do plano.

Por que três testes e não um?

Porque encontram coisas diferentes. Um exercício de mesa encontra lacunas no runbook e na cadeia de decisão pelo preço de uma sala de reunião. Uma contingência parcial encontra falhas técnicas com raio de impacto limitado. Uma contingência total com validação do negócio é a única coisa que comprova o RTO. E cada um precisa que o anterior já tenha sido corrigido.

Precisamos de janela de mudança para os testes?

Para a contingência parcial e a total, sim, elas movem tráfego de produção e carregam risco real. Abra a GMUD com retorno ensaiado e critério de aborto definido. O exercício de mesa não precisa de janela, e é exatamente por isso que ele deve ser esgotado primeiro.

Como isso se relaciona com continuidade de negócios?

Recuperação de desastres é o subconjunto de tecnologia: restabelecer sistemas e dados. Continuidade de negócios é mais ampla e cobre pessoas, instalações e processos. Este modelo cobre o lado de tecnologia, embora as linhas de comunicação de crise e de declaração sejam compartilhadas com qualquer plano de continuidade que você mantenha. Em setores regulados, vale conferir também as exigências específicas do seu regulador, na área financeira, por exemplo, a política de segurança cibernética e os requisitos de contratação de nuvem definidos pelo Banco Central.

O modelo de recuperação de desastres é gratuito?

Sim. Downloads gratuitos em Excel, PowerPoint e CSV, e edição online gratuita, sem cadastro.