slo-implementation

Présentation de la compétence slo-implementation

La compétence slo-implementation vous aide à transformer des objectifs de fiabilité flous en Service Level Indicators (SLI), Service Level Objectives (SLO), budgets d’erreur et logiques d’alerte concrets. Elle convient particulièrement aux SRE, équipes plateforme, ingénieurs backend et responsables produit sensibles aux enjeux de fiabilité qui ont besoin d’une méthode reproductible pour définir ce que signifie réellement un niveau de santé de service « acceptable ».

À quoi sert la compétence slo-implementation

Utilisez la compétence slo-implementation lorsque vous devez :

• définir des objectifs de fiabilité mesurables pour un service
• choisir le bon type de SLI, par exemple disponibilité ou latence
• fixer une cible de SLO cohérente avec l’impact métier
• dériver un budget d’erreur à partir de cette cible
• mettre en place des alertes basées sur le burn rate ou la consommation du SLO

C’est plus utile qu’un prompt générique du type « écris-moi un SLO », car la compétence fournit une structure claire allant du SLI au SLO puis au SLA, tout en ancrant le travail dans des détails d’implémentation comme les fenêtres de mesure et les requêtes de style PromQL.

Pour qui l’installer

La slo-implementation skill est un très bon choix si vous disposez déjà de télémétrie, ou si vous pouvez en obtenir rapidement. Elle est particulièrement utile pour les équipes qui s’appuient sur des métriques de type Prometheus et qui veulent adopter des pratiques de fiabilité alignées sur le SRE sans avoir à inventer tout le cadre elles-mêmes.

Elle est moins utile si :

• vous n’avez pas encore de métriques de service réellement exploitables
• votre problème principal relève de la réponse à incident plutôt que de la définition de cibles de fiabilité
• vous avez seulement besoin d’un document de SLA juridique ou orienté client

Ce que les utilisateurs veulent surtout savoir avant de l’adopter

La plupart des utilisateurs qui évaluent slo-implementation install veulent savoir :

1. si la compétence apporte une aide concrète à la conception de SLO, et pas seulement de la théorie
2. si elle couvre aussi les détails d’implémentation comme les requêtes et les alertes
3. si elle aide à éviter de mauvais SLO, comme des objectifs de disponibilité purement cosmétiques
4. si elle reste assez concise pour s’intégrer dans un vrai workflow

Sur ces points, la compétence est pragmatique : elle couvre les types de SLI les plus courants, des exemples de définition de cibles, ainsi que le lien entre objectifs et budgets d’erreur.

Points forts et compromis

Le principal différenciateur de slo-implementation, c’est qu’elle reste centrée sur la mesure de la fiabilité et la conception de politiques, au lieu de dériver vers des conseils génériques d’observabilité. Ce focus la rend plus facile à invoquer correctement.

En contrepartie, la compétence n’est pertinente qu’à la hauteur du contexte service que vous lui fournissez. Si vous ne précisez pas les parcours utilisateurs, les patterns de trafic, les dépendances, les seuils et les noms de métriques, le résultat pourra sembler crédible sur le papier tout en restant difficile à rendre opérationnel.

Comment utiliser la compétence slo-implementation

Contexte d’installation de la compétence slo-implementation

Installez la compétence dans l’environnement où votre agent peut accéder aux compétences personnalisées. Un schéma courant consiste à :

1. ajouter le dépôt source à votre configuration de skills
2. activer la compétence slo-implementation
3. l’invoquer lorsque votre tâche consiste à définir ou réviser des SLI, SLO, budgets d’erreur ou alertes basées sur les SLO

Si votre outillage permet l’installation directe de skills, utilisez votre chargeur de skills habituel pour le dépôt suivant :
https://github.com/wshobson/agents/tree/main/plugins/observability-monitoring/skills/slo-implementation

Comme les éléments visibles dans le dépôt montrent uniquement un fichier SKILL.md pour cette compétence, prévoyez de lire ce fichier en priorité plutôt que de compter sur des scripts d’aide ou des ressources complémentaires.

Le fichier à lire en premier

Commencez par :

• plugins/observability-monitoring/skills/slo-implementation/SKILL.md

Ce fichier contient l’essentiel du slo-implementation guide : finalité, cas d’usage, hiérarchie SLI/SLO/SLA, types de SLI courants, exemples de cibles et modèles d’implémentation.

Les informations à fournir pour obtenir un résultat utile

Pour une slo-implementation usage de qualité, donnez à l’agent :

• le nom du service et ce que les utilisateurs en font
• les parcours utilisateurs les plus importants
• les métriques et labels actuellement disponibles
• les dashboards, alertes ou requêtes PromQL existants, le cas échéant
• le volume de trafic et sa saisonnalité
• la criticité métier et le coût d’une panne
• les attentes de latence par endpoint ou par opération
• les modes de défaillance connus
• si vous avez besoin de SLO internes, d’un alignement avec un SLA externe, ou des deux

