[Artículo] Observabilidad, SRE y gestión de incidentes

1. Observer ce que l'on livre #

You build it, you run it… et vous le voyez.

Les trois signaux #

Boucle de feedback — Chaque déploiement est observé et peut déclencher un retour arrière.

Signal	Répond à	Outils
Métriques	combien, à quelle vitesse, est-ce normal ?	Prometheus, Grafana, Datadog
Logs	que s'est-il passé exactement ?	Loki, Elasticsearch
Traces	où le temps est-il passé entre les services ?	OpenTelemetry, Tempo, Jaeger

Instrumentez avec OpenTelemetry pour ne pas dépendre d'un fournisseur, et ajoutez la version déployée comme attribut de ressource : on compare ainsi directement deux versions.

Golden signals #

Signal	Exemple
Latence	p95 des requêtes réussies
Trafic	requêtes par seconde
Erreurs	taux de réponses 5xx
Saturation	CPU, mémoire, files d'attente, connexions

2. SLO et budgets d'erreur #

Arbitrer vitesse et fiabilité avec des chiffres.

Définitions #

Notion	Exemple
SLI	part des requêtes servies en moins de 300 ms sans erreur
SLO	99,5 % sur 30 jours glissants
Budget d'erreur	0,5 % des requêtes, soit environ 3 h 36 d'indisponibilité totale par mois

Tant que le budget n'est pas consommé, l'équipe livre aussi vite qu'elle le souhaite. S'il est épuisé, la priorité passe à la fiabilité (gel des fonctionnalités risquées, correctifs). Le budget devient un outil de décision partagé entre produit et exploitation.

À savoir : La formation « SRE en pratique : SLI, SLO et budgets d'erreur » détaille le calcul des SLO et les alertes de burn rate.

3. Alertes et astreinte #

Réveiller quelqu'un seulement si c'est utile.

Des alertes actionnables #

Alerter sur les symptômes vécus par les utilisateurs (SLO, burn rate), pas sur chaque cause possible (CPU à 80 %).
Chaque alerte a un propriétaire et un runbook : que vérifier, comment atténuer.
Distinguer ce qui réveille la nuit (page) de ce qui attend le lendemain (ticket).
Revoir chaque mois les alertes bruyantes : une alerte ignorée est pire qu'aucune alerte.

# Prometheus : alerte de burn rate rapide sur un SLO à 99,5 %
- alert: BudgetErreurConsommeVite
  expr: |
    (sum(rate(http_requests_total{code=~"5.."}[1h])) / sum(rate(http_requests_total[1h]))) > (14.4 * 0.005)
    and
    (sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))) > (14.4 * 0.005)
  labels: { severity: page }
  annotations: { runbook_url: https://wiki.example.com/runbooks/api-erreurs }

Astreinte soutenable #

Rotation d'au moins 5 à 8 personnes, passation documentée.
Les développeurs du service participent à l'astreinte.
Mesurer le nombre de pages par semaine et le temps passé sur les interruptions (toil).

4. Gérer un incident #

Rétablir d'abord, comprendre ensuite.

Rôles et déroulé #

Rôle	Responsabilité
Responsable d'incident	coordonne, décide, ne corrige pas lui-même
Opérations	diagnostiquent et appliquent la mitigation
Communication	informe les utilisateurs et la direction à intervalles réguliers
Scribe	tient la chronologie

Déclarer l'incident et ouvrir un canal dédié.
Évaluer l'impact et la sévérité.
Atténuer au plus vite : retour arrière du dernier déploiement, désactivation d'un feature flag, bascule.
Rétablir le service, puis surveiller.
Rédiger le post-mortem sans blâme sous quelques jours et suivre les actions.

Bonne Pratique : La question « qu'est-ce qui a changé récemment ? » résout une grande partie des incidents : affichez les déploiements sur les tableaux de bord.