Observability & SRE : comment éviter les incidents et gagner en sérénité

Il y a quelques années, quand un incident arrivait en prod, c’était toujours un peu la même scène.

Un Slack qui s’emballe.
Un commercial qui dit “le client X ne peut plus rien faire”.
Un CTO qui demande “c’est quoi l’impact ?”
Et une équipe tech qui répond… “on regarde”.

Traduction : on ne sait pas encore.
Ni quoi.
Ni pourquoi.
Ni depuis quand.

Et surtout : on subit.

Depuis, j’ai accompagné pas mal d’équipes sur des produits à fort trafic, à fort enjeu business, parfois très exposés (B2C, B2B critique, SaaS cœur de métier). Et s’il y a bien un sujet qui change radicalement la vie des équipes  et la relation avec le business c’est l’Observability, couplée à une vraie approche SRE.

Pas pour faire “comme les GAFAM”.
Mais pour arrêter de vivre chaque incident comme une crise existentielle.

‍

Le mythe : “on a du monitoring, donc on est bons”

‍

Quand j’arrive chez un client et que je pose la question :

“Comment vous détectez un incident aujourd’hui ?”

La réponse est souvent :

• “On a des alertes”
  
• “On a des dashboards”
  
• “On reçoit un mail quand ça tombe”
  
  

En réalité :

• les alertes sont trop nombreuses → plus personne ne les regarde
  
• les dashboards sont beaux → mais pas actionnables
  
• l’incident est souvent détecté… par le client
  
  

Ce n’est pas de l’observabilité.
C’est du monitoring passif.

‍

Observability : voir ce qui se passe sans savoir à l’avance ce qui va casser

‍

La différence clé, je la résume comme ça :

• Monitoring : je surveille ce que je connais
  
• Observability : je peux comprendre ce que je ne connais pas encore
  
  

Concrètement, l’observabilité repose sur 3 piliers (les fameux three pillars) :

1. Logs : ce que le système raconte
   
2. Metrics : ce que le système mesure
   
3. Traces : comment une requête traverse le système
   
   

Mais attention :
empiler des logs, des métriques et des traces sans intention, ça ne sert à rien.

La vraie question n’est pas “qu’est-ce qu’on peut mesurer ?”
Mais plutôt :

“Qu’est-ce qui nous empêche de dormir la nuit ?”

‍

SRE : arrêter de promettre le 100 % et devenir fiable

‍

Autre malentendu fréquent :
“SRE = zéro incident”.

Non.
SRE = accepter que les incidents arrivent, mais décider :

• quand,
  
• combien,
  
• et à quel coût.
  
  

C’est là qu’entrent en jeu trois notions clés :

‍

1. SLI – Service Level Indicator

Ce qu’on mesure réellement (ex : taux de requêtes réussies)

‍

2. SLO – Service Level Objective

Le niveau acceptable (ex : 99,9 % sur 30 jours)

‍

3. Error Budget

La marge d’erreur autorisée avant d’arrêter d’ajouter des features

Et ça change tout.

Parce qu’à partir de là :

• le business comprend qu’on choisit le niveau de risque
  
• la tech peut dire non avec des chiffres
  
• les priorités deviennent factuelles, pas émotionnelles
  
  

Vécu terrain : le jour où on a arrêté de courir partout

‍

Sur un produit e-commerce à fort CA, on avait :

• des incidents réguliers
  
• une équipe épuisée
  
• des post-mortems inutiles (“ça venait de la base”, fin du débat)
  
  

On a pris une décision simple (mais pas facile) :
1 sprint entier dédié uniquement à l’observabilité

Au programme :

• définir les parcours critiques business
  
• poser des SLI compréhensibles par tous
  
• instrumenter proprement les services
  
• réduire drastiquement le nombre d’alertes (mais les rendre actionnables)
  
  

Résultat après quelques semaines :

• les incidents n’avaient pas disparu
  
• mais ils étaient détectés plus tôt
  
• et surtout : on savait quoi regarder en premier
  
  

Le stress a baissé.
Les échanges avec le business se sont apaisés.
Et les incidents sont devenus… gérables.

‍

Ce qui marche (et ce qui ne marche pas)

‍

Ce qui ne marche pas

• Tout mesurer “au cas où”
  
• Avoir 50 alertes pour un même symptôme
  
• Laisser l’observabilité uniquement aux ops
  
• Ne jamais revoir ses SLO
  
  

Ce qui marche

• Partir des parcours utilisateurs critiques
  
• Définir peu d’indicateurs, mais les bons
  
• Lier les métriques techniques à l’impact business
  
• Faire vivre les post-mortems (sans chercher de coupable)
  
  

Gagner en sérénité, ce n’est pas magique (mais c’est possible)

‍

Observability & SRE, ce n’est pas :

• un outil magique
  
• une stack hors de prix
  
• une transformation instantanée
  
  

C’est :

• une discipline
  
• un changement de posture
  
• un contrat de confiance entre la tech et le business
  
  

Et quand c’est bien fait, on passe :

• de “ça a cassé”
  
• à “on a vu que ça allait casser, on a agi”
  
  

Et ça, franchement, ça change la vie.

‍