# Runbooks und sichere Automatisierung

> Wiederholbare Diagnose und begrenzte Automatisierung mit Freigaben, Guardrails und Verifikation gestalten.

Track: [Monitoring, Troubleshooting & Incident Operations](https://opsmith.app/learn/monitoring-incident-operations)  
Kanonische Fassung: https://opsmith.app/learn/monitoring-incident-operations/runbook-automation  
Stand: 2026-07-30  
Interaktiver Teil: 3 Checks (nur im Browser)

## Automatisieren ohne den Blast Radius zu verstecken

### Die Betriebsfrage

Ein Runbook verkürzt Wiederholarbeit nur dann sicher, wenn Eingangssignal, Voraussetzungen, Wirkung, Stop-Kriterium und Verifikation explizit sind. Automatisierung ist keine Lizenz für globale Änderungen.

> **Lernziel:** Du kannst entscheiden, wann ein Runbook nur Evidenz sammeln, eine reversible Aktion ausführen oder an einen Menschen eskalieren muss.

### Sicherer Automationsvertrag

Signal und Zielressource validieren → Voraussetzungen und Freigabe prüfen → Kleinste reversible Aktion ausführen → Wirkung gegen SLI oder Gesundheitscheck prüfen → Ergebnis und Kontext in die Zeitlinie schreiben

### Guardrails

Idempotenz, Scope-Grenzen, Rate Limits und eine sichtbare Auditspur sind Betriebsanforderungen. Wenn die Identität der Zielressource unsicher ist, darf ein Runbook keinen schreibenden Schritt ausführen.

### Im Check

Du unterscheidest Erhebung, Remediation und Eskalation. Die richtige Antwort ist nicht immer die schnellste, sondern die mit belegter Wirkung und begrenztem Risiko.

## Quellen

- sre.google/workbook/automation-at-google — https://sre.google/workbook/automation-at-google/
- sre.google/sre-book/eliminating-toil — https://sre.google/sre-book/eliminating-toil/