Teil D — Wie man betreibt. Zurück zur Übersicht.
Lernziel
Nach diesem Kapitel kennst du die Rollen und den Ablauf einer Störungsbearbeitung, kannst ein schuldfreies Postmortem schreiben und erklären, warum die Frage nach dem Schuldigen die Sicherheit eines Systems verringert. Du hast ein Runbook und ein Postmortem selbst verfasst.
Der Reiseführer im Anhalter durch die Galaxis trägt bekanntlich zwei beruhigende Worte auf dem Umschlag, und zwar aus einem guten Grund: In einer unübersichtlichen Lage ist Panik die einzige Reaktion, die die Lage zuverlässig verschlimmert.
Für Störungen im IT-Betrieb gilt dasselbe, und es ist keine Charakterfrage. Wer unter Druck improvisiert, trifft schlechtere Entscheidungen — das ist gut untersucht. Die Gegenmaßnahme heißt nicht Gelassenheit, sondern Vorbereitung: klare Rollen, festgelegte Abläufe, geschriebene Runbooks. Alles, was vorher entschieden wurde, muss während der Störung nicht mehr entschieden werden.
Auch bei kleinen Teams lohnt sich die Trennung — notfalls übernimmt eine Person mehrere Rollen, aber bewusst.
| Rolle | Aufgabe | Tut ausdrücklich nicht |
|---|---|---|
| Incident Commander | koordiniert, entscheidet, behält den Überblick | selbst am System arbeiten |
| Operations | arbeitet technisch an der Behebung | mit Stakeholdern kommunizieren |
| Communications | informiert Fachbereich, Leitung, Anwender | technische Entscheidungen treffen |
| Scribe | protokolliert Zeitpunkte, Maßnahmen, Erkenntnisse | mitdiskutieren |
Die wichtigste Regel: Der Incident Commander tippt nicht.
Der Reflex ist verständlich — die erfahrenste Person will helfen und legt selbst Hand an. Damit verliert die Störung ihre Koordination. Niemand hat mehr den Überblick, niemand spricht mit dem Fachbereich, und drei Personen probieren gleichzeitig widersprüchliche Dinge aus.
Der Incident Commander ist die Person mit dem besten Überblick, nicht mit dem meisten Fachwissen. Bei kleinen Störungen darf das derselbe Mensch sein — dann aber mit bewusstem Rollenwechsel und nicht nebenbei.
| Stufe | Bedeutung | Reaktion |
|---|---|---|
| Sev 1 | Totalausfall, Geschäftsbetrieb steht | sofort, auch nachts, alle Hebel |
| Sev 2 | wesentliche Funktion gestört, Umgehung möglich | sofort während der Geschäftszeit |
| Sev 3 | eingeschränkt, einzelne betroffen | am nächsten Arbeitstag |
| Sev 4 | Schönheitsfehler | im normalen Arbeitsvorrat |
Die Einstufung erfolgt nach Auswirkung, nicht nach technischer Dramatik. Ein ausgefallener Datenbankknoten, den der Cluster abgefangen hat, ist Sev 3. Ein Rechtschreibfehler im Prämienbescheid, der an 40.000 Kunden ging, kann Sev 1 sein.
Wichtig ist außerdem: Im Zweifel höher einstufen. Eine Herabstufung nach zehn Minuten ist billig; eine zu spät erkannte Sev 1 ist es nicht.
1. ERKENNEN Alarm, Anruf, Beobachtung
│ → Störung ausrufen, Rollen besetzen, Kanal öffnen
▼
2. EINDÄMMEN Auswirkung begrenzen
│ → Rollback, Feature-Flag aus, Verkehr umlenken
▼
3. WIEDERHER- Normalbetrieb zurückholen
STELLEN → nicht die Ursache beheben - den Betrieb!
│
▼
4. AUFARBEITEN Postmortem, Maßnahmen, Umsetzung
→ innerhalb weniger Tage, solange Erinnerung frisch
Schritt 2 und 3 kommen vor der Ursachenanalyse.
Der häufigste und teuerste Fehler bei Störungen ist der Versuch, erst zu verstehen und dann zu handeln. Neugier ist eine Berufstugend — während einer laufenden Störung ist sie eine Ausfallzeitverlängerung.
Erst wird zurückgerollt, umgeleitet oder abgeschaltet. Verstanden wird danach, in Ruhe, mit vollständigen Logs und ohne wartende Anwender. Die Logs laufen nicht weg; die Geduld des Fachbereichs schon.
Die einzige Ausnahme: Wenn völlig unklar ist, ob eine Maßnahme die Lage verbessert oder verschlimmert, ist kurzes Innehalten richtig. Das ist aber Abwägung, nicht Ursachenforschung.
Ein Runbook ist eine Handlungsanweisung für einen bekannten Störungsfall — geschrieben für den ungünstigsten Fall: Es ist drei Uhr nachts, die Person hat Bereitschaft, kennt dieses System nur oberflächlich und ist gerade aufgewacht.
# Runbook: KFZ-Rechner, hohe Fehlerrate
**Alarm:** HoheFehlerrate
**Schweregrad:** Sev 2 (Sev 1, wenn über 50 % und länger als 15 Minuten)
**Zuständig:** Team Bestandssysteme
## 1. Lage feststellen
curl -s https://kfz.intern/health
journalctl --user -u kfz-rechner.service --since "15 min ago" | tail -50
podman inspect kfz-rechner --format '{{.ImageName}}'
Grafana-Dashboard: https://grafana.intern/d/kfz
## 2. Häufigste Ursachen, nach Wahrscheinlichkeit
| Beobachtung im Log | Ursache | Maßnahme |
|-------------------------------|------------------------|-------------------|
| `connection refused` zur DB | Datenbank nicht da | Abschnitt 3.1 |
| `ValueError` gehäuft | fehlerhaftes Deployment| Abschnitt 3.2 |
| `pool exhausted` | Verbindungen erschöpft | Abschnitt 3.3 |
| keine Auffälligkeit | vorgelagertes System | Abschnitt 3.4 |
## 3. Maßnahmen
### 3.1 Datenbank nicht erreichbar
systemctl status postgresql # auf db-prod01
Ist die DB tatsächlich aus: Eskalation an Team Datenbanken, Sev 1.
### 3.2 Fehlerhaftes Deployment
Rollback (Dauer etwa 30 Sekunden):
cd ~/kfz-betrieb && git revert HEAD && git push
Der GitOps-Abgleich zieht binnen zwei Minuten nach.
Beschleunigen: `systemctl --user start gitops-abgleich.service`
### 3.3 Verbindungspool erschöpft
systemctl --user restart kfz-rechner.service
Tritt das mehr als einmal pro Woche auf: Ticket für Poolgröße anlegen.
### 3.4 Keine Auffälligkeit
Vorgelagerten Dienst prüfen, dann Eskalation an den Incident Commander.
## 4. Eskalation
- Rufbereitschaft Bestandssysteme: siehe Dienstplan
- Team Datenbanken: siehe Dienstplan
- Ab Sev 1: Leitung Anwendungsbetrieb informieren
## 5. Nach der Störung
Postmortem anlegen, wenn die Störung länger als 30 Minuten dauerte
oder Kunden betroffen waren.
Runbooks veralten schneller als jede andere Dokumentation. Der zuverlässigste Weg, sie aktuell zu halten: Jedes Postmortem prüft das verwendete Runbook und korrigiert es. War keines vorhanden, entsteht eines. Damit wächst die Sammlung genau dort, wo tatsächlich Störungen auftreten — und nicht dort, wo jemand einmal Zeit hatte.
Nach der Störung folgt die Aufarbeitung. Ihr Zweck ist ausschließlich, Wiederholung zu verhindern — nicht, Verantwortung zuzuweisen.
Das ist kein Wohlfühlargument, sondern ein sicherheitstechnisches. Wo Fehler Konsequenzen für Einzelne haben, geschieht Folgendes:
Der zentrale Perspektivwechsel: „Ein Kollege hat das falsche Kommando ausgeführt„ ist kein Ergebnis, sondern der Anfang der eigentlichen Untersuchung.
Die Anschlussfragen lauten: Warum war dieses Kommando so leicht zu verwechseln? Warum gab es keine Rückfrage vor einem zerstörenden Vorgang? Warum hatte diese Sitzung Produktionsrechte? Warum fiel es erst nach vierzig Minuten auf?
Menschliches Versagen ist nie die Ursache. Es ist das Symptom eines Systems, das Versagen zugelassen hat. Denn der nächste Mensch an dieser Stelle wird denselben Fehler machen — und Personalwechsel ist keine Sicherheitsmaßnahme.
Hinzu kommt der Rückschaufehler: Im Nachhinein wirkt die richtige Entscheidung offensichtlich. Während der Störung war sie es nicht. Ein brauchbares Postmortem rekonstruiert, welche Informationen den Beteiligten zum jeweiligen Zeitpunkt vorlagen.
# Postmortem: Ausfall KFZ-Rechner am 29.07.2026 **Schweregrad:** Sev 2 **Dauer:** 47 Minuten (14:32 - 15:19) **Betroffen:** etwa 2.400 Berechnungsanfragen, davon 340 abgebrochen **Verfasser:** [Name] **Status:** abgeschlossen ## Zusammenfassung Nach dem Ausrollen von Version 2.5.0 schlugen alle Berechnungen mit SF-Klasse 0 fehl. Ursache war eine Division durch null in der neuen Rabattlogik. Behoben durch Rollback auf 2.4.8. ## Zeitlicher Ablauf | Zeit | Ereignis | |-------|-------------------------------------------------------------| | 14:28 | Version 2.5.0 ausgerollt, Pipeline grün | | 14:32 | Alarm "HoheFehlerrate" ausgelöst | | 14:35 | Bereitschaft übernimmt, Störung ausgerufen | | 14:41 | Zusammenhang mit dem Deployment erkannt | | 14:44 | Entscheidung: Rollback | | 15:02 | Rollback abgeschlossen, Rückfrage im Team hatte verzögert | | 15:19 | Fehlerrate wieder normal, Störung geschlossen | ## Auswirkung 340 Anwender erhielten eine Fehlermeldung. Keine falschen Prämien berechnet, keine Datenverluste. ## Was ist passiert Die neue Wenigfahrer-Logik teilt durch den SF-Faktor. Bei SF-Klasse 0 ist dieser Faktor 0. Der Fall war in den Tests nicht abgedeckt, weil die Testdaten nur SF-Klassen ab 1 enthielten. ## Was gut lief - Der Alarm griff nach vier Minuten. - Das Runbook führte direkt zum Rollback-Abschnitt. - Der Fachbereich war nach acht Minuten informiert. ## Was schlecht lief - Das Rollback dauerte 18 statt der erwarteten 2 Minuten, weil unklar war, wer es freigeben muss. - Die Testdaten deckten den Randfall nicht ab. - Der Canary-Schritt war für diesen Dienst nicht eingerichtet. ## Wo wir Glück hatten Der Fehler trat sofort auf. Bei einem Fehler, der nur jede tausendste Berechnung falsch macht, hätten wir ihn womöglich wochenlang nicht bemerkt - mit falsch berechneten Prämien als Folge. ## Maßnahmen | # | Maßnahme | Wer | Bis | |---|-------------------------------------------------|--------|------------| | 1 | Testdaten um SF-Klasse 0 und Randfälle ergänzen | A. K. | 05.08.2026 | | 2 | Rollback-Freigabe im Runbook eindeutig regeln | M. R. | 02.08.2026 | | 3 | Canary-Schritt für den KFZ-Rechner einrichten | Team | 31.08.2026 | | 4 | Grenzwerttests als Pflicht in die Definition of | | | | | Done aufnehmen | Team | 15.08.2026 |
Die beiden Abschnitte „Was gut lief“ und „Wo wir Glück hatten„ werden gern weggelassen. Beide sind wertvoll: Der erste bewahrt funktionierende Praktiken davor, im Zuge von Verbesserungen versehentlich abgeschafft zu werden. Der zweite deckt Risiken auf, die diesmal folgenlos blieben — und beim nächsten Mal nicht.
| Regel | Begründung |
|---|---|
| Bereitschaft wird vergütet oder ausgeglichen | sonst wird sie stillschweigend abgebaut |
| Wer entwickelt, ist auch erreichbar | schärft das Interesse an guter Alarmierung |
| Höchstens ein bis zwei Weckrufe pro Bereitschaft | mehr ist ein Zeichen fehlender Stabilität |
| Nach einer Nachtstörung: Ausgleich am Folgetag | Übermüdete verursachen Folgestörungen |
| Jeder Weckruf wird ausgewertet | Ursache beheben statt Symptom ertragen |
Die dritte Zeile ist die wichtigste Kennzahl der Bereitschaft. Wer regelmäßig fünfmal pro Nacht geweckt wird, hat kein Bereitschaftsproblem, sondern ein Qualitätsproblem — und Bereitschaft ist dann lediglich das Verfahren, mit dem es verwaltet statt gelöst wird.
Aufgabe 1 — Runbook. Schreibe ein Runbook für einen Alarm aus Kapitel 12. Gib es jemandem, der das System nicht kennt, und lass es durcharbeiten. Jede Rückfrage ist eine Lücke.
Aufgabe 2 — Störungsübung. Verabredet euch zu einer festen Zeit. Eine Person baut heimlich einen Fehler ein — falsches Image, gestoppte Datenbank, gefülltes Dateisystem. Der Rest bearbeitet die Störung mit besetzten Rollen. Stoppt die Zeit bis zur Erkennung und bis zur Wiederherstellung.
Aufgabe 3 — Postmortem. Schreibe zur Übungsstörung ein vollständiges Postmortem nach der Vorlage. Achte darauf, dass in der Ursachenbeschreibung kein Name vorkommt.
Aufgabe 4 — Prüfung. Lies ein echtes Postmortem aus deinem Betrieb, falls vorhanden. Endet es bei einem menschlichen Fehler oder bei einer Systemeigenschaft?
| Anti-Pattern | Folge | Abhilfe |
|---|---|---|
| Ursachensuche vor Wiederherstellung | Ausfallzeit verlängert sich | erst eindämmen |
| Incident Commander tippt mit | niemand koordiniert | Rollen trennen |
| Postmortem endet beim Menschen | dieselbe Störung kommt wieder | nach Systemursachen fragen |
| Maßnahmen ohne Termin und Verantwortliche | werden nie umgesetzt | Tabelle mit Wer und Bis |
| Kein Postmortem bei „nur kurzen“ Störungen | Beinahe-Vorfälle gehen verloren | feste Schwelle vereinbaren |
| Runbooks veralten | Bereitschaft steht ohne Anleitung da | im Postmortem mitpflegen |
| Bereitschaft ohne Ausgleich | Erschöpfung, Kündigungen | vergüten und begrenzen |
| Alle telefonieren durcheinander | Erkenntnisse gehen verloren | ein Kanal, ein Protokoll |
Denk an die letzte größere Störung in deinem Umfeld. Gibt es dazu ein schriftliches Ergebnis — und wurde daraus tatsächlich etwas umgesetzt?
Ein Postmortem ohne umgesetzte Maßnahmen ist ein Aufsatz. Die Maßnahmentabelle ist der einzige Teil, der Wirkung entfaltet.
Weiter mit Kapitel 14 — DevSecOps