Agent-almanac define-slo-sli-sla

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/de/skills/define-slo-sli-sla" ~/.claude/skills/pjt222-agent-almanac-define-slo-sli-sla-1d350c && rm -rf "$T"

manifest: i18n/de/skills/define-slo-sli-sla/SKILL.md

source content

SLO/SLI/SLA definieren

Messbare Zuverlaessigkeitsziele mit Service Level Objectives festlegen, mit Indikatoren verfolgen und Fehlerbudgets verwalten.

Wann verwenden

Zuverlaessigkeitsziele fuer kundenseitige Services oder APIs festlegen
Klare Erwartungen zwischen Service-Anbietern und Verbrauchern etablieren
Feature-Geschwindigkeit mit Systemzuverlaessigkeit durch Fehlerbudgets ausbalancieren
Objektive Kriterien fuer Incident-Schweregrad und -Reaktion erstellen
Von willkuerlichen Uptime-Zielen zu datengetriebenen Zuverlaessigkeitsmetriken migrieren
Site-Reliability-Engineering-Praktiken (SRE) implementieren
Servicequalitaet im Laufe der Zeit messen und verbessern

Eingaben

Pflichtfeld: Service-Beschreibung und kritische Benutzer-Journeys
Pflichtfeld: Historische Metrikdaten (Request-Raten, Latenzen, Fehlerquoten)
Optional: Bestehende SLA-Verpflichtungen gegenueber Kunden
Optional: Geschaeftsanforderungen fuer Service-Verfuegbarkeit und -Performance
Optional: Incident-Verlauf und Daten zu Kundenauswirkungen

Vorgehensweise

Unter Extended Examples sind vollstaendige Konfigurationsdateien und Templates verfuegbar.

Schritt 1: SLI-, SLO- und SLA-Hierarchie verstehen

Die Beziehungen und Unterschiede zwischen diesen drei Konzepten erlernen.

Definitionen:

SLI (Service Level Indicator)
- **What**: A quantitative measure of service behavior
- **Example**: Request success rate, request latency, system throughput
- **Measurement**: `successful_requests / total_requests * 100`

SLO (Service Level Objective)
- **What**: Target value or range for an SLI over a time window
- **Example**: 99.9% of requests succeed in 30-day window
- **Purpose**: Internal reliability target to guide operations

SLA (Service Level Agreement)
- **What**: Contractual commitment with consequences for missing SLO
- **Example**: 99.9% uptime SLA with refunds if breached
- **Purpose**: External promise to customers with penalties

Hierarchie:

SLA (99.9% uptime, customer refunds)
  ├─ SLO (99.95% success rate, internal target)
  │   └─ SLI (actual measured: 99.97% success rate)
  └─ Error Budget (0.05% failures allowed per month)

Schluessprinzip: Das SLO sollte strenger als das SLA sein, um einen Puffer zu bieten, bevor Kunden betroffen sind.

Beispiel:

SLA: 99,9 % Verfuegbarkeit (Kundenzusage)
SLO: 99,95 % Verfuegbarkeit (internes Ziel)
Puffer: 0,05 % Spielraum vor SLA-Verletzung

Erwartet: Team versteht Unterschiede, Einigung, welche Metriken zu SLIs werden, Abstimmung zu SLO-Zielen.

Bei Fehler:

Google-SRE-Buch-Kapitel zu SLI/SLO/SLA lesen
Workshop mit Stakeholdern zur Abstimmung ueber Definitionen durchfuehren
Mit einfachem Erfolgsquoten-SLI beginnen, bevor komplexe Latenz-SLOs erstellt werden

Schritt 2: Geeignete SLIs auswaehlen

SLIs auswaehlen, die Benutzererfahrung und Geschaeftsauswirkungen widerspiegeln.

Die vier goldenen Signale (Google SRE):

Latenz: Zeit zur Bearbeitung einer Anfrage

# P95 latency
histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Traffic: Nachfrage an das System

# Requests per second
sum(rate(http_requests_total[5m]))

Fehler: Rate fehlgeschlagener Anfragen

# Error rate percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) * 100

Saettigung: Wie "voll" das System ist

# CPU saturation
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))

Gaengige SLI-Muster:

