Was vorher fertig sein muss
Ein Baseline- oder Soll-Zustand ist bekannt und reproduzierbar (z. B. erfolgreicher Build, vergleichbarer Vorgang, vergleichbarer Tag).
Eine chronologische Aufnahme des fehlerhaften Vorgangs liegt vor, damit Veränderungen zeitlich verortet werden können.
Was vor Start vorliegen muss
Whiteboard oder Tabelle mit drei Spalten (Soll, Ist, Differenz); Zugang zu Versionssystemen, Konfigurationsständen, Deploy-Logs, Mitarbeiter-Schichtplänen; Vorlage für Differenz-Liste.
Ein Lead-Investigator; 2-5 Personen mit Kenntnis der Veränderungsbereiche (Engineering, Ops, Daten, Lieferant); ein Scribe; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.
Was funktionierte zuletzt, was funktioniert jetzt nicht; Zeitraum der Abweichung; Liste der bekannten Veränderungen seit Baseline (Deploys, Configs, Personal, Daten, externe Systeme); Logs und Diffs.
60-180 min, je nach Komplexität
Tabelle mit Soll-, Ist- und Differenz-Spalten anlegen. Kategorien als Zeilen: Code, Konfiguration, Daten, Infrastruktur, Personal, Lieferant, Umfeld, Prozess. Anweisung: pro Zeile Soll und Ist möglichst konkret, Differenz mit Quelle und Zeitstempel.
Die eine Frage, die diese Methode beantwortet
Welche Unterschiede zwischen Soll- und Ist-Zustand erklären die beobachtete Abweichung, und welche dieser Differenzen sind ursächlich, beitragend oder zufällig?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Baseline und Ist-Zustand erfassen | 20-30 min | Baseline-Zustand (wann funktionierte es zuletzt) und Ist-Zustand pro Kategorie konkret beschreiben. Versions-IDs, Konfigurations-Hashes, Personalbesetzungen, Umfeldbedingungen. | Wenn Baseline nicht konkret rekonstruierbar ist, Change Analysis funktioniert nicht. Lieber Wochenarbeit für saubere Baseline als oberflächliche Vermutungen. |
2Phase 2: Differenzen auflisten | 30-60 min | Pro Kategorie alle Differenzen zwischen Soll und Ist notieren. Auch scheinbar irrelevante Änderungen erfassen (Library-Update, neue Person im Team, geänderter Lieferanten-Service). | Häufiger Fehler: nur die offensichtlichen Änderungen erfassen. Differenzen wie „neuer Sicherheitspatch in OS“ oder „NTP-Server gewechselt“ tauchen oft erst bei systematischer Liste auf. |
3Phase 3: Differenzen bewerten | 30-45 min | Pro Differenz: ursächlich plausibel, beitragend, zufällig. Begründung pro Bewertung. Bei mehreren plausiblen Ursachen Reihenfolge der Prüfung festlegen. | Confirmation Bias vermeiden: die offensichtlichste Differenz ist nicht automatisch die Ursache. Pro Differenz prüfen: wann wirkt diese Veränderung, passt das zur Timeline. |
4Phase 4: Hypothese testen | 30-90 min | Verdächtige Differenz isoliert prüfen: Rollback in Staging, A/B-Vergleich, gezielter Test. Ergebnis dokumentieren. | Testen statt vermuten. Wenn Test nicht möglich, mindestens Plausibilität anhand Timeline und Logs prüfen. Hypothese ohne Test bleibt Kandidat, kein Ergebnis. |
5Phase 5: Maßnahmen und Lessons | 30-45 min | Korrekturmaßnahme für ursächliche Differenz. Strukturelle Lessons: warum war diese Veränderung möglich ohne Aufmerksamkeit. Change-Management-Verbesserungen. | Häufig zeigt sich: Veränderung war ungeplant oder nicht kommuniziert. Strukturell heisst nicht „mehr Reviews“, sondern bessere Erkennung relevanter Differenzen, z. B. Change Calendar oder Diff Notifications. |
Was am Ende rauskommt
Differenz-Tabelle mit Soll, Ist, Differenz, Bewertung (ursächlich, beitragend, zufällig), Testergebnis und Maßnahme pro relevante Differenz. Lessons Learned über Change-Sichtbarkeit als zusätzlicher Abschnitt.
Datum, Vorfall-ID, Investigator und Reviewer im Header. Spätere Erkenntnisse als Update-Sektion am Ende. Bei Folge-Vorfällen mit ähnlichem Muster Querverweis auf vorherige Change Analysis.
Kompakte Arbeitsvorlage für Change Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Change Analysis Arbeitsmatrix
| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
## Ergebnisartefakte
- Change Matrix:
- Ursachenhypothesen:
- Validierungsfragen:
- Maßnahmenliste:
## Entscheidung oder Empfehlung
Welche Konsequenz ergibt sich aus der Matrix?Konkret gefülltes Szenario
## Change Analysis — Build-Pipeline schlägt seit 12.05. fehl, 14.05.2026
**Soll**: Build erfolgreich, 4.2 min Laufzeit, zuletzt am 11.05.2026 17:23 UTC.
**Ist**: Build schlägt seit 12.05.2026 09:14 UTC fehl mit Fehler „TLS handshake timeout“ beim Artefakt-Upload.
### Differenz-Tabelle (Auszug)
| Kategorie | Soll | Ist | Bewertung |
|---|---|---|---|
| Code | Commit-SHA a3f9 | Commit-SHA b7c2 | Zufällig (nur Doku-Änderung) |
| CI-Image | golang:1.22.2 | golang:1.22.3 | Beitragend (Patch hat neue CA-Zertifikate) |
| Artefakt-Registry | registry.alpha.io | registry.alpha.io | Soll = Ist |
| Netzwerk-Egress | Direkt | Über neuen Proxy seit 12.05. 08:00 | Ursächlich plausibel |
| Personal | DevOps-Lead Tobias | Tobias im Urlaub seit 12.05. | Beitragend (kein Eskalationspfad) |
### Test
Proxy-Konfiguration im Build-Container deaktiviert: Build erfolgreich (12.05. 11:40). Hypothese bestätigt.
### Maßnahmen
- Proxy-Konfiguration mit korrektem CA-Bundle erweitert. Owner @anna, bis 14.05. 18:00.
- Change Calendar für Netzwerk-Änderungen mit CI-Team teilen, Pflicht-Benachrichtigung 48 h vorab. Owner @sabine, bis 21.05.
- Zweite Person als Vertretung im DevOps-Team benannt, dokumentiert in RACI. Owner @sabine, bis 24.05.
### Lessons
Netzwerk-Änderungen wurden über separates Team eingeführt ohne Benachrichtigung der Build-Pipeline-Owner. Strukturelle Lücke: Cross-Team-Change-Visibility.Symptome erkennen, gegensteuern
Soll-Zustand ist „lief vorher“, ohne Versionsstand, Konfiguration oder Zeitpunkt.
Baseline rekonstruieren mit Versionierung, Logs und Konfigurations-Snapshots. Wenn nicht möglich, Methode pausieren bis Baseline klar.
Team listet drei Deploys auf, andere Differenzen (OS-Patch, Lieferanten-Service, Personalwechsel) fehlen.
Systematische Kategorien-Liste durchgehen (Code, Konfig, Daten, Infrastruktur, Personal, Lieferant, Umfeld, Prozess). Pro Kategorie aktiv suchen, nicht warten bis genannt.
Team gibt sich mit erster plausibler Hypothese zufrieden, prüft keine Alternativen.
Mindestens zwei Alternativ-Hypothesen explizit. Devil's Advocate prüft die scheinbar bestätigte Hypothese auf Lücken. Test isoliert, nicht im laufenden Betrieb.
Hypothese wird im Produktivsystem geprüft, Korrektur und Test mischen sich, Erkenntnis verwischt.
Test in Staging oder Pre-Prod-Umgebung. Wenn nicht möglich, kontrollierter Test mit Rollback-Plan, klarem Beobachtungsfenster und expliziter Hypothese.
Maßnahmen sind Symptom-Korrektur, strukturelle Change-Management-Lücke wird nicht adressiert.
Pro Vorfall mindestens eine strukturelle Lessons-Learned-Aktion: Sichtbarkeit, Kommunikation, Reviews. Sonst wiederholt sich Muster.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.