Nas primeiras horas de 27 de agosto de 2026, a Proton sofreu uma interrupção generalizada que afetou os serviços de vários utilizadores. A causa principal foi uma falha total no sistema de refrigeração do nosso centro de dados em Frankfurt. Embora todos os sistemas da Proton sejam redundantes e tenhamos capacidade suficiente para suportar uma falha completa de um centro de dados, existe um pequeno número de cenários em que o failover pode demorar mais tempo e originar perturbações para os utilizadores.

Eis uma cronologia do que aconteceu, das decisões que tomámos durante o incidente e porquê, e de como foi resolvido.

Cronologia

Pouco depois das 23h00 (hora da Europa Central) de quarta-feira, 26 de agosto, ocorreu uma falha no sistema de refrigeração na sala principal do nosso centro de dados 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 a registarem 60 °C de temperatura do ar na sala. À medida que as temperaturas subiam, os equipamentos de servidores e de rede dentro das instalações começaram a falhar um a um.

O incidente visível para os utilizadores começou por volta da meia-noite de 27 de agosto, quando as falhas escalaram a ponto de se perder a redundância crítica. Isto ocorreu quando tanto o switch de rede principal como o secundário de um bastidor crítico falharam e, infelizmente, esse bastidor continha várias cópias de bases de dados principais. Embora quase todos os sistemas da Proton sejam redundantes e façam failover de forma automática/imediata, os failovers de bases de dados principais não são feitos automaticamente sem supervisão humana.

Mantemos este controlo com o intuito de evitar situações de “split-brain”, em que a indisponibilidade temporária de uma base de dados principal faz com que as cópias réplica percam algumas atualizações e fiquem dessincronizadas de formas que podem ser difíceis de reconciliar mais tarde. Além disso, quando ocorre um failover de base de dados principal, o procedimento operacional padrão consiste em fazer o failover para uma réplica no mesmo centro de dados por motivos de latência e desempenho. No entanto, a natureza específica do problema indicava que isso poderia ser desaconselhado, uma vez que poderíamos potencialmente estar a fazer o failover para algo que também iria falhar.

As decisões

