Prometheus tourne, Grafana affiche des graphes et les alertes arrivent dans Slack, mais personne ne regarde les dashboards sauf en panne, les alertes réveillent pour des faux positifs, et chacun improvise pendant un incident. Ce module apprend les pratiques d'exploitation qui transforment une pile d'observabilité en outil du quotidien : des dashboards qui répondent à une question, des alertes qui comptent, et un cluster Kubernetes observé sans noyer Prometheus.
Il est facultatif et s'adresse à celles et ceux qui exploitent déjà une pile Prometheus et Grafana (niveau intermédiaire à avancé). Il vient après les fondamentaux, dont il applique les concepts : la leçon sur les dashboards s'appuie sur RED et USE, celle sur les alertes sur le budget d'erreur.
Quels prérequis faut-il pour ce module ?
Section intitulée « Quels prérequis faut-il pour ce module ? »Le module suppose que vous maîtrisez les fondamentaux de l'observabilité : les métriques, les méthodes RED (débit, erreurs, durée des requêtes) et USE (utilisation, saturation, erreurs des ressources) des modèles mentaux, les SLI, SLO et le budget d'erreur, et la corrélation des signaux.
Il suppose aussi une pile déployée (Prometheus et Grafana, ou un équivalent SaaS comme Datadog ou New Relic), des métriques applicatives qui vont au-delà du CPU et de la RAM, et des logs structurés. Le lab Grafana et le lab Alertmanager de la formation vous donnent cette base si elle vous manque.
Que couvre ce module, et dans quel ordre ?
Section intitulée « Que couvre ce module, et dans quel ordre ? »Le module compte quatre leçons. Lisez-les dans l'ordre si vous montez vos pratiques de zéro, car les alertes renvoient vers les dashboards ; prenez le sujet qui vous manque si vous avez déjà des bases solides.
Dashboards utiles répond au premier piège : le tableau de bord « au cas où » de quarante graphes que personne ne comprend. Un dashboard utile répond à une question précise (« mon service répond-il correctement ? »). La leçon applique les méthodes RED et USE pour construire une vue d'ensemble en haut et du détail en dessous, avec des variables et des annotations de déploiement.
Alerting efficace traite le pont entre des données qui dorment et quelqu'un qui agit. Beaucoup d'équipes alertent sur une cause (CPU élevé) plutôt que sur un symptôme (latence dégradée côté utilisateur), puis finissent par ignorer les notifications. La leçon construit un alerting symptom-first, y compris par le burn rate (la vitesse à laquelle un SLO consomme sa marge d'erreur), et dote chaque alerte des annotations qui mènent au dashboard de diagnostic et au runbook.
Observabilité Kubernetes adapte ces pratiques à un contexte où les pods sont éphémères, le scheduling dynamique et le control plane distribué. Le CPU d'un serveur ne suffit plus : la leçon distingue quatre couches à observer (application, conteneur, node, control plane), les trois sources de métriques dont kube-state-metrics, cinq signaux critiques, huit alertes de départ et le piège de la cardinalité des labels dynamiques.
AIOps clôt le module par un recul : ce que l'IA change vraiment à l'exploitation, entre détection d'anomalies, corrélation d'événements et réduction du bruit d'alertes, et ce qu'elle ne remplace pas. Courte (cinq minutes), elle se lit une fois les alertes maîtrisées, car l'AIOps se greffe sur une observabilité qui fonctionne déjà.
Un cinquième guide, Runbooks et réponse aux incidents, complète la chaîne mais appartient à la formation DevSecOps. Il écrit un runbook par alerte (symptôme, diagnostic, remédiation, escalade), organise les rôles d'incident et conduit un postmortem sans chercher de coupable.
Comment ces pratiques s'enchaînent-elles ?
Section intitulée « Comment ces pratiques s'enchaînent-elles ? »Le schéma suit le fil d'un incident : le dashboard dit ce qu'on mesure, l'alerte signale quand cela dérape, le runbook dit comment réparer, et Kubernetes s'ajoute à l'alerting comme contexte propre.
Le lien technique entre ces maillons est l'annotation : chaque alerte porte
un dashboard_url et un runbook_url, si bien que la personne d'astreinte
passe de la notification au diagnostic en un clic. Sans ces deux liens, le
temps de résolution dépend de l'expérience de celui qui est de garde.
Quelles erreurs ce module vous évite-t-il ?
Section intitulée « Quelles erreurs ce module vous évite-t-il ? »Cinq erreurs reviennent dans presque toutes les équipes. Les repérer d'abord indique par quelle leçon commencer ; le tableau relie chaque piège à la page qui le traite.
| Piège | Pourquoi c'est un problème | La page qui en parle |
|---|---|---|
| Dashboards « au cas où » de 40 panels | Personne ne les regarde, l'information utile est introuvable en panne | Dashboards |
| Alerter sur CPU > 90 % au lieu du taux d'erreur | Réveil à 3 h pour un pic sans impact, fatigue d'alerte | Alerting |
| Alertes sans runbook associé | La personne d'astreinte improvise, le MTTR dépend de l'expérience | Runbooks |
| Postmortems qui cherchent un coupable | Les gens cachent les erreurs, on n'apprend rien | Runbooks |
| Observer les pods Kubernetes comme des VM | Labels à haute cardinalité, métriques inutiles, coûts qui explosent | Observabilité Kubernetes |
Le MTTR (Mean Time To Recovery) est le temps entre la détection d'un incident et le retour à une expérience acceptable pour l'utilisateur ; le guide sur les runbooks le détaille avec MTTD et MTTA.
Où en est votre équipe ?
Section intitulée « Où en est votre équipe ? »Ce modèle en quatre niveaux situe votre organisation et désigne la prochaine étape. Beaucoup d'équipes se reconnaissent dans les niveaux 1 ou 2 ; les leçons du module mènent au niveau 3, et le niveau 4 demande d'automatiser et de tester ses pratiques, au-delà du périmètre ici.
| Niveau | Ce que vous avez | Ce qui manque | Page prioritaire |
|---|---|---|---|
| 1, Ad hoc | Dashboards par-ci par-là, alertes sur tout et rien | Aucune structure, pas de runbooks, MTTR imprévisible | Dashboards, Alerting |
| 2, Réactif | Dashboards structurés (RED/USE), alertes symptom-first | Pas de runbooks formalisés, postmortems informels | Runbooks, Alerting |
| 3, Structuré | Runbooks par alerte, processus d'incident défini, postmortems systématiques | Pas d'automatisation, pas de spécificité Kubernetes | Observabilité Kubernetes |
| 4, Optimisé | Runbooks versionnés et testés en CI, alertes validées par des tests, observabilité Kubernetes complète | Amélioration continue, chaos engineering | AIOps, pour situer la suite |
Ces pratiques dépendent-elles de l'outil ?
Section intitulée « Ces pratiques dépendent-elles de l'outil ? »Non : les pratiques (dashboards RED, alerting symptom-first, runbooks structurés) restent identiques quelle que soit la pile. Avec une pile open source, Grafana porte les dashboards, Alertmanager les alertes et un wiki ou un dépôt Git les runbooks ; avec un SaaS, ces fonctions sont intégrées, souvent complétées par un service d'astreinte comme PagerDuty. Pour comparer les outils et choisir une pile, le panorama des outils d'observabilité les classe par fonction.