# Availability SLI
availability:
  description: "Percentage of successful requests"
  query: |
    sum(rate(http_requests_total{status!~"5.."}[5m]))
    / sum(rate(http_requests_total[5m]))
  good_threshold: 0.999  # 99.9%

# Latency SLI
latency:
  description: "P99 request latency under 500ms"
  query: |
    histogram_quantile(0.99,
      sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
    ) < 0.5
  good_threshold: 0.95  # 95% of windows meet target

# Throughput SLI
throughput:
  description: "Requests processed per second"
  query: |
    sum(rate(http_requests_total[5m]))
  good_threshold: 1000  # Minimum 1000 req/s

# Data freshness SLI (for batch jobs)
freshness:
  description: "Data updated within last hour"
  query: |
    (time() - max(data_last_updated_timestamp)) < 3600
  good_threshold: 1  # Always fresh

SLI-Auswahlkriterien:

Benutzersichtbar: Spiegelt tatsaechliche Benutzererfahrung wider
Messbar: Kann aus vorhandenen Metriken quantifiziert werden
Handlungsorientiert: Team kann es durch Engineering-Arbeit verbessern
Bedeutsam: Korreliert mit Kundenzufriedenheit
Einfach: Leicht zu verstehen und zu erklaeren

Vermeiden:

Interne Systemmetriken, die Benutzern nicht sichtbar sind (CPU, Arbeitsspeicher)
Eitelkeitsmetriken, die keine Kundenauswirkungen vorhersagen
Uebermassig komplexe zusammengesetzte Bewertungen

Erwartet: 2-4 SLIs pro Service ausgewaehlt, mindestens Verfuegbarkeit und Latenz abdeckend, Team-Einigung zu Messabfragen.

Bei Fehler:

Benutzer-Journey abbilden, um kritische Ausfallpunkte zu identifizieren
Incident-Verlauf analysieren: Welche Metriken sagten Kundenauswirkungen voraus?
SLI mit A/B-Test validieren: Metrik verschlechtern, Kundenbeschwerden messen
Mit einfachem Verfuegbarkeits-SLI beginnen, Komplexitaet iterativ hinzufuegen

Schritt 3: SLO-Ziele und Zeitfenster festlegen

Realistische und erreichbare Zuverlaessigkeitsziele definieren.

SLO-Spezifikationsformat:

service: user-api
slos:
  - name: availability
    objective: 99.9
    description: |
      99.9% of requests return non-5xx status codes
# ... (see EXAMPLES.md for complete configuration)

Auswahl des Zeitfensters:

Gaengige Fenster:

30 Tage (monatlich): Typisch fuer externe SLAs
7 Tage (woechentlich): Schnelleres Feedback fuer Engineering-Teams
1 Tag (taeglich): Hochfrequente Services mit schneller Reaktion erforderlich

Beispiel-Fehlerbudget fuer 30-Tage-Fenster:

SLO: 99.9% availability over 30 days
Allowed failures: 0.1%
Total requests per month: 100M
Error budget: 100,000 failed requests
Daily budget: ~3,333 failed requests

Realistische Ziele setzen:

Aktuelle Performance als Ausgangspunkt nehmen:

# Check actual availability over past 90 days
avg_over_time(
  (sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m])))[90d:5m]
)
# Result: 99.95% → Set SLO at 99.9% (safer than current)

Kosten der Neunen berechnen:

99%    → 7.2 hours downtime/month (low reliability)
99.9%  → 43 minutes downtime/month (good)
99.95% → 22 minutes downtime/month (very good)
99.99% → 4.3 minutes downtime/month (expensive)
99.999% → 26 seconds downtime/month (very expensive)

Benutzer-Glueck gegenueber Engineering-Kosten abwaegen:
- Zu streng: Teuer, verlangsamt Feature-Entwicklung
- Zu locker: Schlechte Benutzererfahrung, Kundenverlust
- Optimaler Punkt: Etwas besser als Benutzererwartungen

Erwartet: SLO-Ziele mit Zustimmung der Geschaefts-Stakeholder gesetzt, mit Begruendung dokumentiert, Fehlerbudget berechnet.

Bei Fehler:

