Quero estruturar plano de continuidade e DR
Resposta rápida
Plano de continuidade (BCP) e disaster recovery (DR) começam pela análise de impacto no negócio (BIA), não pela tecnologia. Antes de escolher solução de réplica ou backup, identifique os processos críticos do negócio e quanto tempo cada um aguenta parado sem prejuízo grave. Disso saem dois números por sistema: RTO (quanto tempo até voltar) e RPO (quanto dado é aceitável perder). Cada par de números define a arquitetura mínima necessária — de backup diário simples a réplica síncrona em outro site. Documente o plano, garanta inventário atualizado, defina papéis em situação de crise e teste o plano com regularidade. Plano nunca testado é plano que não existe — descobrir que o backup não restaura no dia do incidente é o pior cenário possível.
Na empresa pequena, plano de continuidade cabe em poucas páginas e a estratégia de DR é majoritariamente baseada em SaaS e backup. Conduza um BIA leve com a liderança: três a cinco processos críticos, RTO e RPO razoáveis para cada (raramente menos de algumas horas). Garanta backup automático, teste de restauração trimestral, política de senhas e acesso, plano de comunicação básico em crise e um documento curto de contatos críticos (MSP, provedores SaaS, banco). Não compre solução corporativa de DR: aproveite o que já vem dos provedores em nuvem. O risco maior é assumir que SaaS faz backup do seu dado — boa parte dos serviços faz retenção curta apenas para recuperação técnica, não para erro humano ou ransomware.
Na empresa média, plano de continuidade vira disciplina recorrente. Faça BIA mais profundo, com áreas de negócio levantando dependências por processo crítico, e produza uma lista por sistema com RTO, RPO e dono. A arquitetura mistura backup corporativo, réplica entre regiões em nuvem para sistemas críticos e plano de comunicação em crise com canais alternativos. Comitê de crise definido e treinado, com simulações pelo menos anuais. ISO 22301 vira referência útil para estruturar o programa. O risco maior é o documento envelhecer: empresa cresce, sistema novo entra, plano não atualiza, e na hora do incidente metade do que está no papel não corresponde mais à realidade.
Na empresa grande, BCP e DR são programa formal com governança própria, frequentemente exigido por reguladores, clientes corporativos e auditoria. O programa cobre não só TI: continuidade de negócios envolve pessoas, instalações, comunicação, cadeia de fornecedores. Estabeleça comitê de crise com diretoria, manual de crise testado por simulação anual completa, infraestrutura redundante por criticidade (sistemas tier 1 com réplica síncrona; tier 2 com réplica assíncrona; tier 3 com backup), e exercícios de tabletop trimestrais. O risco maior é programa estagnar em conformidade formal — documento aprovado, auditoria fechada, plano nunca exercitado de verdade. Simulação realista é o único filtro que separa plano que existe de plano que funciona.
- O backup existe, mas ninguém lembra a última vez que foi restaurado com sucesso
- Ataque ou queda recente expôs que não havia plano para o cenário
- Cliente, regulador ou seguro começou a pedir evidência de continuidade
- Não há clareza de quanto tempo cada sistema crítico aguenta parado
- Plano antigo virou letra morta — sistema novo nunca foi incluído
- Em crise, todo mundo improvisa porque ninguém sabe o que era para fazer
Começa pela análise de impacto no negócio (BIA)
BIA (Business Impact Analysis) é o ponto de partida porque define a régua: qual processo de negócio é crítico, qual o impacto financeiro e reputacional de cada hora parado, quais sistemas suportam cada processo e quais são as dependências externas (fornecedor, banco, regulador). Sem BIA, qualquer decisão de DR é arbitrária — paga-se solução cara para sistema que aguentaria dias parado, e fica fraco em sistema que perde dinheiro por hora.
BIA bem feito envolve as áreas de negócio, não só TI. As perguntas-chave: qual processo? Qual o custo de uma hora parado? E de um dia? Qual sistema suporta? Qual dependência externa? Esse mapa, mesmo simplificado, transforma decisão de continuidade em decisão racional.
RTO e RPO: dois números que definem tudo
De cada sistema crítico, saem dois números. RTO (Recovery Time Objective): tempo máximo aceitável entre o desastre e o retorno do serviço. RPO (Recovery Point Objective): perda máxima aceitável de dado, medida em tempo (quanto tempo de dado pode ser perdido). RTO de quatro horas exige solução diferente de RTO de quatro dias. RPO de cinco minutos exige solução diferente de RPO de vinte e quatro horas. Esses dois números, definidos pelo negócio, determinam a arquitetura mínima necessária e o custo associado.
Como traduzir RTO e RPO em arquitetura
Quanto menor o RTO e o RPO, mais cara a solução. Backup diário simples atende RTO de dias e RPO de horas a um dia, e custa pouco. Backup mais snapshot frequente atende RTO de horas e RPO de minutos a horas. Réplica assíncrona entre regiões em nuvem atende RTO de minutos e RPO de minutos. Réplica síncrona em sites geograficamente separados atende RTO próximo de zero e RPO próximo de zero, e é a solução mais cara. Quase nenhum sistema realmente justifica o extremo — a maior parte se acomoda em backup com restauração testada e réplica assíncrona para os críticos.
- BIA com as áreas de negócio. Processos críticos, impacto por tempo parado, sistemas que suportam, dependências externas.
- RTO e RPO por sistema. Negócio define o aceitável; TI traduz em arquitetura e custo. Decisão conjunta.
- Arquitetura por criticidade. Tier 1 (mais crítico) com réplica; tier 2 com backup e restauração rápida; tier 3 com backup simples. Documente a justificativa.
- Procedimentos e papéis em crise. Quem aciona, quem decide, quem comunica, quem executa. Manual escrito em linguagem operacional, não técnica demais.
- Teste e revisão regulares. Restauração de backup trimestral, simulação de cenário anual, revisão do plano a cada mudança grande de sistema.
Plano não testado é plano que não existe
Plano de continuidade vive ou morre pelo teste. Três tipos de teste compõem um programa maduro. Restauração de backup: prática regular (trimestral, no mínimo) de restaurar dados de backup em ambiente isolado e validar integridade. Tabletop exercise: a equipe se reúne, recebe um cenário e discute o que faria — barato, identifica buracos no plano. Simulação real: failover controlado para o ambiente secundário, ou exercício prolongado em ambiente isolado — caro, mas é o único teste que prova que o plano funciona. Frequência mínima recomendada: backup trimestral, tabletop trimestral, simulação anual.
Definir RTO e RPO sem o negócio. TI sozinha tende a chutar números técnicos. Negócio precisa pactuar: quanto tempo cada processo aguenta parado e quanto dado é aceitável perder.
Backup que nunca foi restaurado. Backup é só promessa até a restauração ser exercitada com sucesso. Empresa que descobre no incidente que o backup não restaura tem perda evitável.
Plano só de TI. Continuidade envolve pessoas, comunicação, instalações, fornecedores externos. Plano restrito a sistema deixa o resto improvisando em crise.
Documento que envelhece. Sistema novo entra, plano não é atualizado, e metade do que está no papel não corresponde mais à realidade. Revisão obrigatória a cada mudança relevante.
Conformidade sem capacidade. Plano aprovado para auditoria, mas sem teste, sem treinamento, sem investimento real. Bom para certificado, péssimo para crise.
- BIA conduzido com as áreas de negócio e documentado
- RTO e RPO definidos por sistema, pactuados com o negócio
- Arquitetura por criticidade documentada, com justificativa de custo
- Backup de sistemas críticos com restauração testada nos últimos 90 dias
- Política específica para dados em SaaS quando aplicável
- Manual de crise com papéis, contatos e procedimentos escritos
- Comitê de crise definido e treinado
- Calendário de testes (restauração, tabletop, simulação) publicado