Neste ponto, os engenheiros de prevenção da Proton precisavam de tomar algumas decisões cruciais enquanto operavam sob extrema pressão.

  • Dar prioridade à reposição do serviço online ou dar prioridade à resolução do problema de refrigeração e à salvaguarda do hardware dentro do centro de dados?
  • Fazer o failover para réplicas dentro do mesmo edifício em Frankfurt (mais rápido e menos perturbador, 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á indisponível no momento? Temos contingências para falhas completas de centros de dados em que tudo muda de forma total e praticamente automática com bastante rapidez, mas uma situação em que servidores aleatórios vão falhando um a um não é bem gerida pela nossa lógica de failover.

Em última análise, a velocidade a que as temperaturas estavam a subir forçou-nos a dar prioridade à salvaguarda do hardware em vez de repor os serviços online. Esta não é uma escolha que habitualmente precise de ser feita, pois os sistemas de refrigeração costumam ser redundantes e a perda total de refrigeração é bastante rara, o que significa que existe bastante tempo antes de as temperaturas se tornarem críticas. O problema é agravado pelo grande aumento da densidade energética dos servidores nos últimos anos, com CPU e GPU mais potentes para IA. Como resultado, o que antes demorava 3 a 4 horas a atingir um nível crítico tornou-se crítico em 20 minutos.

Por isso, a equipa de prevenção concentrou a sua atenção na comunicação com a equipa de operações no local do centro de dados para restaurar a refrigeração enquanto desligava o máximo de servidores possível para os proteger. Devido à escassez de equipamento de servidores associada ao atual boom da IA, muito deste equipamento — se fosse perdido — não poderia ser substituído a curto prazo. Salvaguardá-lo tinha de ser uma prioridade, mesmo com o custo de prolongar potencialmente o tempo de inatividade.

Por volta das 00:45 CEST, conseguimos restaurar a refrigeração e as temperaturas nas instalações começaram a descer, tendo a equipa de prevenção mudado o foco para a recuperação do serviço. Neste momento, tomámos a decisão de fazer o failover das bases de dados principais para Frankfurt se uma réplica ainda estivesse ativa, e para Zurique nos casos em que não existisse qualquer réplica ativa em Frankfurt, de modo a evitar alterar em demasia os nossos fluxos de tráfego e possivelmente criar nova instabilidade. Esta opção foi selecionada porque assumimos que, agora que tínhamos a refrigeração sob controlo, seria relativamente fácil repor Frankfurt online e mais rápido do que mudar para Zurique.

Infelizmente, não foi esse o caso. Durante o incidente, muitas placas de rede na infraestrutura de Frankfurt atingiram uma temperatura de 105 °C (a temperatura normal de funcionamento é de 45 °C), o que aciona um modo especial de proteção de temperatura e faz com que as placas de rede fiquem desativadas até que haja uma reposição a frio do sistema. A nossa postura de segurança limita a capacidade de aceder ao controlador fora de banda dos nossos sistemas, o que nos obrigou a acordar colaboradores adicionais para ajudar na recuperação.

Por volta das 01:30 CEST, conseguimos repor a maioria dos serviços online para grande parte dos utilizadores. No entanto, alguns sistemas menos críticos, como as notificações push ou o processamento de pagamentos, só foram recuperados por volta das 02:00 CEST.

Tal como informámos no relatório de incidente inicial, nenhum e-mail foi perdido, mas o envio e a receção de e-mails sofreram atrasos durante o incidente.

Embora os serviços visíveis para os utilizadores tenham sido totalmente restaurados, a noite não terminou aí para os nossos engenheiros, em particular para a equipa de bases de dados. A nossa infraestrutura ficou num estado altamente anómalo, com algumas bases de dados principais em Zurique e outras em Frankfurt, e várias delas a operar com redundância reduzida e/ou desempenho reduzido. A nossa equipa trabalhou durante toda a noite para resolver estes 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 sucumbiram ao calor, e ainda não sabemos se o incidente térmico irá afetar a vida útil do equipamento sobrevivente.

Causa principal e próximos passos

Uma investigação posterior a 27 de agosto determinou que a causa principal da falha de refrigeração foi a substituição do filtro de ar em ambos os compressores de ar redundantes que alimentavam o sistema de refrigeração. Infelizmente, o operador do centro de dados realizou esta operação a meio da noite, sem aviso prévio, e também não comunicou a falha de refrigeração quando esta ocorreu, o que reduziu drasticamente o tempo que tínhamos para responder. Estamos a trabalhar em estreita colaboração com o operador para evitar a repetição deste incidente.

No entanto, é também uma limitação conhecida da nossa infraestrutura atual de bases de dados que uma interrupção deste tipo possa levar a um processo de recuperação mais longo do que o normal. A série de eventos que conduziu a este incidente é altamente improvável — contudo, aconteceu.

O trabalho de resiliência das bases de dados necessário para responder a este modo de falha já está em curso e mantém-se planeado para estar concluído até ao final do ano. Capacidade de infraestrutura adicional, incluindo novo espaço de centro de dados, também está atualmente a ser integrada e deverá ficar disponível nas próximas semanas, o que reduzirá ainda mais a nossa dependência de um único local.

Infelizmente, este incidente ocorreu antes de essas melhorias estarem totalmente implementadas. Estamos agora a avaliar onde podemos acelerar em segurança o trabalho restante, mantendo o nível de rigor necessário para alterações a infraestruturas críticas de bases de dados.

Reconhecemos que os nossos utilizadores esperam um nível de fiabilidade muito elevado da Proton, e este incidente reforça a importância de concluir este trabalho e de continuar a elevar os nossos padrões de resiliência. Pedimos novamente desculpa, sem reservas, a todos os utilizadores afetados.