Vous avez compris les fondamentaux — logs, métriques, traces, SLO. 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 quand un incident arrive, chacun improvise. Cette section vous donne les pratiques opérationnelles qui transforment une stack d’observabilité en un système qui aide vraiment au quotidien — des dashboards qu’on consulte, des alertes qui comptent, et des runbooks qui réduisent le temps de résolution.
Prérequis
Section intitulée « Prérequis »Cette section suppose que vous maîtrisez les fondamentaux. Vous tirerez davantage des guides si vous avez :
- Lu la section Fondamentaux — particulièrement les guides sur les métriques, les SLI/SLO et la corrélation
- Une stack d’observabilité déployée — Prometheus + Grafana, ou équivalent SaaS (Datadog, New Relic)
- Des métriques applicatives — pas uniquement CPU/RAM, mais aussi les signaux RED (rate, errors, duration)
- Un accès aux logs structurés — Loki, Elasticsearch, ou logs SaaS
Si ces notions vous sont familières, vous êtes prêt. Sinon, commencez par la section Fondamentaux.
Par où commencer selon votre situation
Section intitulée « Par où commencer selon votre situation »Parcours guidé
Section intitulée « Parcours guidé »Étape 1 — Construire des dashboards qui servent
Section intitulée « Étape 1 — Construire des dashboards qui servent »Le premier piège : créer des dashboards “au cas où” avec 40 graphes que personne ne comprend. Un dashboard utile répond à une question précise — “Mon service répond-il correctement ?” ou “Où est le goulet d’étranglement ?”. Le guide Dashboard vous apprend à appliquer les frameworks RED et USE pour construire des vues actionnables : un overview en haut (santé globale en un coup d’œil), du drill-down en dessous (détail par service, par endpoint, par instance).
La règle : si vous n’avez pas regardé un panel depuis 30 jours, supprimez-le. Un dashboard encombré est un dashboard ignoré.
Étape 2 — Créer des alertes qui comptent
Section intitulée « Étape 2 — Créer des alertes qui comptent »Les alertes sont le pont entre l’observabilité passive (des données qui dorment) et l’action (quelqu’un qui agit). Mais trop d’équipes alertent sur des causes (CPU élevé) au lieu de symptômes (latence utilisateur dégradée). Résultat : des alertes qui réveillent à 3h du matin pour des situations qui n’impactent personne, et une équipe qui finit par ignorer les notifications.
Le guide Alerting vous apprend à construire des alertes symptom-first : on alerte sur l’impact utilisateur (augmentation du taux d’erreur, burn rate du SLO qui s’envole), pas sur les causes internes. Chaque alerte pointe vers un runbook, un dashboard de diagnostic et des requêtes de logs/traces — tout ce qu’il faut pour agir immédiatement.
Étape 3 — Structurer la réponse aux incidents
Section intitulée « Étape 3 — Structurer la réponse aux incidents »Quand une alerte sonne, que fait l’on-call ? Sans runbooks, chacun improvise. Les anciens se débrouillent avec l’expérience, les nouveaux cherchent pendant que le client attend. Le MTTR (temps de résolution) dépend de qui est de garde.
Le guide Runbooks et incidents structure tout le cycle : un runbook par alerte (symptôme → diagnostic → remédiation → escalade), un processus d’incident avec rôles clairs (Incident Commander, Ops Lead, Scribe, Communicateur), et un postmortem qui transforme chaque panne en amélioration. L’objectif : que le MTTR soit constant quel que soit l’ingénieur de garde.
Étape 4 — Maîtriser l’observabilité Kubernetes
Section intitulée « Étape 4 — Maîtriser l’observabilité Kubernetes »Kubernetes ajoute une couche de complexité : pods éphémères, scheduling dynamique, control plane distribué. Les métriques traditionnelles (CPU d’un serveur) ne suffisent plus — il faut observer 4 couches (application, conteneur, node, control plane) avec des sources spécifiques (kube-state-metrics, cAdvisor, kubelet).
Le guide Observabilité Kubernetes vous donne les 5 signaux critiques à surveiller (OOMKilled, pod restarts, pending pods, node not ready, CPU throttling), les alertes Prometheus prêtes à copier-coller, et les techniques pour maîtriser la cardinalité des labels dynamiques.
Glossaire express
Section intitulée « Glossaire express »Avant d’aller plus loin, voici les termes que vous croiserez dans tous les guides pratiques. Chaque page les définit en détail, mais ce résumé vous évite de décrocher dès la première lecture.
| Terme | Définition en une phrase |
|---|---|
| Symptom-first | Alerter sur l’impact utilisateur (erreurs, latence) plutôt que sur les causes internes (CPU, RAM) |
| Burn rate | La vitesse de consommation de l’error budget — un burn rate de 10× épuise le budget 10 fois plus vite |
| Runbook | Documentation structurée pour diagnostiquer et résoudre un problème lié à une alerte spécifique |
| Playbook | Procédure pour gérer un type d’incident (panne BDD, DDoS) — peut invoquer plusieurs runbooks |
| MTTR | Mean Time To Recovery — le temps entre la détection d’un incident et le retour à une expérience utilisateur acceptable |
| Incident Commander (IC) | Le coordinateur d’un incident majeur — décide des priorités et valide les actions |
| Postmortem | L’analyse post-incident qui identifie les causes et génère des action items — toujours blameless |
| Action item | Une amélioration concrète issue d’un postmortem — catégorisée (prévention, détection, mitigation, remédiation, résilience) |
| kube-state-metrics | Exporter Prometheus qui expose les états des objets Kubernetes (pods, deployments, nodes) |
| cAdvisor | Collecteur de métriques de consommation ressources par conteneur (CPU, mémoire, I/O) |
Les pièges classiques des pratiques opérationnelles
Section intitulée « Les pièges classiques des pratiques opérationnelles »Avant de plonger dans les guides, voici les cinq erreurs que les équipes font le plus souvent. Les reconnaître maintenant vous évitera de les reproduire :
| Piège | Pourquoi c’est un problème | Le guide qui en parle |
|---|---|---|
| Dashboards “au cas où” avec 40 panels | Personne ne les regarde, impossible de trouver l’info utile en panne | Dashboards |
| Alerter sur CPU > 90 % au lieu du taux d’erreur | Réveil à 3h pour un spike qui n’impacte personne, fatigue d’alerte | Alerting |
| Alertes sans runbook associé | L’on-call 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 VMs | Labels à haute cardinalité, métriques inutiles, coûts explosifs | Observabilité K8s |
Niveaux de maturité opérationnelle
Section intitulée « Niveaux de maturité opérationnelle »Où en êtes-vous aujourd’hui ? Ce modèle simple vous aide à situer votre organisation et à identifier la prochaine étape :
| Niveau | Ce que vous avez | Ce qui manque | Guides prioritaires |
|---|---|---|---|
| 1 — Ad hoc | Dashboards par-ci par-là, alertes sur tout et rien | Pas de 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é K8s | Observabilité K8s |
| 4 — Optimisé | CI/CD sur les runbooks, alertes validées par tests, observabilité K8s complète | Amélioration continue, chaos engineering | Labs (prochaine section) |
La plupart des équipes sont au niveau 1 ou 2. Les pratiques de cette section vous amènent au niveau 3 ; les labs de la section suivante vous donnent les outils du niveau 4.
Vue d’ensemble
Section intitulée « Vue d’ensemble »| Guide | Question centrale | Ce que vous en retirez | Temps | Niveau |
|---|---|---|---|---|
| Dashboards utiles | Comment construire des vues qui servent ? | Hiérarchie overview → drill-down, variables, conventions | 18 min | Intermédiaire |
| Alerting efficace | Comment alerter sans fatiguer l’équipe ? | Symptom-first, burn rate, annotations, routing | 20 min | Intermédiaire |
| Runbooks et incidents | Comment structurer la réponse aux pannes ? | Template runbook, 4 rôles, postmortem blameless | 22 min | Intermédiaire |
| Observabilité Kubernetes | Quoi surveiller sur K8s ? | 4 couches, 5 signaux critiques, alertes prêtes | 20 min | Intermédiaire → Avancé |
Comment ces guides s’articulent
Section intitulée « Comment ces guides s’articulent »Les quatre guides de cette section forment une chaîne cohérente :
- Les dashboards définissent ce qu’on affiche — ils utilisent les frameworks RED et USE pour structurer les vues
- L’alerting définit les seuils et les règles — chaque alerte pointe vers un dashboard de diagnostic
- Les runbooks documentent la réponse — chaque runbook est lié à une alerte
via l’annotation
runbook_url - L’observabilité Kubernetes adapte ces pratiques au contexte spécifique des clusters — pods éphémères, labels dynamiques, control plane
Les annotations créent le lien technique : chaque alerte porte dashboard_url,
runbook_url, log_query_url, trace_query_url. L’on-call navigue de l’alerte
au diagnostic en un clic.
Les stacks pour les pratiques
Section intitulée « Les stacks pour les pratiques »Les pratiques de cette section sont indépendantes de l’outil choisi. Pour fixer les idées, voici ce que chaque outil apporte :
| Composant | Stack OSS typique | Stack SaaS typique |
|---|---|---|
| Dashboards | Grafana | Intégré (Datadog, New Relic) |
| Alerting | Prometheus Alertmanager | Intégré + PagerDuty/Opsgenie |
| Runbooks | Wiki (Notion, Confluence) ou Git | Idem |
| Incident management | Opsgenie, PagerDuty, incident.io | Intégré ou dédié |
| Postmortems | Templates Git/Wiki | Intégré ou dédié |
| K8s monitoring | kube-prometheus-stack | Intégré |
L’essentiel : les pratiques (RED dashboards, symptom-first alerting, runbooks structurés) restent identiques quelle que soit la stack.