Recuperação de desastre não começa quando alguém corre para restaurar o serviço. Ela é testada quando um servidor falha e a arquitetura detecta o problema, tira o recurso do caminho e direciona o tráfego a destinos saudáveis.

Recuperação de desastre começa antes da emergência

Uma falha isolada não precisa virar uma interrupção para todos. O desenho precisa separar o recurso que pode falhar do caminho usado para receber as solicitações e definir o que acontece quando a saúde cai.

Em uma configuração de recuperação automática (auto-healing), a orientação de confiabilidade da AWS descreve mecanismos que podem reiniciar, remover ou substituir o recurso depois da detecção. Em serviços sem estado, isso ajuda a reduzir o tempo de recuperação e o risco de perda de disponibilidade. A ressalva é importante: essa reação precisa estar configurada e ser verificada; não surge apenas porque existe um segundo servidor.

Simulação: um servidor não subiu

O exemplo abaixo é uma simulação, não um relato de cliente. Premissas: a aplicação tem mais de um destino capaz de atendê-la; o balanceador monitora a saúde desses destinos; e os contêineres usam sondas de liveness e readiness.

  • Um servidor não conclui a inicialização. O balanceador identifica o destino como não saudável e interrompe o roteamento de novas solicitações para ele.
  • Se o problema estiver no contêiner, a falha na sonda de liveness leva o Kubernetes a reiniciá-lo. Se a aplicação ainda não estiver pronta para receber tráfego, a falha de readiness mantém o Pod fora do roteamento.
  • Enquanto isso, o balanceador pode encaminhar as solicitações para destinos saudáveis, inclusive em outra zona de disponibilidade quando essa estrutura existe, como descrito na documentação do Elastic Load Balancing .
  • Uma rotina de auto-healing pode reiniciar, remover ou substituir o recurso que falhou, conforme a arquitetura definida.

Nesse cenário, o cliente continua usando a aplicação porque o destino indisponível foi isolado antes de receber novas solicitações. A simulação não significa que toda falha será invisível: se não houver outro destino saudável ou se houver dependência de estado local, pode haver impacto.

Por que o cliente pode nem perceber

A experiência do cliente depende do caminho completo, não de um servidor específico. A readiness evita que um Pod ainda incapaz receba tráfego; a verificação do balanceador evita que um destino não saudável continue no conjunto de atendimento.

O resultado esperado é simples: a falha aparece nos eventos, nos logs e nos alertas da operação, enquanto as solicitações seguem para um destino que consegue respondê-las. Isso é tolerância a falhas, não ausência de falhas.

Como transformar a simulação em prática

Para saber se a recuperação de desastre funciona, valide o comportamento em condições controladas:

  • defina quais sinais tornam um destino não saudável e qual é a diferença entre “pode receber tráfego” e “precisa ser reiniciado”;
  • simule a retirada de um servidor e confirme se o balanceador deixa de encaminhar solicitações para ele;
  • verifique se o Kubernetes reinicia o contêiner quando liveness falha e se readiness impede o roteamento enquanto a aplicação não está pronta;
  • confirme se a substituição ou o reinício gera registro e alerta, mesmo quando não há erro percebido pelo cliente;
  • revise o resultado e corrija dependências que transformem a falha de um recurso em falha do serviço inteiro.

O ponto não é prometer que o cliente nunca verá uma indisponibilidade. É reduzir a chance de uma falha previsível se transformar em incidente amplo e saber, com evidência, qual etapa precisa de melhoria.

Próximo passo: escolha um serviço crítico, documente o que deve acontecer quando um servidor não sobe e teste esse fluxo. A LYPES pode ajudar a mapear o risco, priorizar melhorias e implementá-las sem perder de vista a operação.