Um cabo da rede elétrica falhou fora de um data center em Londres. Isso, por si só, deveria ter sido absorvido pela arquitetura de energia. Não foi. Durante uma manutenção, um dos dois alimentadores principais estava isolado; quando o outro caiu, a lógica que deveria acionar os geradores não reconheceu corretamente o cenário. As baterias seguraram a carga por alguns minutos e depois os servidores da zona europe-west2-b apagaram.
O relato é do próprio Google Cloud, no postmortem do incidente de 20 de outubro. O impacto principal foi mitigado depois de 6 horas e 8 minutos, mas a parte mais útil para quem opera sistemas não está no cabo rompido. Está no encadeamento: um plano de redundância temporariamente reduzido, uma automação de backup que falhou e um failover que levou tráfego e pressão para o que restou da região.
Redundância no desenho não é redundância no momento do incidente
O data center usava dois caminhos de energia e geradores de backup. Só que, durante uma reparação, um dos alimentadores estava em uma postura temporária de manutenção. A instalação ficou dependente do outro caminho. Quando houve a falha externa, o gerador não recebeu o comando automático de partida porque a configuração do PLC ainda interpretava tensão no caminho isolado como sinal de uma fonte saudável.
É um alerta bem direto: diagramas de arquitetura normalmente mostram o estado ideal. Incidentes acontecem também durante manutenção, migração, troca de fornecedor e alteração de rede — justamente quando parte da folga foi retirada. Para um time de software, a pergunta útil não é apenas “temos duas zonas?”. É: o que sobra quando uma zona está em manutenção, uma dependência regional degrada e o failover começa a concentrar carga?
Failover desloca o problema; ele não cria capacidade
Quando a zona ficou indisponível, tráfego e chamadas passaram a buscar zonas não afetadas. O postmortem relata picos de latência, filas de admissão e erros transitórios porque a capacidade disponível recebeu de uma vez workloads, réplicas e chamadas de controle que antes estavam distribuídos. Serviços regionais também sofreram timeouts ao depender de componentes que estavam na zona desconectada.
Esse é o detalhe que costuma escapar de um plano de continuidade escrito só como “fazer failover”. Mover uma requisição é fácil de desenhar; garantir que o destino tenha capacidade, conexões, limites e dependências saudáveis é o trabalho difícil. Se todos os clientes e jobs tentam se recuperar ao mesmo tempo, o mecanismo de proteção pode virar a próxima fila.
- Teste a capacidade de sobrevivência: quanto tráfego cada zona ou região aguenta depois de perder uma vizinha?
- Defina prioridades: checkout, autenticação, processamento assíncrono e analytics não precisam disputar o mesmo recurso no mesmo instante.
- Controle a retomada: readmitir tráfego gradualmente costuma ser mais seguro do que religar tudo assim que o health check muda de cor.
Bateria e backup precisam de teste de ponta a ponta
As UPS funcionaram como ponte até as baterias se esgotarem. O problema estava na transição seguinte. É uma diferença importante: componentes podem passar em seus testes individuais e o sistema ainda falhar na passagem entre eles.
Em escala menor, isso aparece quando o banco tem réplica, mas a aplicação ainda aponta para o endpoint antigo; quando o DNS tem failover, mas os workers continuam saturando a fila; ou quando existe backup, mas ninguém mediu quanto tempo leva para restaurar. A recomendação do Google Cloud para confiabilidade inclui redundância, observabilidade, degradação graciosa e testes de recuperação. O incidente mostra por que essas práticas precisam se encontrar no mesmo exercício.
Recuperar é mais do que ligar servidor
Depois que a energia voltou, o trabalho não acabou. Hosts, rede e armazenamento precisaram se recuperar. O Google relata que parte dos dispositivos de storage sofreu desligamento não limpo e que a equipe optou por não apressar serviços que poderiam piorar a integridade da recuperação. A volta do tráfego foi controlada, com filas sendo drenadas antes de normalizar a zona.
Para quem responde a incidentes, esse trecho é um bom antídoto contra a pressão de “coloca de pé agora”. A ordem correta pode ser preservar dados, checar consistência, limitar escrita e só então aumentar a carga. Um serviço que responde rápido com estado corrompido não está recuperado.
O checklist que vale sair deste postmortem
- Modele o estado de manutenção. Liste o que fica sem redundância enquanto há mudança planejada e qual risco passa a exigir janela ou aprovação adicional.
- Exercite a transição, não só os componentes. Simule a troca de energia, zona, banco, DNS ou credencial até a aplicação voltar a atender.
- Meça o failover sob carga. Valide capacidade, pools de conexão, limites de API, filas e dependências de plano de controle.
- Escreva uma ordem de retomada. Quem decide o que volta primeiro, quais dados precisam de verificação e quando o tráfego pode crescer?
- Guarde evidência para o pós-incidente. Linha do tempo, métricas e decisões ajudam a corrigir o sistema — não apenas a explicar o que aconteceu.
Nenhum time impede toda falha externa. O que separa uma queda localizada de uma crise maior é saber quais proteções estão realmente disponíveis no dia da mudança, como o sistema se comporta sem uma zona e como voltar sem criar um segundo incidente.
