Pas de déploiement sans monitor.

Le 29 mai, une fonctionnalité de contrôles de politique de quota supplémentaires est arrivée dans Service Control sans feature flag et sans gestion d’erreur sur le nouveau chemin. Le 12 juin, un changement de politique a produit des champs vides, et les binaires ont planté dans le monde entier sur une erreur de pointeur nul. Google a écrit que son premier rapport d’incident était paru environ une heure après le début des plantages, parce que l’infrastructure de Cloud Service Health était elle-même tombée. Google a aussi écrit que, pour certains clients, l’infrastructure de monitoring qu’ils faisaient tourner sur Google Cloud tombait également, ce qui les laissait sans signal de l’incident.

Ce que montre un check depuis l’extérieurCette dernière phrase plaide pour le monitoring externe, dans les mots de l’exploitant lui-même : un monitoring sur la même plateforme tombe avec elle. Perstat vérifie depuis l’extérieur, depuis 6 régions au plus, avec quorum, et son infrastructure de sondes ne tourne pas sur la plateforme qu’elle surveille. Une page de statut sur une infrastructure séparée aurait informé vos clients pendant cette heure.

Source : Rapport d’incident Google Cloud, 2025-06-12 · The Register, 2025-06-16

Un script destiné à supprimer les instances d’une app retirée a reçu des identifiants de sites au lieu d’identifiants d’apps. Il a supprimé des sites clients entiers pendant 23 minutes, à partir de 07:38 UTC. Le premier ticket client est arrivé à 07:46 UTC, au bout de 8 minutes, et le processus d’incident majeur a démarré à 08:17 UTC. La première mise à jour de la page de statut est venue à 09:03 UTC, au bout de 85 minutes, et la première déclaration externe large sur les réseaux sociaux le 7 avril, au bout de 41 heures. La restauration a pris jusqu’à 14 jours et n’était que partiellement automatisée.

Ce que montre un check depuis l’extérieurUn check HTTP de votre propre URL de tenant depuis plusieurs régions signale la panne après 2 checks consécutifs en échec, sans attendre un ticket de support. Certains clients ont perdu Statuspage et Opsgenie avec leurs sites. La page de statut et l’alerte ne doivent donc pas se trouver chez le fournisseur dont elles sont censées montrer la panne. Aucun monitoring n’aurait raccourci les 14 jours.

Source : Revue post-incident Atlassian, 2022-04-29

Le PDG a écrit que l’entreprise renouvelle chaque année des milliers de domaines avec précision, mais que le processus de renouvellement automatique de son domaine principal avait échoué. La déclaration citait une erreur humaine et de processus comme cause. Les clients se sont plaints publiquement sur Twitter.

Ce que montre un check depuis l’extérieurUn check de domaine signale la date d’expiration des jours à l’avance, depuis un système qui ne dépend pas du renouvellement automatique défaillant. Un check DNS depuis plusieurs régions aurait signalé la perte de résolution après 2 checks consécutifs en échec. Une page de statut sur un autre domaine aurait porté le message pendant que marketo.com ne se résolvait plus, mais aucun check ne peut renouveler le domaine.

Source : Base de connaissances Marketo (Adobe), P1 du 25 juillet 2017 · The Drum, 2017-07-26

En réparant la réplication, un ingénieur a supprimé le répertoire de données sur le primaire au lieu du secondaire. Les sauvegardes pg_dump n’existaient pas, parce que le script lançait pg_dump 9.2 contre PostgreSQL 9.6 et échouait. GitLab a écrit que les notifications des jobs cron en échec partaient par e-mail, mais que DMARC n’était pas activé pour ces e-mails, si bien que le destinataire les rejetait. Les instantanés de disque n’étaient pas activés pour les serveurs de base de données, et il ne restait qu’un instantané LVM manuel, vieux de 6 heures.

Ce que montre un heartbeatUn heartbeat fonctionne comme un dead man’s switch : le job de sauvegarde se signale après un succès, et Perstat alerte si le signal manque, qu’un e-mail d’erreur arrive ou non. Le cas montre aussi que l’alerte ne doit pas dépendre d’un seul canal susceptible de tomber lui-même. L’escalade doit donc passer par plusieurs voies et exiger un acquittement. Un heartbeat ne vérifie pas si la sauvegarde peut être restaurée. Cela reste le rôle d’un test de restauration.

Source : Post-mortem GitLab, 2017-02-10 · The Register, 2017-02-01, sur les 5 techniques de sauvegarde