Sans ces éléments, la compétence peut tout de même proposer un brouillon de SLO, mais elle aura tendance à se rabattre sur des cibles de disponibilité génériques et des SLI simplistes basés sur les requêtes.

Transformer un objectif vague en prompt solide

Prompt faible :

• « Create SLOs for my API. »

Meilleur prompt :

• « Use the slo-implementation skill to define SLIs and SLOs for a multi-tenant payments API. Our critical user journeys are charge creation and webhook delivery. We use Prometheus. Available metrics include http_requests_total, http_request_duration_seconds_bucket, and queue retry counters. Propose 2 to 3 SLIs, recommend SLO targets, calculate monthly error budgets, and suggest burn-rate alerts. Exclude admin endpoints and health checks.”

Pourquoi cela fonctionne :

• le périmètre du service est défini
• le prompt pointe vers de vraies métriques
• le champ est limité à des parcours utilisateurs réellement importants
• il demande précisément des livrables que la compétence est conçue pour produire

Le meilleur workflow pour une première utilisation

Un flux de slo-implementation usage pratique ressemble à ceci :

1. identifier un seul service, pas toute la plateforme
2. nommer 1 à 3 parcours utilisateurs critiques
3. faire correspondre chaque parcours aux signaux existants
4. demander à la compétence de proposer des SLI candidats
5. vérifier si ces SLI reflètent bien l’expérience utilisateur, et pas seulement l’état interne du système
6. définir une première cible de SLO et un budget d’erreur
7. rédiger la logique d’alerte
8. tester si les métriques disponibles permettent réellement de supporter cette conception
9. ajuster les seuils et les exclusions avant le déploiement

Cette approche évite un écueil fréquent : essayer de définir une politique de fiabilité à l’échelle de toute l’entreprise en une seule passe.

Ce que la compétence produit le mieux

La slo-implementation skill est particulièrement solide pour :

• proposer des modèles de SLI courants, comme la disponibilité et la latence
• expliquer les relations entre SLI, SLO et SLA
• traduire des objectifs de fiabilité en ratios mesurables
• suggérer des plages de cibles et un cadrage en budget d’erreur
• esquisser des alertes fondées sur la consommation du SLO

Elle est particulièrement utile lorsque vous avez besoin rapidement d’un premier brouillon exploitable, ancré dans le langage standard du SRE.

Là où les équipes se retrouvent souvent bloquées

L’adoption cale généralement pour l’une des raisons suivantes :

• l’équipe n’arrive pas à s’accorder sur la frontière du service vue par l’utilisateur
• seules des métriques d’infrastructure existent, pas de métriques liées aux parcours utilisateurs
• les histogrammes de latence manquent, ce qui fragilise les SLI basés sur des seuils
• les métriques incluent du trafic bot, des jobs internes ou des health checks qui faussent le numérateur et le dénominateur
• les cibles sont choisies pour des raisons politiques plutôt qu’en fonction du risque et du coût

La compétence peut aider à structurer la discussion, mais elle ne peut pas inventer une mesure fiable là où la télémétrie n’existe pas.

Des formulations de prompt concrètes qui améliorent la qualité du résultat

Demandez à la compétence de produire des sorties prêtes à la décision, par exemple :

• « List candidate SLIs with rationale and tradeoffs.”
• “Recommend one primary SLO and one secondary guardrail SLO.”
• “Show PromQL-style formulas for each SLI.”
• “Identify exclusions that should not count against the SLO.”
• “Suggest alerting windows for fast and slow burn.”

Ces formulations poussent la compétence vers un résultat de niveau implémentation, plutôt que vers des conseils abstraits sur la fiabilité.

Comment utiliser slo-implementation pour le travail de fiabilité

Pour slo-implementation for Reliability, utilisez-la dans les situations suivantes :

• avant le lancement d’un nouveau service
• pendant un chantier d’amélioration de l’observabilité
• après des incidents récurrents montrant que vos alertes actuelles sont trop bruyantes
• lorsque la direction demande des objectifs de fiabilité reliés à l’impact client
• lorsque vous devez relier la vélocité d’ingénierie à une politique de budget d’erreur

Elle a le plus de valeur lorsque l’équipe passe d’une logique de « tout monitorer » à une logique de « mesurer ce qui compte pour les utilisateurs ».

FAQ sur la compétence slo-implementation

slo-implementation est-elle meilleure qu’un prompt classique ?

Oui, si votre besoin porte spécifiquement sur la conception de SLI/SLO. Un prompt classique peut produire des définitions acceptables, mais slo-implementation a plus de chances de préserver la hiérarchie, d’inclure des formules mesurables et de relier les cibles aux budgets d’erreur et aux alertes.

La compétence slo-implementation est-elle adaptée aux débutants ?

