Sistemas em computação em nuvem também param, e Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia com mais de 25 anos em varejo, observa que a falha raramente nasce no provedor. Ela nasce em decisões de arquitetura tomadas meses antes, quando a indisponibilidade ainda parecia improvável.
Continuidade operacional não é recurso contratado junto com a máquina virtual. É uma propriedade do desenho da aplicação: como ela guarda estado, como reage à perda de uma zona de disponibilidade e quanto tempo leva para voltar sozinha. O acordo de nível de serviço não cobre nada disso.
A distância entre o que o contrato promete e o que a operação precisa aparece no pior momento possível. Compreender onde ela se forma separa uma migração que reduz risco de outra que apenas muda o risco de endereço.
O que a nuvem garante e o que continua sob responsabilidade da empresa?
A responsabilidade compartilhada define uma fronteira menos generosa do que se supõe. O provedor responde pela energia, pela rede física, pelo hipervisor e pela troca de hardware na região. Do cliente para cima ficam a replicação dos dados, o desenho da aplicação e a capacidade de restaurar backups.
Uma aplicação de vendas roda em uma única zona de disponibilidade, com banco gerenciado e sem réplica. A zona sai do ar por algumas horas. O provedor cumpre o compromisso contratado, o painel de status continua verde e a operação fica parada assim mesmo.
Jean Pierre Lessa e Santos Ferreira conduziu múltiplas viradas de ERP e integrações tecnológicas de fusões e aquisições, contextos em que essa fronteira fica visível. Migrar cargas para a nuvem resolve elasticidade, mas não decide o que acontece quando um componente crítico some no meio da tarde.
Como definir RTO e RPO antes de escolher a arquitetura?
Dois números precedem qualquer decisão técnica de continuidade. O RTO define quanto tempo o negócio tolera parado; o RPO define quanto dado ele aceita perder. Sem esses valores acordados com quem responde pela operação, a discussão de arquitetura vira preferência pessoal de engenheiro.
Um checkout de comércio eletrônico e um relatório gerencial interno não merecem o mesmo tratamento. O primeiro perde receita por minuto e justifica réplica ativa em outra região. O segundo volta no dia seguinte sem consequência, e alta disponibilidade nele desperdiça orçamento.
Sem classificação de criticidade, todo responsável de área pede tolerância zero para o que é seu. Jean Pierre Lessa e Santos Ferreira pontua que o resultado é um projeto caro, que protege igualmente o essencial e o dispensável, e que, por isso, costuma ser cortado na primeira revisão de custos.
Por que a redundância desenhada no papel falha junto?
Redundância só funciona quando as cópias falham de forma independente. Duas instâncias na mesma região compartilham rede, plano de controle e, muitas vezes, o provedor de identidade. Basta uma dessas camadas cair para que as duas saiam do ar juntas, com o diagrama mostrando blocos separados.
Jean Pierre Lessa e Santos Ferreira avalia que integrações de aquisições tornam o problema mais difícil de enxergar. Cada empresa chega com sua pilha de dependências, e a soma das duas cria caminhos que ninguém desenhou. Um serviço herdado passa a ser chamado por sistemas nunca inventariados juntos.
O mapeamento de dependências corrige isso antes do incidente. Vale listar, para cada sistema crítico, de quem ele depende para subir: banco, fila, autenticação, resolução de nomes, segredo de configuração. Dependência presente em todas as listas virou ponto único de falha do negócio.
Continuidade que não é testada é apenas documentação
Backup nunca restaurado não é backup, é expectativa. Muitas empresas descobrem isso no dia em que precisam do arquivo e encontram uma cópia incompleta ou uma chave de criptografia guardada no sistema que caiu. O teste periódico de restauração transforma suposição em fato verificável.
Exercícios controlados de falha revelam o que o documento esconde. Derrubar uma zona em homologação mostra runbook desatualizado, credencial expirada, ordem errada de subida e telefone de plantão que ninguém atende. Cada descoberta dessas é barata no teste e cara no incidente.
Como resume Jean Pierre Lessa e Santos Ferreira, continuidade é menos promessa de plataforma e mais disciplina de operação. A computação em nuvem entrega componentes para resistir a falhas em escala, porém nenhum provedor assume no lugar da empresa quanto tempo ela pode ficar parada.