Mit erreichbarem Ziel beginnen (z. B. 99 %, wenn aktuell 98,5 %)
SLO-Ziele vierteljaehrlich basierend auf tatsaechlicher Performance iterieren
Fuehrungsunterstuetzung fuer realistische Ziele vs. "fuenf Neunen"-Anforderungen einholen
Kosten-Nutzen-Analyse fuer jede zusaetzliche Neun dokumentieren

Schritt 4: SLO-Monitoring mit Sloth implementieren

Sloth verwenden, um Prometheus-Recording-Rules und Alerts aus SLO-Spezifikationen zu generieren.

Sloth installieren:

# Binary installation
wget https://github.com/slok/sloth/releases/download/v0.11.0/sloth-linux-amd64
chmod +x sloth-linux-amd64
sudo mv sloth-linux-amd64 /usr/local/bin/sloth

# Or Docker
docker pull ghcr.io/slok/sloth:latest

Sloth-SLO-Spezifikation erstellen (

slos/user-api.yml

version: "prometheus/v1"
service: "user-api"
labels:
  team: "platform"
  tier: "1"
slos:
# ... (see EXAMPLES.md for complete configuration)

Prometheus-Regeln generieren:

# Generate recording and alerting rules
sloth generate -i slos/user-api.yml -o prometheus/rules/user-api-slo.yml

# Validate generated rules
promtool check rules prometheus/rules/user-api-slo.yml

Generierte Recording-Rules (Auszug):

groups:
  - name: sloth-slo-sli-recordings-user-api-requests-availability
    interval: 30s
    rules:
      # SLI: Ratio of good events
      - record: slo:sli_error:ratio_rate5m
# ... (see EXAMPLES.md for complete configuration)

Generierte Alerts:

groups:
  - name: sloth-slo-alerts-user-api-requests-availability
    rules:
      # Fast burn: 2% budget consumed in 1 hour
      - alert: UserAPIHighErrorRate
        expr: |
# ... (see EXAMPLES.md for complete configuration)

Regeln in Prometheus laden:

# prometheus.yml
rule_files:
  - "rules/user-api-slo.yml"

Prometheus neu laden:

curl -X POST http://localhost:9090/-/reload

Erwartet: Sloth generiert Multi-Window-Multi-Burn-Rate-Alerts, Recording-Rules werden erfolgreich ausgewertet, Alerts werden waehrend Incidents entsprechend ausgeloest.

Bei Fehler:

YAML-Syntax mit
```
yamllint slos/user-api.yml
```
validieren
Sloth-Versionskompatibilitaet pruefen (v0.11+ empfohlen)
Prometheus-Recording-Rule-Auswertung pruefen:
```
curl http://localhost:9090/api/v1/rules
```
Mit synthetischer Fehlerinjektion testen, um Alerts auszuloesen
Sloth-Dokumentation fuer das SLI-Ereignisabfrageformat pruefen

Schritt 5: Fehlerbudget-Dashboards erstellen

SLO-Compliance und Fehlerbudget-Verbrauch in Grafana visualisieren.

Grafana-Dashboard-JSON (Auszug):

{
  "dashboard": {
    "title": "SLO Dashboard - User API",
    "panels": [
      {
        "type": "stat",
# ... (see EXAMPLES.md for complete configuration)

Zu visualisierende Schluesselmetriken:

SLO-Ziel vs. aktueller SLI
Verbleibendes Fehlerbudget (prozentuell und absolut)
Burn-Rate (wie schnell das Budget erschoepft wird)
Historische SLI-Trends (gleitendes 30-Tage-Fenster)
Bis zur Erschoepfung verbleibende Zeit (bei aktueller Burn-Rate)

Dashboard fuer Fehlerbudget-Richtlinien (Markdown-Panel):

## Error Budget Policy

**Current Status**: 78% budget remaining

### If Error Budget > 50%
- ✅ Full speed ahead on new features
# ... (see EXAMPLES.md for complete configuration)

Erwartet: Dashboards zeigen Echtzeit-SLO-Compliance, Fehlerbudget-Abbau sichtbar, Team kann fundierte Entscheidungen zur Feature-Geschwindigkeit treffen.

Bei Fehler:

Recording-Rules pruefen:

curl http://localhost:9090/api/v1/rules | jq '.data.groups[].rules[] | select(.name | contains("slo:"))'

Prometheus-Datenquelle in Grafana auf korrekte URL pruefen
Abfrageergebnisse in der Explore-Ansicht validieren, bevor zum Dashboard hinzugefuegt wird
Sicherstellen, dass der Zeitbereich auf das entsprechende Fenster eingestellt ist (z. B. 30d fuer monatliche SLOs)

Schritt 6: Fehlerbudget-Richtlinie etablieren

Organisatorischen Prozess zur Verwaltung von Fehlerbudgets definieren.

Vorlage fuer Fehlerbudget-Richtlinien:

service: user-api
slo:
  availability: 99.9%
  latency_p99: 200ms
  window: 30 days

# ... (see EXAMPLES.md for complete configuration)

Richtliniendurchsetzung automatisieren:

# Example: Deployment gate script
import requests
import sys

def check_error_budget(service):
    # Query Prometheus for error budget
# ... (see EXAMPLES.md for complete configuration)

In CI/CD-Pipeline integrieren:

# .github/workflows/deploy.yml
jobs:
  check-error-budget:
    runs-on: ubuntu-latest
    steps:
      - name: Check SLO Error Budget
        run: |
          python scripts/check_error_budget.py user-api
      - name: Deploy
        if: success()
        run: |
          kubectl apply -f deploy/

Erwartet: Klare Richtlinie dokumentiert, automatisierte Gates verhindern riskante Deployments waehrend der Budget-Erschoepfung, Team-Abstimmung zu Zuverlaessigkeitsprioritaeten.

Bei Fehler:

Mit manueller Richtliniendurchsetzung beginnen (Slack-Erinnerungen)
Schrittweise mit weichen Gates automatisieren (Warnungen, keine Blockierungen)
Fuehrungsunterstuetzung vor harten Gates einholen (Deployments blockieren)
Richtlinieneffektivitaet vierteljaehrlich ueberpruefen, Schwellenwerte nach Bedarf anpassen

Validierung

Haeufige Stolperfallen

Zu strenge SLOs: "Fuenf Neunen" ohne Kostenanalyse setzen fuehrt zu Erschoepfung und verlangsamter Feature-Entwicklung. Erreichbar beginnen, iterativ steigern.
Zu viele SLIs: 10+ Indikatoren verfolgen schafft Verwirrung. Auf 2-4 kritische kundenseitige Metriken konzentrieren.
SLO ohne SLA-Puffer: SLO gleich SLA setzen laesst keinen Spielraum fuer Fehler vor Kundenauswirkungen. 0,05-0,1 % Puffer halten.
Fehlerbudget ignorieren: SLOs verfolgen, aber nicht auf Budget-Erschoepfung reagieren, macht den Zweck zunichte. Fehlerbudget-Richtlinie durchsetzen.
Eitelkeitsmetriken als SLIs: Interne Metriken (CPU, Arbeitsspeicher) statt benutzersichtbarer Metriken (Latenz, Fehler) verwenden, fuehrt zu Fehlausrichtung der Prioritaeten.
Kein Stakeholder-Buy-in: Nur Engineering-SLOs ohne Produkt/Geschaefts-Vereinbarung fuehren zu Konflikten. Fuehrungsunterstuetzung einholen.
Statische SLOs: Ziele niemals ueberpruefen oder anpassen, wenn das System sich weiterentwickelt. Vierteljaehrlich basierend auf tatsaechlicher Performance und Benutzerfeedback ueberpruefen.

Agent-almanac define-slo-sli-sla

SLO/SLI/SLA definieren

Wann verwenden

Eingaben

Vorgehensweise

Schritt 1: SLI-, SLO- und SLA-Hierarchie verstehen

Schritt 2: Geeignete SLIs auswaehlen

Schritt 3: SLO-Ziele und Zeitfenster festlegen

Schritt 4: SLO-Monitoring mit Sloth implementieren

Schritt 5: Fehlerbudget-Dashboards erstellen

Schritt 6: Fehlerbudget-Richtlinie etablieren

Validierung

Haeufige Stolperfallen

Verwandte Skills