Radar Tech: Falha de refrigeração derruba o Proton — o que o outage de 27/08 ensina sobre failover de datacenter

O Proton divulgou nesta sexta-feira o relatório de incidente do apagão que afetou seus serviços na madrugada de 27 de agosto de 2026. Para quem projeta sistemas de alta disponibilidade, a história é um raro e detalhado estudo de caso real de falha de datacenter — e um alerta sobre como a era da IA mudou os tempos de resposta que os arquitetos davam como certos.

O que aconteceu

Logo após as 23h (horário da Europa Central) de 26 de agosto, o sistema de refrigeração do datacenter do Proton em Frankfurt falhou por completo. A temperatura da sala saltou de cerca de 21,8°C (nominal) para 51,9°C em menos de meia hora — com algumas sondas marcando 60°C. Equipamentos de rede e servidores começaram a morrer um a um.

O ponto de virada veio por volta da meia-noite: os switches primário e de backup de um rack crítico caíram juntos, e esse rack continha várias cópias primárias de bancos de dados. Foi quando a redundância crítica se perdeu.

As decisões de arquitetura que valem ouro

O relatório do Proton deixa claro três decisões que qualquer arquiteto de resiliência deveria estudar:

• Proteger o hardware ou manter o serviço? O time escolheu proteger o hardware. Com a temperatura subindo a esse ritmo e escassez de reposição de equipamentos no mercado (efeito do boom de IA/GPUs), perder servidores significaria indisponibilidade por semanas. Essa é uma inversão importante do cenário clássico.
• O tempo crítico caiu de 3-4 horas para ~20 minutos. A maior densidade de potência dos servidores modernos — CPUs e GPUs para IA — faz o calor se acumular muito mais rápido. Runbooks que pressupunham horas de tolerância ficaram obsoletos.
• Failover de primário continua sendo supervisionado (humano). Apesar da pressão, o Proton mantém a promoção de primários longe da automação total, para evitar o clássico split-brain — dois primários aceitando escrita ao mesmo tempo, com réplicas des-sincronizadas e difíceis de reconciliar.

Também vale destacar o detalhe da proteção térmica: várias NICs chegaram a 105°C (o normal é 45°C) e entraram em modo de proteção, exigindo cold reset para voltar — e a segurança do ambiente restringe o acesso ao out-of-band controller, o que obrigou a despertar mais pessoas para a recuperação.

Recuperação e lições

Os serviços principais voltaram por volta de 01:30–02:00 CEST, mas o Proton deixou explícito que o incidente não terminou ali: a infraestrutura ficou num estado anormal — alguns primários em Frankfurt, outros em Zurique, vários com redundância reduzida — e o time trabalhou o dia inteiro de 27 de agosto para restaurar a redundância plena. Nenhum e-mail foi perdido, apenas atrasos na entrega em ambos os sentidos.

A lição central para arquitetos: incidente não termina quando o serviço volta ao ar, mas quando a redundância plena é restaurada. E o segundo ensinamento é que a premissa de "a refrigeração é redundante e dá tempo de sobra" não vale mais — o envelope térmico encolheu.

Como preparar o seu time

Falhas de datacenter são raras, mas quando acontecem não há tempo de improvisar. A resposta certa é um runbook claro, com limiares numéricos, matrizes de decisão proteger × disponibilizar, gates de verificação e plano de rollback — algo que um on-call consiga seguir sob pressão, de madrugada, sem depender de julgamento de momento.

Para ajudar nisso, publicamos no ArchPrompts um pacote de arquivos que transforma "como reagir a uma falha crítica de datacenter?" num runbook de failover multi-região completo e auditável: modelos de ameaça, failover supervisionado de primário (com prevenção de split-brain), recuperação e retorno à redundância plena, variações para RCA, multi-cloud e drill de game day. Vale a pena conferir antes que a próxima anomalia térmica aconteça.

Radar Tech é a curadoria diária de notícias de tecnologia com viés de arquitetura de software do ArchPrompts. Hoje: o relatório de incidente do Proton e o que ele ensina sobre failover de datacenter na era da alta densidade de potência.