5 min de lecture
Un ami ingénieur DevOps m’a appelé l’année dernière, peu après sa première nuit d’astreinte. 2 h 17, un mardi, une alerte Slack : « CRITIQUE – Temps de réponse de la passerelle API > 5 s – En production ». Il fixait un tableau de bord Grafana composé de 14 panneaux, dont il comprenait à peine trois. Personne ne lui avait expliqué qu’un service d’astreinte ne consiste pas à résoudre des problèmes – mais à savoir lequel des problèmes est le bon à traiter en priorité. Trois leçons tirées de cette nuit, que tout ingénieur cloud devrait connaître avant son premier service d’astreinte.
L’essentiel
- La fatigue liée aux alertes constitue le véritable défi de l’astreinte : les équipes recevant plus de 100 alertes par semaine ignorent en moyenne 30 % des notifications critiques (PagerDuty, State of Digital Operations, 2025).
- Les procédures opérationnelles (runbooks) non soumises à des revues régulières ni à des exercices pratiques (Game Days) sont inutilisables – elles décrivent des systèmes ayant évolué depuis leur dernière mise à jour.
- Une culture des analyses post-incident (postmortem) n’est pas une surcharge bureaucratique, mais la seule méthode permettant d’apprendre systématiquement des incidents, au lieu de les répéter.
2 h 17 : Le moment où rien ne fonctionne comme dans les tutoriels
Mon ami – appelons-le Max – était membre de l’équipe depuis six mois. Il avait déployé des clusters Kubernetes, écrit des charts Helm et construit des pipelines CI/CD. Il se sentait prêt. Ce qu’il ignorait : tout ce qu’il avait appris concernait le fonctionnement nominal. L’astreinte commence précisément là où cesse le fonctionnement nominal.
L’alerte est arrivée via PagerDuty, a été redirigée vers Slack et est également apparue simultanément sous forme de notification push sur son smartphone. Au cours des quatre minutes suivantes, sept autres alertes sont survenues – dont trois classées « CRITIQUES », deux « AVERTISSEMENTS » et deux « INFORMATIONS ». Max ne savait pas laquelle des sept alertes constituait la cause initiale, ni lesquelles étaient des erreurs secondaires. Son tableau de bord Grafana affichait des lignes rouges partout, mais il était incapable de distinguer si le pic d’utilisation du processeur était la cause ou la conséquence du problème de latence.
Après vingt minutes et un appel Slack paniqué avec l’ingénieur senior, le problème fut résolu : un pod avait atteint sa limite mémoire et était piégé dans une boucle de redémarrage. La solution tenait en une seule ligne. Mais ces vingt minutes de panique ont appris à Max davantage sur les opérations cloud que six mois de fonctionnement nominal.
Leçon 1 : Signal contre bruit – le vrai travail se fait avant l’incident
Cette nuit-là, Max a reçu 11 alertes en 15 minutes. Une seule d’entre elles était pertinente. Les dix autres étaient soit des erreurs secondaires, soit des alertes dotées de seuils trop bas, déclenchées par la moindre fluctuation de charge.
Ce que Max aurait aimé savoir à l’avance : l’ajustement des alertes (alerting tuning) n’est pas une tâche ponctuelle qu’on réalise une fois pour toutes puis oublie. C’est un processus continu. Toute alerte qui ne conduit à aucune action est du bruit. Toute alerte qui devrait conduire à une action, mais qui passe inaperçue, constitue un risque. Améliorer le rapport signal/bruit est la tâche la plus importante à accomplir avant le premier incident – bien plus que la simple configuration de tableaux de bord.
Son conseil : demandez à votre équipe quelles alertes, au cours des 30 derniers jours, ont effectivement débouché sur une action concrète. Toutes les autres doivent être examinées.
Leçon 2 : Un runbook non mis à jour n’est pas un runbook
À 2 h 30, Max a ouvert le runbook. Celui-ci décrivait une architecture qui avait été entièrement remodelée trois mois plus tôt. Le microservice désigné comme « point de défaillance unique » n’existait plus. Le répartiteur de charge (load balancer) présenté comme « point de terminaison principal pour les contrôles de santé » avait été remplacé par un nouveau. Il disposait d’un document qui le menait activement en erreur.
« Un runbook obsolète est plus dangereux qu’aucun runbook. Sans runbook, vous savez que vous n’en avez pas. Avec un runbook obsolète, vous croyez en avoir un – et suivez une procédure qui ne correspond plus à la réalité. »
– Évaluation rédactionnelle de cloudmagazin
Ce que Max en a retenu : les Game Days ne sont pas une activité ludique réservée aux équipes disposant de temps libre. Ce sont le seul moyen de garantir que vos runbooks fonctionnent avant d’en avoir besoin en situation réelle. Son équipe organise désormais un incident simulé tous les six semaines. Depuis, le runbook est toujours à jour – car chaque Game Day met en lumière les écarts entre la documentation et la réalité opérationnelle.
Leçon 3 : Une culture des postmortems sauve les nerfs et la réputation
Le lendemain de l’incident, quelque chose s’est produit que Max n’attendait pas : une analyse structurée postmortem. Pas de recherche de coupables, pas d’assignation de responsabilités. À la place : une chronologie, la cause racine (root cause), les facteurs contributifs, et des actions correctives avec leurs propriétaires (owner) et leurs échéances. L’ingénieur senior utilisait une fiche-type qu’il employait depuis trois ans – cinq sections, une page.
L’analyse postmortem a révélé trois points passés inaperçus : premièrement, la fuite mémoire existait depuis deux semaines, mais l’alerte correspondante était configurée comme « faible priorité ». Deuxièmement, le chemin d’escalade (escalation path) était flou – Max ne savait pas à quel moment il pouvait « légitimement » appeler l’ingénieur senior plutôt que de tenter de résoudre lui-même le problème. Troisièmement, le processus d’intégration des nouveaux membres en astreinte ne prévoyait pas de période d’observation (shadowing).
Les trois actions correctives ont été mises en œuvre la semaine suivante. Depuis, chaque nouveau membre de l’équipe effectue une semaine complète de « Shadow On-Call » avant d’intégrer seul la rotation. Cela coûte une semaine par personne. Mais cela épargne des mois de frustration.
Ce que Max fait différemment aujourd’hui
Deux ans et probablement 50 nuits d’astreinte plus tard, Max a conservé trois habitudes : il vérifie ses alertes une fois par sprint et supprime tout ce qui, au cours des 30 derniers jours, n’a pas débouché sur une action. Il met à jour le runbook après chaque changement d’architecture – pas seulement après un incident. Et il rédige un postmortem après chaque incident, même « mineur ». Car ce sont précisément les petits incidents qui offrent les meilleures opportunités d’apprentissage – ils constituent souvent les prémices des grands incidents.
Si vous vous apprêtez à assumer votre première astreinte : vous commettrez des erreurs. Ce n’est pas le problème. Le problème survient lorsque votre équipe ne dispose d’aucune structure pour tirer des enseignements de ces erreurs. Demandez des Game Days, demandez des procédures de réponse aux incidents, demandez une phase de « Shadow On-Call ». Si rien de tout cela n’existe encore : créez-le. C’est la voie la plus rapide pour passer du statut de junior à celui d’ingénieur qu’on appelle la nuit – non parce que vous connaissez la meilleure solution, mais parce que vous maîtrisez le meilleur processus.
Questions fréquentes
À partir de quand un ingénieur junior peut-il intégrer la rotation d’astreinte ?
Après une phase d’observation (shadowing) d’au moins une semaine et la participation à un Game Day. Plus important que les compétences techniques est la connaissance du chemin d’escalade : quand dois-je escalader ? À qui ? Par quel canal ? Sans cette clarté, personne ne doit être placé seul en astreinte.
Quel nombre d’alertes hebdomadaires est acceptable ?
PagerDuty recommande comme seuil indicatif moins de 40 alertes par semaine et par équipe. Ce qui compte n’est pas le chiffre en soi, mais le ratio : plus de 50 % des alertes doivent déboucher sur une action concrète. Si ce taux est inférieur, un ajustement des alertes est impératif.
Quel format de postmortem fonctionne le mieux ?
Celui que votre équipe utilise réellement. Une structure éprouvée comprend : chronologie, cause racine (root cause), facteurs contributifs, impact, actions correctives (avec propriétaire et échéance). Une page maximum. Google et Atlassian publient gratuitement leurs modèles.
Suggestions de lecture de la rédaction
Source de l’image principale : illustration générée par IA (FLUX.2) – aucune représentation de produit
