Nas primeiras horas de 27 de agosto de 2026, a Proton enfrentou uma interrupção generalizada que afetou os serviços de vários usuários. A causa raiz foi uma falha total no sistema de resfriamento do nosso datacenter em Frankfurt. Embora todos os sistemas da Proton sejam redundantes e tenhamos capacidade suficiente para suportar uma falha completa de datacenter, há um pequeno número de cenários em que o failover pode demorar mais e levar a interrupções visíveis para os usuários.

Aqui está uma linha do tempo do que aconteceu, das decisões que tomamos durante o incidente e seus motivos, e de como tudo foi resolvido.

Linha do tempo

Pouco depois das 23h (horário da Europa Central) de quarta-feira, 26 de agosto, ocorreu uma falha no sistema de resfriamento na sala principal do nosso datacenter em Frankfurt. Por volta das 23h15, a temperatura começou a subir de aproximadamente 21,8 °C (temperatura nominal) para 51,9 °C em menos de meia hora, com algumas sondas de medição registrando 60 °C de temperatura do ar na sala. À medida que as temperaturas subiam, os equipamentos de rede e servidores dentro das instalações começaram a parar de funcionar, um a um.

O incidente visível para os usuários começou por volta da meia-noite de 27 de agosto, quando as falhas se intensificaram a ponto de a redundância crítica ser perdida. Isso ocorreu quando os switches de rede principal e de backup em um rack crítico falharam, e esse rack infelizmente continha várias cópias de bancos de dados principais. Embora quase todos os sistemas da Proton sejam redundantes e realizem failover automática e imediatamente, os failovers de bancos de dados principais não são feitos automaticamente sem supervisão humana.

Mantemos esse controle para evitar as chamadas situações de “split-brain”, em que a indisponibilidade temporária de um banco de dados principal faz com que as cópias de réplica percam algumas atualizações e fiquem dessincronizadas de maneiras difíceis de reconciliar posteriormente. Além disso, quando ocorre um failover de banco de dados principal, o procedimento operacional padrão é realizar o failover para uma réplica no mesmo datacenter por motivos de latência e desempenho. No entanto, a natureza específica do problema indicava que isso poderia ser imprudente, já que poderíamos estar fazendo o failover para algo que também cairia.

As decisões

Nesse momento, os engenheiros de plantão da Proton precisaram tomar algumas decisões cruciais sob extrema pressão.

  • Priorizar restabelecer o serviço on-line ou priorizar a solução do problema de resfriamento e salvar o hardware dentro do datacenter?
  • Fazer o failover para réplicas no mesmo edifício em Frankfurt (mais rápido e com menor impacto, mas possivelmente uma solução temporária se o calor não pudesse ser controlado) ou fazer o failover para Zurique?
  • Fazer o failover de tudo ou apenas do que está fora do ar no momento? Temos contingências para falhas completas de datacenter em que a migração ocorre de forma total e praticamente automática com bastante rapidez, mas uma situação em que servidores aleatórios param de funcionar um a um não é bem tratada pela nossa lógica de failover.

No fim das contas, a velocidade com que as temperaturas subiam nos forçou a priorizar a preservação do hardware em vez de restabelecer os serviços on-line. Essa não é uma escolha que normalmente precisa ser feita, pois os sistemas de resfriamento costumam ser redundantes e a perda total do resfriamento é muito rara, o que significa que há bastante tempo antes de as temperaturas se tornarem críticas. O problema é agravado pelo grande aumento na densidade de potência dos servidores nos últimos anos, com CPUs e GPUs de maior consumo para IA. Como resultado, o que costumava levar de 3 a 4 horas para se tornar crítico atingiu níveis críticos em 20 minutos.

Portanto, a equipe de plantão concentrou sua atenção em se comunicar com a equipe de operações no datacenter para restaurar o resfriamento, enquanto desligava o máximo de servidores possível para protegê-los. Devido à escassez de equipamentos de servidores associada ao atual boom da IA, grande parte desses equipamentos — se perdida — não poderia ser substituída em prazos curtos. Preservá-los tinha que ser uma prioridade, mesmo ao custo de potencialmente prolongar o tempo de inatividade.

