Imagine uma empresa que ficou fora do ar por horas por causa de um problema de energia em um data center que ela nem sabia que existia. Os pedidos pararam, o atendimento não conseguia consultar nada e a equipe passou a tarde respondendo a clientes sem ter o que dizer. Ninguém tinha escrito o que fazer nessa situação, porque o sistema estava “na nuvem” e a nuvem parecia uma garantia. Um plano de contingência na nuvem existe justamente para evitar essa improvisação.
Em 20 de outubro de 2026, a região europe-west2, em Londres, do Google Cloud teve um incidente. Segundo o relatório preliminar publicado pelo Google em 22 de outubro, uma queda de energia da rede elétrica atingiu a instalação que hospeda a zona europe-west2-b. Os geradores de backup não partiram por falha na automação e, quando as baterias do no-break se esgotaram, servidores, rede e armazenamento daquela zona ficaram sem energia. As zonas europe-west2-a e -c também sentiram impacto, por aumento súbito de demanda e por dependências de controle entre zonas. Segundo o Google, a duração foi de cerca de 6 horas. Como se trata de um relatório preliminar, o documento final pode trazer detalhes diferentes.
Minha tese é que a lição não é desconfiar da nuvem. A lição é que a nuvem não elimina o risco de indisponibilidade, e que o plano B é uma decisão de negócio, não apenas de TI. Quem decide quanto tempo a operação pode ficar parada, quais processos vêm primeiro e o que comunicar aos clientes é a diretoria, não o departamento técnico. O resto do texto desenvolve o que essa tese exige.
O que é plano de contingência na nuvem?
Plano de contingência na nuvem é o conjunto de decisões e procedimentos que dizem o que a empresa faz quando o provedor fica indisponível, total ou parcialmente. Ele cobre como manter a operação em modo reduzido, como comunicar clientes e equipe e como voltar ao normal com os dados consistentes.
Ele não é um documento técnico guardado em uma pasta. Responde a perguntas de negócio: quantas horas de parada a empresa aguenta em cada processo, o que pode ser feito à mão e quem autoriza a decisão de acionar o modo reduzido. Se a empresa ainda está avaliando se deve migrar, vale antes ler sobre nuvem para empresas: o que é e quando vale a pena migrar.
Zona e região: o que a replicação protege de fato?
Provedores de nuvem organizam a infraestrutura em regiões, que são áreas geográficas, e, dentro delas, em zonas de disponibilidade, que são instalações isoladas com energia e rede próprias. Replicar um sistema entre zonas da mesma região protege contra a falha de uma instalação. Mas a replicação não protege contra tudo, e o incidente de Londres mostrou isso: segundo o relatório preliminar, as zonas vizinhas também sentiram o impacto, em parte por dependências de controle entre elas.
- Falha de uma instalação. Replicar entre zonas costuma proteger bem contra a perda de um prédio ou de uma linha de energia.
- Falha da região. Só uma cópia em outra região protege contra um problema que atinja a área inteira ou um serviço compartilhado.
- Erro ou ataque aos dados. A réplica copia também o erro: se um dado foi apagado ou corrompido, a cópia sofre o mesmo. Por isso backup separado é indispensável, como mostra o texto sobre backup e continuidade.
Para a diretoria, a regra prática é perguntar sempre se a cópia está em outra zona, em outra região ou apenas em outro disco. Cada resposta muda o tipo de parada que o plano consegue absorver, e essa é a informação que precisa chegar à reunião em que a decisão é tomada.
Quais processos precisam de plano B primeiro?
Nem tudo precisa voltar ao mesmo tempo. A forma mais útil de priorizar é perguntar, para cada processo, quanto ele vale por hora parado, o que a empresa perde se o cliente não for atendido e se existe obrigação legal ou contratual envolvida. Com essas três respostas, a lista de prioridades costuma aparecer sozinha.
Exemplo: em uma loja, o checkout e o controle de estoque vêm antes do painel de relatórios mensais, que pode esperar. Em uma clínica, a agenda e o acesso ao prontuário são prioridade, enquanto a emissão de relatórios gerenciais pode ser feita depois. A prioridade muda de empresa para empresa, e é a diretoria que a define.
Estimativa: um processo de vendas que gera R$ 10.000 por dia útil perde cerca de R$ 5.000 em meio dia de parada, sem contar o cliente que não volta. O número é ilustrativo, mas mostra por que vale colocar um valor na conta antes da próxima queda.
O que fazer enquanto o provedor resolve?
Durante a indisponibilidade, a empresa não controla a solução técnica, mas controla o que faz em seguida. O primeiro movimento é comunicar. Equipe e clientes precisam de uma mensagem clara sobre o que está acontecendo, o que já se sabe e quando haverá nova atualização. Silêncio costuma gerar mais desgaste que a própria parada.
- Comunicação. Defina antes do incidente um responsável, um canal e modelos de mensagem, para que ninguém improvise sob pressão.
- Modo reduzido. Escolha o que o sistema pode oferecer com menos recursos, como consulta ao catálogo sem finalização de compra ou atendimento sem histórico completo.
- Operação manual. Tenha formulários prontos, planilhas de contingência e a lista de quem autoriza cada decisão. Tudo o que for feito à mão precisa ser registrado para reconciliar depois.
Exemplo: uma loja online percebe que a finalização de compra está fora do ar, mas a vitrine ainda carrega. A decisão de negócio é manter a vitrine no ar com um aviso de instabilidade e pausar as vendas, em vez de aceitar pedidos que não seriam processados. Quem tem essa regra escrita não precisa esperar a reunião de crise para decidir, e a equipe comercial sabe o que responder ao cliente que pergunta.
Esse trabalho só funciona se for testado. Um plano guardado sem ensaio costuma falhar na primeira vez, porque o contato mudou, o acesso expirou ou ninguém sabe onde está a lista de telefones. Para saber da falha antes do cliente, o monitoramento também precisa estar no lugar, assunto de monitoramento de sistemas.
Quais perguntas fazer ao fornecedor sobre contingência?
Resiliência tem custo. Redundância em outra região aumenta a fatura, e vale entender por que ela cresce antes de decidir o nível de proteção, como explica o texto sobre custo de nuvem. Antes de assinar ou renovar um contrato, a diretoria deve fazer perguntas que vão além do preço.
- Onde estão as cópias? Pergunte se há réplica em outra zona e em outra região, e qual o tempo esperado para voltar a operar.
- Quais dependências são compartilhadas? Pergunte quais serviços de controle ou de identidade podem afetar várias zonas ao mesmo tempo.
- Como é a comunicação? Pergunte como o fornecedor avisa o cliente durante o incidente e em que prazo publica o relatório final.
- Quem testa a recuperação? Pergunte com que frequência a recuperação é testada e se o cliente pode acompanhar o teste.
A resposta honesta a cada pergunta mostra se o plano B existe na prática ou apenas no contrato.
Plano B é decisão de negócio, e precisa de um dono
A nuvem reduz muitos problemas, mas transfere outros para contratos, dependências e decisões de risco. O incidente em Londres, descrito em relatório preliminar, mostra que uma parada pode vir de uma instalação que o cliente nunca viu. A pergunta que a diretoria precisa responder não é se a nuvem é confiável, e sim quanto tempo a empresa aguenta parar e o que faz nesse intervalo.
Escolha um responsável pelo plano, faça o primeiro ensaio com um processo de cada vez e revise o documento a cada mudança relevante de sistema. Se a sua empresa quer sair do improviso e montar um plano B com critérios de negócio, fale com o nosso time.
Perguntas frequentes sobre plano de contingência na nuvem
Se os dados estão replicados, ainda preciso de backup?
Sim. A replicação copia o estado atual, inclusive erros e exclusões, então não serve como histórico. O backup separado permite voltar a um momento anterior. São proteções diferentes, e a empresa precisa das duas.
Um plano de contingência exige muita tecnologia?
Nem sempre. Boa parte do plano é de processo: quem decide, como se comunica, o que é feito à mão e quem confere a reconciliação depois. A tecnologia reduz o tempo de parada, mas o plano começa no papel e no treinamento da equipe.
O que fazer logo depois de uma queda do provedor?
Acione o responsável pelo plano, comunique clientes e equipe com a informação disponível e ative o modo reduzido previsto. Acompanhe o status oficial do fornecedor e registre o que foi feito, porque isso será necessário para reconciliar os dados depois.