Quand un service dont vous dépendez se dégrade, le rapport de bug vous arrive

Un peu après minuit le 27 août 2026, la température dans la salle du centre de données principal de Proton à Francfort est passée de 21,8 °C à 51,9 °C en moins de trente minutes. Un système de refroidissement avait échoué, et l’équipement réseau qui a atteint 105 °C s’est mis en mode de protection qui l’a désactivé jusqu’à un redémarrage froid. Proton était indisponible pendant environ deux heures.

Ce qui vaut la peine de lire n’est pas que cela s’est produit - l’infrastructure de tout le monde échoue éventuellement - mais le rapport d’incident que Proton a publié par la suite, qui est précis d’une manière que la plupart ne sont pas. Il nomme la cause : un remplacement du filtre à air sur les compresseurs d’air redondants, effectué par l’opérateur du centre de données “au milieu de la nuit, sans notification préalable”, qui “a également échoué à communiquer l’échec du refroidissement quand cela s’est produit”. Il explique pourquoi la récupération a été lente plutôt qu’instantanée - l’équipe a choisi de sauver le matériel plutôt que de restaurer le service rapidement, parce que le remplacer est difficile “avec le boom de l’IA en cours” qui tendu l’approvisionnement. Un post-mortem aussi précis est une faveur pour tous ceux qui font fonctionner quelque chose, et il vaut la peine de le dire.

Mais il y a une deuxième chose en cela qui vaut l’attention de quiconque reçoit des rapports de bugs, et il est facile de la manquer. Le symptôme visible par l’utilisateur n’était pas un message disant “Proton est indisponible”. C’était ceci, selon leurs propres mots : “Aucun e-mail n’a été perdu, mais la livraison des e-mails dans les deux sens a été retardée.”

L’échec qui ne s’annonce pas

Une panne difficile est le cas facile. Le site retourne un 503, la page ne se charge pas, tout le monde comprend en une minute que le problème n’est pas le leur.

Une dégradation est le cas difficile. Quelque chose dont vous dépendez devient lent, ou échoue une demande sur vingt, ou retarde une livraison - et cela reste en place suffisamment pour que rien n’annonce la faute. Le symptôme n’apparaît pas là où se trouve la faute. Il apparaît dans le système suivant, qui très souvent est le vôtre, utilisé par un utilisateur qui n’a aucune raison de soupçonner un centre de données à Francfort et toutes les raisons de soupçonner l’application devant lui.

Donc le rapport que vous recevez ne dit pas “mon fournisseur a un incident de refroidissement”. Il dit “votre application est lente”, ou “cela n’a pas été envoyé”, ou “cela a fonctionné ce matin et maintenant ce n’est plus le cas” - et vous passez la première heure à chercher dans le seul endroit où le problème n’est pas, parce que c’est là que la personne l’a désigné.

Distinguer leur panne de votre bug, pendant qu’elle se produit

La distinction est généralement visible en quelques minutes si vous savez où regarder, et c’est à peu près dans cet ordre.

Est-ce seulement cette seule dépendance ? Une dégradation en amont échoue selon un schéma : les demandes qui touchent ce service sont lentes ou échouent, et tout le reste sur la page va bien. Un bug qui est le vôtre est rarement aussi organisé. Ouvrez l’onglet Réseau et observez quelles demandes sont rouges ou lentes. Si elles vont toutes vers un seul hôte et rien d’autre n’est affecté, vous regardez l’après-midi de quelqu’un d’autre.

Quelle est la forme de l’échec ? Une erreur 504 Gateway Timeout est un serveur devant un autre serveur qui n’a jamais répondu - une empreinte digitale spécifique d’un service en amont qui est en place mais ne répond pas, ce qui est exactement ce à quoi une dégradation ressemble de l’extérieur. Une demande qui s’accroche puis expire, plutôt qu’une qui retourne une erreur que votre code a produite, pointe dans la même direction.

La page d’état du fournisseur lui-même le confirme-t-elle ? Elle est souvent en retard de l’incident de plusieurs minutes, donc une page d’état verte au début ne prouve rien - l’échec vous a atteint avant qu’il n’atteigne leur tableau de bord. Mais une fois qu’elle s’allume, cela règle la question. Vérifiez-la, et vérifiez les horodatages par rapport au moment où vos rapports ont commencé.

Quelque chose du vôtre a-t-il changé ? Si vous n’avez pas déployé, et le code qui échoue maintenant a fonctionné il y a une heure et n’a pas été touché, la chose qui a changé est plus susceptible d’être de l’autre côté du fil que dans un fichier que vous pouvez voir.

La version complète de ceci - le raisonnement pour chaque vérification et comment l’exécuter sous pression - est dans C’est votre bug ou leur panne ?.

Ce qu’il faut capturer pour ne pas avoir à en débattre plus tard

Le problème avec une dégradation en amont est qu’elle a disparu au moment où quelqu’un vous demande de prouver que ce n’était pas de votre faute. Le fournisseur récupère, la page d’état devient verte, le post-mortem apparaît une semaine plus tard, et tout ce que vous avez est un souvenir d’un mauvais après-midi et aucun enregistrement.

Donc pendant que cela se produit, capturez la preuve qui relie le symptôme à l’extérieur : les demandes défaillantes avec leurs codes d’état et leurs délais, les horodatages, la réponse que le service en amont a réellement retournée. C’est la différence entre “nous pensons que c’était notre fournisseur” et un rapport avec les 504 et les retards de livraison assis à côté de la chronologie d’incident propre du fournisseur. L’une est un argument ; l’autre est fermée.

Le journal réseau qu’elle capture est l’enregistrement exact de quelles demandes ont échoué et combien de temps elles ont pris, sauvegardé au moment où cela s’est mal passé plutôt que reconstruit par la suite. Lorsque la question est de savoir si la faute était la vôtre ou la leur, ce journal est ce qui y répond - et il ne s’évapore pas quand le fournisseur récupère.