Skip to content
NeuralSkills
Bereitstellung

Deployment-Post-Mortem

Fehlgeschlagene Deployments analysieren und Wiederholung verhindern — Incidents mit strukturierten, schuldfreien Retrospektiven in Lernchancen verwandeln.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Das Deployment ist fehlgeschlagen, der Incident behoben, und alle wollen weitermachen. Aber ohne ein strukturiertes Post-Mortem wiederholt sich dasselbe Fehlermuster — anderer Service, anderer Tag, gleiche Grundursache. Die meisten Teams ueberspringen Post-Mortems, weil sie sich wie Schuldzuweisungen anfuehlen, zu lange zum Schreiben brauchen oder Action Items produzieren, die nie erledigt werden. Das Ergebnis ist ein Team, das immer wieder dieselben Braende loescht.

Der Prompt

Du bist ein Incident-Analyse-Experte spezialisiert auf schuldfreie Post-Mortems. Hilf mir ein Post-Mortem fuer ein fehlgeschlagenes Deployment zu schreiben.

INCIDENT-DETAILS:
- Was passiert ist: [z.B. "Deploy von v2.4.0 verursachte 500-Fehler auf /api/checkout fuer 23 Minuten"]
- Auswirkung: [z.B. "~2.000 Nutzer betroffen, geschaetzter Umsatzverlust 15.000 EUR"]
- Zeitleiste: [Schluesselevents mit Zeitstempeln einfuegen]
- Grundursache (falls bekannt): [z.B. "Datenbankmigration sperrte die Orders-Tabelle"]
- Erkennung: [z.B. "Alert auf 5xx-Rate nach 8 Minuten, Kundenbericht nach 3 Minuten"]

Generiere ein schuldfreies Post-Mortem:
1. **Zusammenfassung**: 3-Satz-Zusammenfassung fuer die Fuehrungsebene.
2. **Zeitleiste**: Annotierte Zeitleiste mit Was, Wann und Wer.
3. **Ursachenanalyse**: 5-Whys-Methode zur Identifizierung der wahren Grundursache.
4. **Beitragende Faktoren**: Was die Situation verschlimmert hat.
5. **Was gut lief**: Anerkennung was funktioniert hat.
6. **Massnahmen**: Konkrete, zuweisbare Aufgaben zur Verhinderung der Wiederholung, mit Owner und Deadline.
7. **Erkenntnisse**: Was sich in Prozess, Tooling oder Kultur aendern sollte.

Beispielausgabe

Zusammenfassung:
Deploy v2.4.0 um 14:32 UTC verursachte 500-Fehler auf Checkout fuer 23 Minuten, betraf ~2.000 Nutzer (15.000 EUR geschaetzter Umsatzverlust). Grundursache: Datenbankmigration sperrte die Orders-Tabelle waehrend Spitzen-Traffic. Durch Rollback um 14:55 UTC behoben.

5 Whys:
1. Warum scheiterte Checkout? → Orders-Tabelle gesperrt
2. Warum war sie gesperrt? → ALTER TABLE fuegte NOT NULL-Spalte hinzu
3. Warum sperrte das? → 50 Mio Zeilen ohne Online-DDL neu geschrieben
4. Warum wurde Online-DDL nicht verwendet? → Kein Datenbankmigrations-Review-Prozess
5. Warum kein Review-Prozess? → Team nahm an, ORM behandelt es sicher ← GRUNDURSACHE

Massnahmen:
[P0] Datenbankmigrations-Review zur PR-Checkliste hinzufuegen — Owner: @alice — Frist: 22. Apr
[P1] Deploy-Freeze waehrend Spitzenzeiten implementieren (11-15 UTC) — Owner: @bob — Frist: 30. Apr

Wann einsetzen

Verwenden Sie diesen Skill nach jedem fehlgeschlagenen Deployment, bedeutenden Incident oder Beinahe-Ausfall. Das Ziel ist Lernen, nicht Schuld.

Profi-Tipps

  • Schuldfrei bedeutet nicht verantwortungslos — es geht darum Systeme und Prozesse zu verbessern. “Alice hat ohne Pruefung deployed” wird zu “unser Deploy-Prozess erfordert keinen Checklisten-Schritt.”
  • Schreiben Sie das Post-Mortem innerhalb von 48 Stunden — Details verblassen schnell.
  • Massnahmen muessen spezifisch und zugewiesen sein — “Monitoring verbessern” ist keine Massnahme. “Alert auf Orders-Table-Lock-Wait > 5 Sekunden hinzufuegen, Owner @carol, Frist 15. Mai” ist eine.
  • Teilen Sie Post-Mortems breit — der Wert eines Post-Mortems steigt exponentiell mit der Anzahl der Leser.