Quando um Serviço do Qual Você Depende se Degrada, o Relatório de Bug Cai em Você

Pouco depois da meia-noite de 27 de agosto de 2026, a temperatura na sala principal do datacenter da Proton em Frankfurt subiu de 21,8 °C para 51,9 °C em menos de trinta minutos. Um sistema de arrefecimento havia falhado, e os equipamentos de rede que atingiram 105 °C entraram em um modo de proteção que os desativou até um reinício a frio. A Proton ficou fora de serviço por cerca de duas horas.

O que vale a pena ler não é que isto aconteceu (afinal, a infraestrutura de todos falha eventualmente), mas o relatório de incidente que a Proton publicou depois, que é específico de uma forma que a maioria não é. Ele nomeia a causa: uma substituição de filtro de ar nos compressores de ar redundantes, realizada pelo operador do datacenter “no meio da noite, sem aviso prévio”, que “também falhou em comunicar a falha de arrefecimento quando aconteceu”. Explica por que a recuperação foi lenta em vez de instantânea: a equipa escolheu salvar hardware em vez de restaurar o serviço rapidamente, porque substituí-lo é difícil “com o boom contínuo de IA” pressionando a oferta. Um postmortem tão específico é um favor para todos que executam algo, e vale a pena dizer isto.

Mas há uma segunda coisa nele que merece a atenção de qualquer um que receba relatórios de bug, e é fácil de não notar. O sintoma visível ao utilizador não era uma mensagem dizendo “Proton está fora de serviço”. Era isto, nas suas palavras: “Nenhum e-mail foi perdido, mas a entrega de e-mail em ambas as direções foi atrasada.”

A falha que não se anuncia

Uma paragem completa é o caso fácil. O site retorna um 503, a página não carrega, todos entendem em um minuto que o problema não é deles.

Uma degradação é o caso difícil. Algo de que você depende fica lento, ou falha um em cada vinte pedidos, ou atrasa uma entrega, e permanece suficientemente ativo para que nada anuncie a falha. O sintoma não aparece onde a falha está. Aparece no próximo sistema da linha, que muitas vezes é o seu, vivido por um utilizador que não tem motivo para suspeitar de um datacenter em Frankfurt e toda a razão para suspeitar da aplicação que vê à sua frente.

Então o relatório que você recebe não diz “meu fornecedor está a ter um incidente de arrefecimento”. Diz “sua aplicação está lenta”, ou “não enviou”, ou “funcionava esta manhã e agora não funciona”, e você passa a primeira hora procurando no único lugar onde o problema não está, porque é para lá que a pessoa apontou.

Distinguindo a interrupção deles do seu bug, enquanto está a acontecer

A distinção é geralmente visível em minutos se você souber onde procurar, e esta é mais ou menos a ordem.

É apenas uma dependência? Uma degradação a montante segue um padrão: os pedidos que tocam esse serviço são lentos ou falham, e tudo mais na página está bem. Um bug seu próprio é raramente tão organizado. Abra o separador Rede e observe quais pedidos são vermelhos ou lentos. Se todos forem para um host e nada mais for afetado, você está olhando para o problema de outra pessoa.

Qual é a forma da falha? Um 504 Gateway Timeout é um servidor na frente de outro servidor que nunca respondeu: uma impressão digital específica de um serviço a montante que está ativo mas não respondendo, que é exatamente como uma degradação parece de fora. Um pedido que fica pendurado e depois expira, em vez de um que retorna um erro que seu código produziu, aponta para a mesma direção.

A página de status do próprio fornecedor concorda? Muitas vezes fica atrasada do incidente por vários minutos, então uma página de status verde no início não prova nada: a falha chegou a você antes de chegar ao painel deles. Mas uma vez que muda, resolve a questão. Verifique-a e verifique os timestamps contra quando seus relatórios começaram.

Algo seu mudou? Se não fez deploy, e o código que agora está falhando funcionava uma hora atrás e não foi tocado, o que mudou é mais provável estar no outro lado da conexão do que em um ficheiro que você pode ver.

A versão completa disto (o raciocínio para cada verificação e como executá-lo sob pressão) está em É Seu Bug ou a Interrupção Deles.

O que capturar para não estar a discutir sobre isto depois

O problema com uma degradação a montante é que ela desaparece quando alguém lhe pede para provar que não foi sua culpa. O fornecedor se recupera, a página de status fica verde, o postmortem aparece uma semana depois, e o que você tem é uma memória de uma tarde ruim e nenhum registo.

Então enquanto está a acontecer, capture a evidência que liga o sintoma ao exterior: os pedidos falhados com seus códigos de status e tempos, os timestamps, a resposta que o serviço a montante realmente retornou. Essa é a diferença entre “achamos que foi nosso fornecedor” e um relatório com os 504s e os atrasos de entrega sentados ao lado da linha do tempo do incidente do próprio fornecedor. Um é um argumento; o outro está fechado.

O registo de rede que captura é o registo exato de quais pedidos falharam e quanto tempo levaram, salvos no momento em que algo deu errado em vez de reconstruídos depois. Quando a questão é se a falha foi sua ou deles, esse registo é o que responde, e ele não evapora quando o fornecedor se recupera.