Este é um cenário ilustrativo: um servidor não sobe durante uma falha, mas o cliente continua usando o sistema. A recuperação de desastre funciona quando a arquitetura detecta o problema, redireciona o tráfego e permite restaurar o serviço dentro dos limites definidos.

Recuperação de desastre começa antes do incidente

Considere, na simulação, um balanceador diante de dois destinos: o servidor A, que falha ao iniciar no rack de infraestrutura, e o servidor B, que permanece saudável. A premissa é que B tenha a aplicação e os dados necessários para atender o tráfego previsto.

Nesse desenho, a continuidade não depende de alguém descobrir o problema olhando para os indicadores do rack. Ela depende de uma verificação automática e de uma rota de atendimento preparada para a falha.

Health checks evitam que o erro chegue ao usuário

O health check, ou verificação periódica de saúde, testa os destinos do serviço. Quando um destino falha consecutivamente, o balanceador o retira de serviço e encaminha novas requisições apenas para destinos saudáveis.

  • O balanceador verifica periodicamente se o servidor responde como esperado.
  • Falhas consecutivas sinalizam que o servidor A não deve receber novas requisições.
  • O tráfego é direcionado ao servidor B enquanto ele permanecer saudável.

É assim que o cliente pode não perceber a indisponibilidade de um servidor: o tráfego segue para outro destino. A condição é importante: o destino alternativo precisa atender à operação, e o health check precisa observar um sinal relevante para o uso real.

RTO e RPO tiram a recuperação do improviso

O RTO define o limite de tempo para restaurar o serviço. O RPO define o limite de perda de dados aceitável. Sem esses valores definidos, a equipe não tem uma referência objetiva para avaliar se o plano de recuperação atende à operação.

Na simulação deste artigo, não há valores arbitrários para esses limites. O teste deve medir o tempo necessário para restaurar um backup e verificar se os dados recuperados permanecem dentro do RPO definido.

  • Restaurar o backup escolhido.
  • Medir o intervalo entre a falha e a disponibilidade do serviço.
  • Conferir o ponto de recuperação dos dados.
  • Comparar os resultados com o RTO e o RPO registrados.

Teste o failover e a volta ao normal

Um plano que só existe no papel não mostra se o redirecionamento funciona. A recuperação deve ser testada periodicamente em cenários de failover e restauração de backups.

Durante o exercício, observe se o tráfego é redirecionado, acompanhe as métricas e confirme se os alertas são acionados. Depois, registre as falhas encontradas e ajuste o procedimento enquanto o ambiente ainda está sob controle.

Próximo passo: escolha um serviço crítico, documente seu RTO e RPO e planeje um teste de failover ou restauração. Se o sistema já convive com gargalos de estabilidade, converse com a LYPES sobre as melhorias prioritárias e a forma mais segura de implementá-las sem paralisar a operação.