Compétences observability-monitoring-slo-implement
📊

observability-monitoring-slo-implement

Sûr

Implémenter des SLO et des budgets d'erreur

Concevoir et implémenter des objectifs de niveau de service avec des SLI et des budgets d'erreur pour mesurer et améliorer la fiabilité du système tout en équilibrant la vélocité des fonctionnalités.

Prend en charge: Claude Codex Code(CC)
📊 69 Adéquat
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "observability-monitoring-slo-implement". Concevoir des SLO pour un nouveau service de checkout e-commerce

Résultat attendu:

Un framework SLO complet incluant : classification par niveau (critique), objectif de disponibilité (99,95%), SLI de latence (p95 < 500ms), SLI de taux d'erreur (< 0,1%), calcul du budget d'erreur (4,38 heures/mois) et seuils d'alerte de taux de consommation.

Utilisation de "observability-monitoring-slo-implement". Créer des règles d'enregistrement Prometheus pour le suivi SLO

Résultat attendu:

Configuration YAML avec des règles d'enregistrement pour le taux de requêtes, le taux de succès sur plusieurs fenêtres temporelles (5m, 30m, 1h), les percentiles de latence (p50, p95, p99) et les calculs de taux de consommation du budget d'erreur.

Audit de sécurité

Sûr
v1 • 2/24/2026

Static analysis detected 57 potential issues, but manual review confirms all findings are false positives. The skill contains documentation with Python code examples for SLO implementation - no actual executable code, no network calls, and no cryptographic operations. The placeholder URLs use example.com domain. This is a legitimate DevOps reliability skill.

2
Fichiers analysés
1,124
Lignes analysées
5
résultats
1
Total des audits
Problèmes à risque moyen (2)
resources/implementation-playbook.md:40resources/implementation-playbook.md:154-161SKILL.md:36SKILL.md:45
External Commands Detection in Documentation
Static scanner detected 'external_commands' pattern in markdown documentation. This is a false positive - the skill contains Python code examples in markdown blocks, not executable shell commands. The backtick syntax detected is part of Python f-strings and dictionary literals in documentation examples.
resources/implementation-playbook.md:969resources/implementation-playbook.md:970
Hardcoded URLs in Example Configuration
Static scanner detected placeholder URLs in YAML configuration examples. These are example.com domain URLs used as placeholders in documentation, not actual network endpoints.
Problèmes à risque faible (3)
resources/implementation-playbook.md:7resources/implementation-playbook.md:39SKILL.md:3
Numeric Pattern False Positives
Static scanner detected 'weak cryptographic algorithm' patterns at multiple locations. These are false positives - the numeric values detected (99.9%, 0.001, 14.4) are SLO availability targets and burn rate multipliers, not cryptographic algorithms.
resources/implementation-playbook.md:24SKILL.md:40
Documentation Language False Positive
Static scanner detected 'system reconnaissance' patterns. This is a false positive - words like 'analyze', 'assess', 'identify' are used in the legitimate context of service analysis for SLO design, not reconnaissance.
resources/implementation-playbook.md:1
Code Block Bracket Pattern
Static scanner detected 'obfuscation' pattern with multiple bracket chains. This is a false positive - the pattern detected is legitimate markdown code block formatting with Python dictionary and f-string syntax.
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
31
Communauté
89
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Définir des SLO pour un nouveau service API

Créer des SLO de disponibilité, de latence et de taux d'erreur avec des objectifs appropriés basés sur la criticité du service

Configurer l'alerting de budget d'erreur

Configurer des alertes de taux de consommation multi-fenêtres pour détecter la consommation rapide et lente du budget d'erreur

Établir un processus de revue SLO

Créer des modèles de revue SLO hebdomadaire et des processus de gouvernance pour les équipes d'ingénierie

Essayez ces prompts

Conception SLO de base 
Aidez-moi à concevoir des SLO pour mon service de traitement des paiements. Il gère 10 000 requêtes par minute et nécessite une haute fiabilité. Quel objectif de disponibilité devrais-je définir et comment définir les SLI ?
Implémentation SLI 
Je dois implémenter des SLI pour un service API REST utilisant Prometheus. Montrez-moi comment créer des requêtes SLI de disponibilité et de latence qui suivent le pourcentage de requêtes réussies et les requêtes sous 500ms.
Alertes de budget d'erreur 
Configurez des alertes de taux de consommation de budget d'erreur pour mon service avec un objectif SLO de 99,9%. J'ai besoin de règles d'alerte pour la consommation rapide (page immédiatement) et lente (créer un ticket).
Gouvernance SLO 
Établissez un framework de gouvernance SLO pour mon équipe avec les rôles et responsabilités, des modèles de revue hebdomadaire et des processus de communication avec les parties prenantes.

Bonnes pratiques

  • Commencer avec des objectifs SLO conservateurs et les resserrer en fonction des données de performance réelles du service
  • Utiliser plusieurs fenêtres temporelles pour les alertes de taux de consommation afin de détecter la consommation rapide et lente du budget
  • Aligner les objectifs SLO avec les priorités métier et les attentes des utilisateurs, pas avec la commodité technique

Éviter

  • Définir des objectifs SLO trop serrés initialement, entraînant des alertes constantes et la fatigue d'alerte
  • Utiliser uniquement des SLI de disponibilité sans considérer les métriques de latence ou de qualité
  • Créer des SLO sans alignement des parties prenantes ou contexte métier

Foire aux questions

Quelle est la différence entre un SLO et un SLA ?
Un SLO (Service Level Objective) est une cible interne à laquelle les équipes d'ingénierie s'engagent. Un SLA (Service Level Agreement) est un engagement contractuel envers les clients avec des conséquences financières en cas de violation.
Comment choisir le bon objectif de disponibilité SLO ?
Commencez par analyser la disponibilité historique, comprendre les attentes des utilisateurs et considérer l'impact métier. Les services critiques nécessitent généralement 99,95%+ tandis que les services standards peuvent cibler 99,5%.
Quelle fenêtre temporelle devrais-je utiliser pour les mesures SLO ?
Les fenêtres courantes sont 30 jours pour la disponibilité glissante ou des mois calendaires pour les périodes de facturation. Des fenêtres plus longues offrent de la stabilité mais un feedback plus lent sur les problèmes.
Comment gérer la maintenance planifiée dans les calculs SLO ?
Excluez les fenêtres de maintenance planifiée des mesures SLO ou utilisez des formules de disponibilité qui prennent en compte les temps d'arrêt attendus. Documentez clairement votre approche.
Que faire lorsque le budget d'erreur est épuisé ?
Mettez en pause le développement de fonctionnalités, concentrez-vous sur les améliorations de fiabilité et communiquez le statut aux parties prenantes. Utilisez la politique de budget d'erreur pour guider les décisions de release.
Combien de SLO un service devrait-il avoir ?
Commencez avec 2-4 SLO couvrant les aspects les plus importants面向用户 : disponibilité, latence et taux d'erreur. Ajoutez-en d'autres selon les besoins mais évitez la fatigue d'alerte.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/observability-monitoring-slo-implement

Réf

main

Structure de fichiers

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md