Observabilité, SRE et gestion des incidents

1. Observer ce que l'on livre #

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

Les trois signaux #

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 #

2. SLO et budgets d'erreur #

Arbitrer vitesse et fiabilité avec des chiffres.

Définitions #

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é #

1. Déclarer l'incident et ouvrir un canal dédié.
2. Évaluer l'impact et la sévérité.
3. Atténuer au plus vite : retour arrière du dernier déploiement, désactivation d'un feature flag, bascule.
4. Rétablir le service, puis surveiller.
5. 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.