1. Observer ce que l'on livre #
You build it, you run it… et vous le voyez.
Les trois signaux #
| 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.
