Ein Runbook führt von einem bestimmten Symptom zu einer sicheren Entscheidung.
Ein Runbook führt von einem bestimmten Symptom zu einer sicheren Entscheidung. Es ist keine ungeordnete Befehlssammlung. Schreiben Sie für eine Person mit den erwarteten Rechten und Fähigkeiten, die müde sein oder die Komponente noch nicht gut kennen kann.
Mit Signal und Wirkung beginnen
Benennen Sie Alarm, betroffenen Ablauf und Gültigkeitsbedingungen. Verlinken Sie das relevante Dashboard und erklären Sie, welche Beobachtung ähnliche Ursachen unterscheidet. Ergänzen Sie Eigentümer, Prüfdatum und Eskalation. Die Anleitung muss erreichbar sein, wenn die Hauptanwendung ausfällt; ihr Speicherort ist damit Teil der Betriebsplanung.
Voraussetzungen und Abbruchregeln nennen
Beschreiben Sie benötigte Rechte, sichere Umgebungswahl und Freigaben für folgenreiche Änderungen. Legen Sie fest, wann unerklärliche Datenänderungen, fehlende Sicherung oder widersprüchliche Ergebnisse zur Eskalation führen. Speichern Sie keine Geheimnisse im Dokument. Jede Aktion braucht Zweck, erwartetes Ergebnis und nächsten Entscheidungspfad, einschließlich Auswirkung auf laufende Arbeit.
Wiederherstellung und Pflege einbauen
Bei Neustart, Wiederholung oder Umschaltung muss klar sein, wie doppelte Verarbeitung verhindert und eine Änderung gegebenenfalls zurückgenommen wird. Prüfen Sie Kundenreise und liegen gebliebene Aufgaben, dokumentieren Sie Aktionen und Restpunkte. Lassen Sie eine zweite Person die Anleitung sicher erproben. Aktualisieren Sie sie nach relevanten Releases und Vorfällen; eine kurze getestete Anleitung ist belastbarer als eine lange veraltete Sammlung.
Ein konkreter Abnahmetest
Für eine wachsende Warteschlange sollte die Anleitung zunächst zwischen fehlenden Workern, langsamer externer Abhängigkeit und wiederholt scheiternden Einzelaufträgen unterscheiden. Ein pauschaler Neustart kann diese Ursachen verdecken oder zusätzliche Wiederholungen erzeugen. Nennen Sie die Messung, die jeden Zweig bestätigt, und den sicheren nächsten Schritt. Die Übung gilt erst als bestanden, wenn eine zweite Person den richtigen Zweig findet und anschließend sowohl die Warteschlangenentwicklung als auch das Geschäftsergebnis überprüft. Nicht verstandene Ausgaben oder fehlende Rechte werden als Verbesserungen der Anleitung erfasst.
- Passende Leistung
- Bereitschaft für Startups ohne eigenes SRE-Team
- Schweregrade für Vorfälle: eine Eskalationsmatrix
Häufige Fragen
Gehören Befehle hinein?
Ja, wenn geprüft und mit Voraussetzungen, Umfang und erwartetem Ergebnis beschrieben.
Wie lang sollte es sein?
So lang wie der konkrete Entscheidungspfad verlangt, ohne fremde Details zu verstecken.
Wer sollte testen?
Eine andere Person mit den erwarteten Rechten und Fähigkeiten.
Was bei abweichender Realität?
An der definierten Grenze stoppen, Belege sichern und eskalieren.
Wann aktualisieren?
Nach relevanten Änderungen, Übungen und Vorfällen.
Vom Vorhaben zu einem umsetzbaren Umfang
Teilen Sie Nutzerablauf, Schnittstellen und Rahmenbedingungen. Gemeinsam klären wir den Umfang und erstellen eine Schätzung mit Annahmen und Ausschlüssen.
Weiterführend
Bereitschaft für Startups ohne eigenes SRE-Team
Ein kleines Team kann verlässliche Bereitschaft organisieren, wenn Zusagen zu Personal und Werkzeugen passen.
Schweregrade für Vorfälle: eine Eskalationsmatrix
Der Schweregrad eines Vorfalls sollte seine Geschäftsauswirkung beschreiben, nicht die dramatische Formulierung einer Logmeldung.
Rollback oder Hotfix im Produktionsvorfall?
Wählen Sie im Vorfall die Maßnahme, die akzeptablen Betrieb mit kontrolliertem Risiko am wahrscheinlichsten wiederherstellt.