SRE & observabilité

Être réveillé pour les bonnes choses

Voir plus n'est pas le but. Ce dont une équipe d'exploitation a besoin, c'est d'être réveillée pour ce que les clients subissent vraiment, et qu'on lui laisse la paix le reste du temps. Cela commence par un objectif, pas par un outil.

Une alerte que personne ne traite apprend à tout ignorer.

Soixante à quatre-vingts pour cent des alertes sont des faux positifs, et un ingénieur d'astreinte reçoit une médiane de quarante-deux notifications par semaine. Le résultat n'est pas une équipe fatiguée, c'est une équipe qui ne lit plus, et le seul signal qui comptait passe inaperçu au milieu des soixante-trois qui ne valaient rien.

Nous prenons donc le problème par l'autre bout. Un objectif négocié avec le métier, un budget d'erreur qui rend l'arbitrage explicite, une alerte sur ce que le client subit plutôt que sur ce que la machine ressent, et une revue mensuelle qui supprime tout ce que personne n'a traité.

Ce que nous faisons

Quatre chantiers pour qu'une équipe d'exploitation soit réveillée pour les bonnes choses.

CHANTIER 01Négocié, pas décrété

Niveaux de service et budget d'erreur

Un objectif négocié avec le métier, mesuré du point de vue du client, avec un budget d'erreur qui dit combien d'échecs sont acceptables. C'est un choix métier, pas une décision technique.

mesuré sur le parcours client, pas sur le serveur

  • Un SLO par parcours critique
  • Un budget d'erreur et sa règle d'arbitrage
  • La livraison arbitrée sur le budget restant
CHANTIER 02Un seul fil

Observabilité de bout en bout

Des traces propagées du navigateur au dernier système, des métriques par étape et des journaux échantillonnés, pour qu'un incident se lise sur un seul fil plutôt que dans quatre consoles.

avec un budget de cardinalité, là où se cache la facture

  • Traces propagées à chaque saut
  • Métriques par étape du parcours
  • Un budget de cardinalité, posé avant la facture
CHANTIER 03Symptôme, pas cause

Une alerte qui mérite le réveil

Alerter sur le symptôme plutôt que sur la cause, gradué par la vitesse à laquelle le budget d'erreur se consomme. Ce qui n'appelle pas d'action devient un ticket, ou disparaît.

aucune alerte créée sans qu'une autre soit supprimée

  • Deux niveaux : réveiller, ou ouvrir un ticket
  • Revue mensuelle, alertes sans action supprimées
  • Aucun seuil sans action documentée
CHANTIER 04Corréler, pas accumuler

AIOps et analyse de cause racine

Des signaux corrélés automatiquement au lieu d'être additionnés, pour que l'investigation parte d'une hypothèse et non d'un tableau de bord. Ce qu'on gagne n'est pas la détection, c'est le délai avant le premier ordre.

le délai de décision se mesure comme le délai de détection

  • Corrélation automatique des traces, journaux et métriques
  • Cause racine proposée, puis confirmée par un humain
  • Post-mortem sans recherche de coupable, avec un responsable

Ce que vous recevez

Un même projet traverse les quatre livrables ci-dessous : la mise sous SLO d'un parcours de paiement. Chaque étape dit ce qui est réellement remis, dans l'ordre où on le remet.

01/ définir

Le niveau de service et son budget d'erreur

Disponibilité et latence mesurées du côté client, sur une fenêtre glissante, avec un budget de quarante-trois minutes par mois et la règle qui dit ce qui se passe quand les trois quarts sont consommés.

01-slo.yaml · parcours-paiement

parcours-paiement

  • 01-slo.yaml
  • 02-instrumentation.yaml
  • 03-alertes.yaml
  • 04-incident.yaml
# Un SLO se négocie avec le métier, pas avec l'équipe technique.
# Il dit combien d'échecs sont acceptables, ce qui est un choix.

parcours: paiement
mesure_du_point_de_vue: client final     # pas du serveur

