Notre page de statut publique affiche les mêmes chiffres que ceux qui nous alertent. Des sondes de l'extérieur vers l'intérieur, des sentinelles pour les pannes au ralenti, la maintenance du cloud traversée sans incident, et la copie nocturne qui vit à des centaines de kilomètres.
Chaque fournisseur affirme que « la fiabilité est notre priorité absolue », en général dans les excuses. Cet article est la version sans excuses : ce que nous exploitons réellement pour garder email.eu en état, ce que nous avons construit pour les jours où quelque chose casse quand même, et pourquoi notre page de statut publique affiche les mêmes chiffres que ceux qui nous réveillent. Partie 6 de la série.
L'erreur fondamentale en supervision consiste à demander à ses serveurs comment ils se sentent. Les serveurs sont optimistes. Le processus tourne, le port est ouvert, le disque a de la place, et pendant ce temps un client ne peut pas envoyer de courrier à cause d'un nom d'hôte dans un certificat ou d'une file bloquée deux couches plus haut.
Notre supervision est donc construite de l'extérieur vers l'intérieur. Les sondes s'adressent à chaque pilier comme le ferait un utilisateur : par les adresses publiques, avec les vrais protocoles, en vérifiant les réponses dont un vrai logiciel a besoin. La sentinelle TLS de la partie 3 en est l'exemple le plus net : un certificat peut être valide et approuvé tout en manquant le seul nom d'hôte qu'un logiciel strict exige, et seule une vérification qui se connecte comme ce logiciel le remarquera, c'est donc ainsi que la nôtre se connecte. Le principe, « surveiller la promesse, pas le processus », vaut pour toute la plateforme : les sondes se connectent là où un utilisateur se connecterait et récupèrent ce qu'un utilisateur récupérerait.
Ces mêmes sondes alimentent status.email.eu. Il n'y a aucune couche marketing entre nos alertes et la page publique ; le taux de disponibilité que vous voyez est calculé à partir des vérifications qui nous réveillent. Une page de statut retouchée à la main pendant les incidents est un communiqué de presse. La nôtre est un instrument de mesure.
Les pannes attirent toute l'attention, mais les défauts qui érodent vraiment une plateforme sont les lents : un disque qui se remplit en quelques semaines, un renouvellement de certificat qui laisse tomber un nom d'hôte, une tâche nocturne qui s'arrête en silence. Pour chacun, nous exploitons une petite sentinelle dont l'unique rôle est un pessimisme professionnel. L'une surveille les certificats de messagerie chaque jour, comme ci-dessus. Une autre surveille l'espace disque des bases et se plaint bien avant que « bien avant que cela compte » devienne urgent. Le principe est volontairement bête : un minuscule vérificateur indépendant par mode de panne lente connu, car un système de supervision subtil est une chose de plus qui peut échouer subtilement. Chaque fois que nous identifions un nouveau mode de panne lente, il reçoit sa propre sentinelle, et la collection ne fait que grandir.
Notre hébergeur remplace périodiquement les machines sous le cluster Kubernetes. Correctifs de noyau, maintenance matérielle, routine et à peine annoncée. Dans un cloud géré, le sol bouge, et c'est à nous d'en faire un non-événement. Tout ce qui est critique tourne donc avec au moins deux répliques, et, tout aussi important, l'ordonnanceur se voit dire explicitement quelles paires ne doivent jamais être indisponibles en même temps, de sorte que la maintenance vide les machines dans un ordre qui garde chaque service en quorum. La barre pour une nuit de maintenance n'est pas « nous avons récupéré vite ». C'est « rien d'observable ne s'est produit ».
Des serveurs redondants protègent contre les machines qui tombent. Ils ne protègent pas contre les catégories plus vastes et plus rares : un événement à l'échelle d'un centre de données, ou une erreur d'exploitation qui se réplique fidèlement sur chaque copie. Pour cela, les données clients essentielles sont copiées chaque nuit vers une seconde région OVH à des centaines de kilomètres, sur une infrastructure distincte.
Une sauvegarde que personne ne surveille est un espoir, pas une sauvegarde, la copie a donc sa propre sonde : la console vérifie la fraîcheur de la copie hors région et traite une copie périmée comme un incident en soi, et non comme quelque chose à découvrir pendant une catastrophe. Nous nous tenons ici à la même règle que partout : ne rien affirmer de plus que ce qui tourne en production. À mesure que nous ajoutons des produits, raccorder leurs données à cette copie fait partie de la livraison, et les contrôles de fraîcheur en sont l'application.
Ce que nous promettons, c'est une structure : deux exemplaires de tout ce qui est critique, des rayons d'impact délibérément réduits, des sentinelles qui font remonter les problèmes avant les clients, une page de statut qui ne peut pas nous flatter, et des réponses franches dessus quand quelque chose casse. La fiabilité n'est pas de l'héroïsme. C'est la suppression patiente de toute raison d'en avoir besoin.
Enfin, la partie 7 : les soixante secondes après votre clic sur s'inscrire, là où chaque pilier de cette série doit fonctionner en même temps.