Às 00h45 CEST, conseguimos restaurar o resfriamento e as temperaturas na instalação começaram a cair, e a equipe de plantão mudou o foco para a recuperação dos serviços. Nesse momento, tomamos a decisão de fazer o failover dos bancos de dados principais para Frankfurt caso uma réplica ainda estivesse ativa, e para Zurique nos casos em que não houvesse réplica ativa em Frankfurt, para evitar alterar excessivamente nossos fluxos de tráfego e possivelmente criar uma nova instabilidade. Essa opção foi selecionada porque presumimos que, agora que tínhamos o resfriamento sob controle, seria relativamente fácil restabelecer Frankfurt on-line e mais rápido do que migrar para Zurique.

Infelizmente, não foi isso que aconteceu. Durante o incidente, muitas placas de rede na infraestrutura de Frankfurt atingiram uma temperatura de 105 °C (a temperatura normal de operação é de 45 °C), o que ativa um modo especial de proteção de temperatura e faz com que as placas de rede fiquem desativadas até que haja uma reinicialização a frio do sistema. Nossa postura de segurança restringe a capacidade de acessar o controlador out-of-band de nossos sistemas, o que exigiu que acionássemos funcionários adicionais para ajudar na recuperação.

Às 01h30 CEST, conseguimos restabelecer a maioria dos serviços on-line para a maior parte dos usuários. No entanto, alguns sistemas menos críticos, como notificações push ou processamento de pagamentos, só foram recuperados por volta das 02h00 CEST.

Conforme informamos no relatório inicial do incidente, nenhum e-mail foi perdido, mas o envio e o recebimento de e-mails sofreram atrasos durante o incidente.

Embora os serviços voltados aos usuários tenham sido totalmente restaurados, a noite não terminou aí para nossos engenheiros, especialmente a equipe de bancos de dados. Nossa infraestrutura ficou em um estado altamente anormal, com alguns bancos de dados principais em Zurique e outros em Frankfurt, e vários deles operando com redundância reduzida e/ou desempenho reduzido. Nossa equipe trabalhou durante a noite para resolver os problemas mais urgentes, e o trabalho continuou ao longo do dia 27 de agosto para restaurar a redundância total.

Embora tenhamos conseguido salvar quase toda a infraestrutura, alguns servidores infelizmente foram danificados de forma irreversível pelo calor, e ainda não sabemos se o incidente de superaquecimento afetará a vida útil dos equipamentos sobreviventes.

Causa raiz e próximos passos

Uma investigação posterior em 27 de agosto identificou que a causa raiz da falha de resfriamento foi a substituição do filtro de ar em ambos os compressores de ar redundantes que alimentam o sistema de resfriamento. Infelizmente, a operadora do datacenter realizou essa operação no meio da noite, sem aviso prévio, e também não comunicou a falha de resfriamento quando ela aconteceu, o que reduziu drasticamente o tempo que tínhamos para responder. Estamos trabalhando em estreita colaboração com a operadora para evitar que esse incidente se repita.

No entanto, também é uma limitação conhecida da nossa infraestrutura de banco de dados atual que uma interrupção desse tipo possa levar a um processo de recuperação mais longo do que o normal. A série de eventos que levou a esse incidente é altamente improvável — e, mesmo assim, aconteceu.

O trabalho de resiliência de banco de dados necessário para solucionar esse modo de falha já está em andamento e permanece planejado para ser concluído até o final do ano. Capacidade de infraestrutura adicional, incluindo novo espaço de datacenter, também está sendo comissionada e deve ficar disponível nas próximas semanas, o que reduzirá ainda mais nossa dependência de um único local.

Infelizmente, esse incidente ocorreu antes que essas melhorias estivessem totalmente implementadas. Agora estamos avaliando onde podemos acelerar com segurança o trabalho restante, mantendo o nível de cuidado necessário para alterações em infraestruturas críticas de bancos de dados.

Reconhecemos que nossos usuários esperam um nível altíssimo de confiabilidade da Proton, e esse incidente reforça a importância de concluir esse trabalho e continuar elevando nossos padrões de resiliência. Pedimos desculpas novamente, sem reservas, a todos os usuários afetados.