objectifs:
  - nom: disponibilite
    cible: 99,9 %
    fenetre: 30 jours glissants
    budget_erreur: 43 minutes par mois

  - nom: latence
    cible: 95 % des paiements sous 1,2 s
    fenetre: 30 jours glissants

consommation_du_budget:
  usage: arbitrer, pas punir
  regle: >
    Budget consommé à plus de 75 % avant la fin de la fenêtre,
    les livraisons non critiques s'arrêtent jusqu'à reconstitution.

# Sans budget d'erreur, « on vise le zéro incident » se traduit par
# « on ne livre plus », ou par « on livre et on encaisse ». Le budget
# rend l'arbitrage explicite.
02/ instrumenter

L'instrumentation du parcours

Des traces propagées à chaque saut, des métriques par étape, des journaux échantillonnés et un budget de cardinalité. Une étiquette par identifiant client multiplie la facture par mille et n'aide personne à diagnostiquer.

02-instrumentation.yaml · parcours-paiement

parcours-paiement

  • 01-slo.yaml
  • 02-instrumentation.yaml
  • 03-alertes.yaml
  • 04-incident.yaml
# On instrumente le parcours, pas les serveurs. Ce qui compte est
# ce que le client subit, pas ce que la machine rapporte.

trace:
  propagation: de bout en bout, du navigateur à la banque
  identifiant: conservé à chaque saut, y compris via la file d'attente

