Fähigkeiten observability-monitoring-slo-implement
📊

observability-monitoring-slo-implement

Sicher

Implementieren von SLOs und Fehlerbudgets

Entwerfen und Implementieren von Service Level Objectives mit SLIs und Fehlerbudgets zur Messung und Verbesserung der Systemzuverlässigkeit bei gleichzeitiger Balance zwischen Feature-Geschwindigkeit und Stabilität.

Unterstützt: Claude Codex Code(CC)
📊 69 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "observability-monitoring-slo-implement". Design SLOs for a new e-commerce checkout service

Erwartetes Ergebnis:

Ein umfassendes SLO-Framework einschließlich: Tier-Klassifikation (kritisch), Verfügbarkeitsziel (99,95%), Latenz-SLIs (p95 < 500ms), Fehlerraten-SLI (< 0,1%), Fehlerbudget-Berechnung (4,38 Stunden/Monat) und Burn-Rate-Warnschwellenwerte.

Verwendung von "observability-monitoring-slo-implement". Create Prometheus recording rules for SLO tracking

Erwartetes Ergebnis:

YAML-Konfiguration mit Recording-Regeln für Anfragerate, Erfolgsrate bei mehreren Zeitfenstern (5m, 30m, 1h), Latenz-Perzentile (p50, p95, p99) und Fehlerbudget-Burn-Rate-Berechnungen.

Sicherheitsaudit

Sicher
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
Gescannte Dateien
1,124
Analysierte Zeilen
5
befunde
1
Gesamtzahl Audits
Probleme mit mittlerem Risiko (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.
Probleme mit niedrigem Risiko (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.
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
31
Community
89
Sicherheit
91
Spezifikationskonformität

Was du bauen kannst

Definieren von SLOs für einen neuen API-Dienst

Erstellen von Verfügbarkeits-, Latenz- und Fehlerraten-SLOs mit geeigneten Zielen basierend auf Service-Kritikalität

Einrichten von Fehlerbudget-Warnungen

Konfigurieren von Multi-Window-Burn-Rate-Warnungen zur Erkennung von schnellem und langsamem Fehlerbudget-Verbrauch

Etablieren von SLO-Review-Prozessen

Erstellen von wöchentlichen SLO-Review-Vorlagen und Governance-Prozessen für Engineering-Teams

Probiere diese Prompts

Grundlegendes SLO-Design 
Helfen Sie mir, SLOs für meinen Zahlungsabwicklungsdienst zu entwerfen. Er verarbeitet 10.000 Anfragen pro Minute und erfordert hohe Zuverlässigkeit. Welches Verfügbarkeitsziel sollte ich setzen und wie definiere ich die SLIs?
SLI-Implementierung 
Ich muss SLIs für einen REST-API-Dienst mit Prometheus implementieren. Zeigen Sie mir, wie ich Verfügbarkeits- und Latenz-SLI-Abfragen erstelle, die den Prozentsatz erfolgreicher Anfragen und Anfragen unter 500ms verfolgen.
Fehlerbudget-Warnungen 
Konfigurieren Sie Fehlerbudget-Burn-Rate-Warnungen für meinen Dienst mit einem 99,9% SLO-Ziel. Ich benötige sowohl Fast-Burn- (sofortige Benachrichtigung) als auch Slow-Burn- (Ticket erstellen) Warnregeln.
SLO-Governance 
Etablieren Sie ein SLO-Governance-Framework für mein Team mit Rollen und Verantwortlichkeiten, wöchentlichen Review-Vorlagen und Stakeholder-Kommunikationsprozessen.

Bewährte Verfahren

  • Beginnen Sie mit konservativen SLO-Zielen und verschärfen Sie diese basierend auf tatsächlichen Service-Performance-Daten
  • Verwenden Sie mehrere Zeitfenster für Burn-Rate-Warnungen, um sowohl schnellen als auch langsamen Budgetverbrauch zu erkennen
  • Richten Sie SLO-Ziele an Geschäftsprioritäten und Benutzererwartungen aus, nicht an technischer Bequemlichkeit

Vermeiden

  • Zu enge SLO-Ziele von Anfang an setzen, was zu ständigen Warnungen und Warnmüdigkeit führt
  • Nur Verfügbarkeits-SLIs verwenden ohne Latenz- oder Qualitätsmetriken zu berücksichtigen
  • SLOs ohne Stakeholder-Abstimmung oder Geschäftskontext erstellen

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem SLO und einem SLA?
Ein SLO (Service Level Objective) ist ein internes Ziel, zu dem sich Engineering-Teams verpflichten. Ein SLA (Service Level Agreement) ist eine vertragliche Verpflichtung gegenüber Kunden mit finanziellen Konsequenzen bei Verletzung.
Wie wähle ich das richtige SLO-Verfügbarkeitsziel aus?
Beginnen Sie mit der Analyse historischer Verfügbarkeit, dem Verständnis von Benutzererwartungen und der Berücksichtigung von Geschäftsauswirkungen. Kritische Dienste benötigen typischerweise 99,95%+ während Standarddienste 99,5% anstreben können.
Welches Zeitfenster sollte ich für SLO-Messungen verwenden?
Gängige Fenster sind 30 Tage für rollierende Verfügbarkeit oder Kalendermonate für Abrechnungszeiträume. Längere Fenster bieten Stabilität, aber langsamere Feedback-Zyklen bei Problemen.
Wie gehe ich mit geplanter Wartung in SLO-Berechnungen um?
Planen Sie geplante Wartungsfenster aus SLO-Messungen aus oder verwenden Sie Verfügbarkeitsformeln, die erwartete Ausfallzeiten berücksichtigen. Dokumentieren Sie Ihren Ansatz klar.
Was sollte ich tun, wenn das Fehlerbudget erschöpft ist?
Pausieren Sie die Feature-Entwicklung, konzentrieren Sie sich auf Zuverlässigkeitsverbesserungen und kommunizieren Sie den Status an Stakeholder. Verwenden Sie die Fehlerbudget-Richtlinie, um Release-Entscheidungen zu leiten.
Wie viele SLOs sollte ein Dienst haben?
Beginnen Sie mit 2-4 SLOs, die die wichtigsten benutzerorientierten Aspekte abdecken: Verfügbarkeit, Latenz und Fehlerrate. Fügen Sie bei Bedarf weitere hinzu, vermeiden Sie aber Warnmüdigkeit.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

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

Ref

main

Dateistruktur

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md