Modérément. Les débutants peuvent l’utiliser, mais les meilleurs résultats viennent quand on maîtrise déjà les concepts SRE de base et qu’on dispose d’un minimum de contexte de télémétrie. Si vous débutez avec les SLO, utilisez d’abord la compétence sur un seul service et examinez chaque métrique proposée avant de l’adopter.

Faut-il utiliser Prometheus ?

Non, mais le contenu de la compétence s’aligne clairement bien avec une logique Prometheus et des raisonnements de style PromQL. Si vous utilisez Datadog, CloudWatch, Grafana ou une autre stack, vous pouvez malgré tout reprendre la logique et traduire les expressions de métriques dans votre plateforme.

Quand ne faut-il pas utiliser slo-implementation ?

N’utilisez pas slo-implementation comme outil principal si :

• vous avez besoin d’un texte de SLA à portée juridique
• vous n’avez aucune télémétrie de service exploitable
• votre vrai problème est l’ownership, pas la mesure
• votre service est encore trop immature pour définir des parcours utilisateurs stables

Dans ces cas-là, commencez par instrumenter, ou résolvez d’abord le problème de modèle opérationnel avant de formaliser des SLO.

Peut-elle aussi aider pour les alertes ?

Oui. La compétence ne se limite pas à la définition des cibles ; elle couvre aussi le volet opérationnel des budgets d’erreur et des alertes basées sur les SLO. C’est ce qui la rend plus utile qu’un simple modèle qui s’arrête à des pourcentages cibles.

Comment améliorer la compétence slo-implementation

Donnez du contexte métier, pas seulement des métriques techniques

Pour améliorer les résultats de slo-implementation, expliquez à l’agent ce que la fiabilité signifie d’un point de vue business :

• Quel workflow fait perdre du revenu lorsqu’il est dégradé ?
• Quels utilisateurs sont premium ou sensibles à la latence ?
• Quelle durée d’impact est tolérable ?

Cela aide la compétence à choisir des cibles réalistes, au lieu de retomber sur des chiffres ambitieux par défaut comme 99.99%.

Définissez explicitement les frontières du service

Une entrée de slo-implementation guide plus solide indique clairement ce qui compte et ce qui ne compte pas. Par exemple :

• inclure les requêtes d’écriture de l’API publique
• exclure /healthz, les routes d’administration et les batchs internes
• mesurer uniquement l’achèvement visible et réussi pour l’utilisateur, pas seulement l’acceptation de la requête

La clarté du périmètre est l’un des facteurs les plus déterminants pour qu’un SLO soit jugé crédible.

Fournissez les noms de métriques et des exemples de requêtes

La compétence devient beaucoup plus actionnable lorsque vous partagez la télémétrie réelle. Une bonne entrée comprend :

• les noms de métriques
• les dimensions de labels
• les buckets d’histogramme
• les requêtes d’alerte actuelles
• des liens vers les dashboards ou des extraits copiés

Cela permet de passer de SLO conceptuels à des définitions presque directement implémentables.

Évitez les SLI de façade

Un écueil fréquent consiste à choisir des métriques faciles à collecter mais faiblement liées à l’expérience utilisateur. Exemples :

• les redémarrages de pods
• la saturation CPU prise isolément
• l’uptime brut d’une dépendance sans lien explicite avec l’impact sur le service

Demandez à la compétence de justifier en quoi chaque SLI reflète la fiabilité perçue par l’utilisateur. Si elle n’y parvient pas, remplacez ce SLI.

Itérez après le premier brouillon

Le premier résultat produit par slo-implementation doit être traité comme un brouillon. Améliorez-le en posant des questions comme :

• « Which SLI is most representative of user harm?”
• “What would make this SLO impossible to measure accurately?”
• “Which exclusions are risky or easy to abuse?”
• “How would this change for low-traffic services?”
• “What alerting would reduce noise while protecting the error budget?”

Cette deuxième passe produit généralement une conception opérationnelle bien meilleure que le simple fait d’accepter le premier jeu de cibles.

Confrontez la proposition aux incidents historiques

L’un des meilleurs moyens d’améliorer le résultat de la slo-implementation skill consiste à comparer les SLI et alertes proposés à de vrais incidents. Demandez :

• ce SLO aurait-il détecté le problème ?
• aurait-il surcompté des échecs sans impact réel ?
• la politique de burn rate aurait-elle pagé trop tôt ou trop tard ?

Cette étape de validation transforme un document bien présenté en quelque chose qu’une équipe peut réellement exploiter.

Travaillez service par service

Si les résultats vous semblent génériques, le périmètre est probablement trop large. La compétence fonctionne le mieux lorsqu’elle se concentre sur un seul service ou un seul parcours utilisateur. Découpez les grands systèmes en plusieurs passes, puis standardisez les patterns ensuite.