metriques:
  par_etape: [taux d'erreur, latence p50, latence p95, latence p99]
  cardinalite_max: 40 valeurs par étiquette      # au-delà, coût et bruit

journaux:
  niveau_par_defaut: warn
  echantillonnage: 100 % des erreurs, 5 % du reste
  retention: 30 jours en chaud, 13 mois en froid

corrélation:
  regle: un incident se lit sur un seul fil, pas dans quatre consoles

# La cardinalité est le poste de coût qu'on découvre trop tard :
# une étiquette par identifiant client multiplie la facture par mille
# et n'aide personne à diagnostiquer.
03

Une alerte qui mérite le réveil

Deux niveaux seulement, et un critère de suppression écrit : toute alerte déclenchée cinq fois sans action est supprimée ou requalifiée. En créer une suppose d'en retirer une autre.

04

Un incident, rejoué

Quarante et une minutes d'indisponibilité partielle pour un budget mensuel de quarante-trois. Ce que le rejeu trouve n'est pas un signal manquant, et cela change toute la conclusion.

Comment on livre

PHASE 012 à 6 semaines

Définir

selon le nombre de parcours critiques et de systèmes traversés

  • SLO négociés avec le métier
  • Budget d'erreur et règle d'arbitrage
  • Cartographie des parcours critiques
PHASE 024 à 10 semaines

Instrumenter

selon la profondeur des traces et les systèmes à raccorder

  • Traces propagées de bout en bout
  • Alertes sur symptôme, pas sur cause
  • Un premier incident traité sur cette base
PHASE 033 à 6 mois

Réduire le bruit

selon le volume d'alertes existant et le nombre d'équipes d'astreinte

  • Alertes sans action supprimées ou requalifiées
  • Corrélation automatique des signaux
  • Astreinte dimensionnée sur des pages utiles
PHASE 04en continu

Tenir

engagement de service défini avec vous

  • Budget d'erreur suivi et arbitré
  • Post-mortem sans recherche de coupable
  • Revue mensuelle des alertes

À quoi ressemble vraiment une astreinte

60 à 80 %
de faux positifs sur les alertes, médiane du secteur : l'essentiel de ce qui réveille un ingénieur n'appelle rien
42
notifications par ingénieur d'astreinte et par semaine à la médiane, et 41 % d'entre eux ont envisagé de partir à cause de cette charge
−90 %
de volume d'alertes constaté quand les signaux sont corrélés au lieu d'être additionnés, le reste étant effectivement lu

Une production qu'on tient, pas qu'on surveille

Une charpente tient parce que chaque portique a été dimensionné, pas parce qu'on la regarde. C'est ce qu'une exploitation doit produire : un système où l'attention se porte là où elle sert, et nulle part ailleurs.

L'objectif avant l'outil. Un SLO par parcours critique et un budget d'erreur qui rend l'arbitrage de livraison explicite, plutôt qu'un tableau de bord sur lequel personne n'arbitre.

Des niveaux de service qui tiennent

Monter à 200 000 utilisateurs actifs sans lâcher le niveau de service
BforBankBanque en ligne
Performance
Cas(01)

Monter à 200 000 utilisateurs actifs sans lâcher le niveau de service

SLO de 99,99 % atteint · MTTR P1 divisé par trois

L'enjeu

Une banque en ligne du groupe Crédit Agricole en montée vers 200 000 utilisateurs actifs, où un ralentissement au moment d'un pic n'est pas un sujet de performance mais des clients qui n'accèdent plus à leurs comptes.

Notre réponse

Une équipe transverse performance et observabilité : les pics anticipés au lieu d'être encaissés, un délai de détection divisé par cinq, et un niveau de service qui tient pendant que la base d'utilisateurs est multipliée par quatre.

Lire l'étude de cas
Une performance éditoriale qui cesse de s'éroder de livraison en livraison
TéléramaMédias & presse
Performance web
Cas(02)

Une performance éditoriale qui cesse de s'éroder de livraison en livraison

−45 % de temps de chargement · 5 Core Web Vitals verts sur 6

L'enjeu

Un site éditorial dont la performance s'érodait à chaque livraison, sur un titre où le confort de lecture fait partie du produit, et où personne ne pouvait dire quel changement avait coûté quoi.

Notre réponse

La mesure branchée sur la chaîne de livraison plutôt que menée en audit : ce qui se dégrade se voit à la livraison suivante, et la maintenance garde la mesure en marche après la refonte.

Lire l'étude de cas
PARLER À UN EXPERT

Soyez réveillé pour les bonnes choses

Des niveaux de service négociés avec le métier, une observabilité qui se lit sur un seul fil, et une astreinte dimensionnée sur des notifications utiles.

En soumettant ce formulaire, vous acceptez notre politique de confidentialité.

Questions fréquentes

Par les objectifs. Un outil montre ce qu'on lui désigne, et sans niveau de service convenu, chaque incident s'arbitre dans l'instant. Un SLO négocié avec le métier est ce qui transforme un tableau de bord en décision.

À rendre l'arbitrage explicite. Viser zéro incident revient soit à ne plus livrer, soit à livrer et encaisser. Le budget dit combien d'échecs sont acceptables, et arrête les livraisons non critiques quand les trois quarts sont consommés.

Parce qu'une cause qui ne gêne aucun client ne mérite pas un réveil, et qu'un symptôme le mérite toujours. L'usage processeur seul ne dit rien de ce que vit un client, et c'est l'une des premières alertes que nous supprimons.

En supprimant ce que personne n'a traité. Une alerte déclenchée cinq fois sans action est supprimée ou transformée en ticket. Le risque n'est pas de rater un signal, c'est que l'utile passe inaperçu dans un flot que plus personne ne lit.

Non. Il corrèle les signaux et propose une cause racine, ce qui raccourcit le délai avant le premier ordre. La décision reste humaine, parce qu'agir sur un système critique d'après une suggestion de machine est exactement ce qu'un post-mortem regrette ensuite.

Surtout de la cardinalité. Une étiquette par identifiant client multiplie le volume par mille et n'aide personne à diagnostiquer. Le budget se pose à la conception, étiquette par étiquette, ce qui coûte bien moins cher que de le découvrir sur la facture.

Les définir prend 2 à 6 semaines selon le nombre de parcours critiques et de systèmes traversés, et produit les SLO, le budget d'erreur et la cartographie des parcours critiques. L'instrumentation et un premier incident traité sur cette base suivent en 4 à 10 semaines.