Journal

Dix-sept minutes le 8 juin 2026

La seule panne connue depuis que nous exploitons des sites de clients : ce qui a lâché, pourquoi tout a suivi, comment nous l'avons vu, ce qui a changé.

Le matin du 8 juin 2026, vers dix heures, tout ce que nous exploitions a été inaccessible pendant environ dix-sept minutes : les sites web de nos clients, notre propre site et nos services. C'est la seule panne dont nous ayons connaissance depuis que nous avons commencé à exploiter des sites web pour des clients en décembre 2024. Voici le rapport que nous vous devons, rédigé plus tard qu'il n'aurait dû l'être.

Ce qui s'est passé

Notre code utilisait une bibliothèque tierce pour vérifier des licences. Cette bibliothèque a rencontré une erreur qui lui était propre, et la manière dont notre code l'appelait faisait que sa défaillance n'était pas contenue : elle a entraîné tout le système avec elle. Rien d'autre n'était en cause. Aucun serveur n'est tombé, aucune base de données n'a été endommagée, aucune donnée n'a été perdue. Une fois la cause trouvée et la dépendance à la bibliothèque retirée du chemin qui sert les pages, tout est revenu.

Nous ne nommons pas la bibliothèque. L'erreur tenait autant à la manière dont nous l'utilisions qu'à la bibliothèque elle-même, et la nommer ferait porter la faute là où elle n'appartient qu'à moitié.

Comment nous l'avons remarqué

La réponse honnête : parce que tout avait soudain disparu. À ce moment-là, aucun moniteur ne surveillait nos services depuis l'extérieur. Nous l'avons appris comme l'aurait appris un visiteur, c'est-à-dire dans le mauvais sens. Les dix-sept minutes sont notre propre reconstitution de cette matinée, pas une mesure. C'est aussi pourquoi nous n'indiquons pas de chiffre exact de disponibilité pour la période d'avant : rien ne la mesurait.

Ce qui a changé

Trois choses.

  • La bibliothèque a disparu. Elle ne fait plus partie des systèmes que nous exploitons.
  • Une dépendance qui n'est pas nécessaire pour afficher une page ne peut plus empêcher une page de s'afficher. Une vérification de licence, un appel de statistiques, une notification : si l'un d'eux échoue, la page répond quand même et l'échec est journalisé. C'est désormais une règle que nous vérifions en revue de code, pas un espoir.
  • Quatre moniteurs indépendants surveillent nos services. Ils tournent à des endroits différents et alertent séparément, de sorte qu'un seul moniteur défaillant ne peut pas masquer une panne. Depuis la mise en service de notre propre cluster le 3 octobre 2026, status.elchi.dev publie ce qui est mesuré, y compris chaque perturbation avec sa durée réelle.

Pourquoi nous écrivons ceci

Une entreprise qui vous donne ses chiffres devrait aussi vous parler du moment où ces chiffres étaient mauvais. Si ces dix-sept minutes d'un lundi matin vous ont touché et que vous n'avez jamais eu de nouvelles de notre part, voici l'explication, et nous regrettons qu'elle arrive si tard.

Désormais, chaque perturbation qu'un client pourrait remarquer fait l'objet d'un rapport comme celui-ci dans le journal, avec ce qui a lâché, combien de temps cela a duré et ce que nous avons changé.

Écrit par Samuel Krauss, Founder. Classé sous incident, operations.

Traduit de l’anglais. Lire l’original anglais

Tous les articles Cet article en Markdown Flux Atom