Incident Management für Platform Teams
Severity, Kommunikation, Postmortems und Plattform-spezifische Incidents.
Lernziele
Nach dieser Lektion kannst du erklären, warum Incident Management für Platform Teams andere Regeln hat als für Produkt-Teams, wie du Severity-Klassen und Kommunikationswege definierst und was ein brauchbares Postmortem für Plattform-Incidents enthält. Du kannst Plattform-spezifische Incident-Muster (Kaskadeneffekte, Multi-Team-Impact) von Anwendungs-Incidents unterscheiden und typische Kommunikationsfehler benennen.
Das Problem: Ein Platform-Incident ist kein App-Incident
Ein Stream-Team-Incident ist begrenzt: Der Checkout-Service hat erhöhte Fehlerrate — ein Team, ein Service, ein Runbook. Ein Platform-Incident ist ein Multiplikator: Der Shared Ingress fällt aus, und 40 Teams haben gleichzeitig 503-Fehler. Die GitOps-Pipeline hängt, und niemand kann deployen. Vault sealed sich, und Pods starten nicht neu — während laufende Pods noch funktionieren, bis der nächste Rolling Update kommt.
Drei Eigenschaften machen Platform-Incidents gefährlicher:
Kaskadeneffekte. Ingress-Ausfall → Monitoring-Alerts feuern nicht (kein Traffic) → Teams merken es erst über User-Beschwerden. CI-Ausfall → niemand deployt Fixes für den Ingress-Ausfall. Die Abhängigkeitskette muss im Incident-Response-Plan stehen.
Unklare Ownership. Ist ein 503 am Ingress ein Platform-Problem oder ein App-Problem? Ohne Routing-Regeln landet jedes Ticket beim Platform-Team — oder jedes beim Stream-Team. Beides ist falsch.
Kommunikationsdruck. 40 Team-Leads fragen gleichzeitig „was ist los?” in Slack. Ohne zentralen Status-Channel und klare Severity-Definition eskaliert die Kommunikation schneller als das Incident selbst.
Severity: Wann ist es ein Platform-Incident?
Definiere Severity vor dem ersten Incident — nicht währenddessen. Ein bewährtes Schema für Plattform-Teams:
| Severity | Kriterium | Beispiel | Response |
|---|---|---|---|
| SEV-1 | Mehrere Teams blockiert, kein Workaround | CI komplett down, kein Deploy möglich | Sofort-Page, Incident Commander, Status-Updates alle 15 Min |
| SEV-2 | Ein Plattform-Service degradiert, Workaround existiert | Build-Queue 30 Min statt 5 Min, Deploy über manuelles kubectl möglich | Page, Updates alle 30 Min |
| SEV-3 | Einzelner Tenant betroffen oder Monitoring-Gap | Ein Team-Environment nicht provisionierbar | Ticket, nächster Business Day |
| SEV-4 | Kosmetisch oder präventiv | Dashboard zeigt veraltete Metrik | Backlog |
Der entscheidende Unterschied zu Produkt-Teams: SEV-1 bei einer Plattform betrifft immer mehrere Teams. Deshalb braucht das Platform-Team einen Incident Commander (IC), der Kommunikation und Koordination von der technischen Diagnose trennt — auch wenn das Team klein ist.
Kommunikation: Status-Channel und Stakeholder-Matrix
Drei Kommunikationsartefakte, die du vorab einrichtest:
Status-Channel (z. B. #platform-status): Einziger Kanal für Incident-Updates. Format: [SEV-X] <Service> — <Kurzbeschreibung> — <ETA oder nächstes Update>. Kein Thread-Diskurs, keine Spekulation. IC postet, alle anderen lesen.
Stakeholder-Matrix: Wer wird bei welcher Severity informiert? SEV-1: Engineering-Leadership + alle Team-Leads. SEV-2: Platform-Team + betroffene Teams. SEV-3: Platform-Team intern.
Status-Page (intern): Auch wenn ihr kein externes Statuspage.io habt — eine einfache Seite mit aktuellem Plattform-Status, geplanten Wartungen und Incident-Historie. Stream-Teams checken dort statt 40 mal Slack zu fragen.
Während des Incidents gilt: Lieber zu früh updaten als zu spät. „Wir wissen noch nicht, wann es fixed ist — nächstes Update in 15 Minuten” ist eine vollwertige Mitteilung.
Plattform-spezifische Incident-Muster
Diese Muster solltest du in Runbooks (Lektion 39) und Postmortems wiedererkennen:
Shared-Component-Ausfall: Ingress, DNS, CoreDNS, CNI, Container-Registry. Symptom: Breitflächige Fehler über alle Teams. Erste Diagnose: Ist die Komponente selbst healthy? kubectl -n <ns> get pods, Logs, SLO-Dashboard.
Control-Plane-Degradation: Kubernetes-API langsam, etcd-Latenz hoch, Scheduler hängt. Symptom: Deployments pending, HPA reagiert nicht. Gefährlich, weil die Symptome verzögert auftreten.
GitOps-Desync: Argo CD oder Flux reconciled nicht. Symptom: Teams mergen, aber nichts ändert sich in Production. Oft SEV-2, weil laufende Workloads weiter funktionieren — bis jemand einen Fix braucht.
Secrets-Kaskade: Vault sealed oder ESO sync failed. Symptom: Neue Pods starten nicht, bestehende laufen. Zeitbombe: Jeder Rolling Update verschärft das Problem.
Noisy-Neighbor auf Shared Infrastructure: Ein Team füllt Kafka-Disk oder blockiert CI-Runner. Symptom: Andere Teams degradiert, ohne eigenen Change. Braucht Quota-Enforcement und schnelle Isolation.
Postmortems: Blameless, aber nicht bedeutungslos
Ein Postmortem nach jedem SEV-1 und SEV-2 — innerhalb von fünf Werktagen. Struktur:
- Summary: Was ist passiert, wie lange, wer war betroffen (Anzahl Teams, nicht nur „viele”).
- Timeline: UTC-Zeitstempel — Alert, IC-Assign, erste Diagnose, Mitigation, Resolution.
- Root Cause: Technische Ursache und Systemursache. „Ingress-Pod crashte” ist Symptom; „kein PDB, kein HA-Setup, kein automatischer Restart” ist Systemursache.
- Impact: SLO-Verletzung quantifiziert — wie viel Error Budget verbraucht (Lektion 36)?
- Action Items: Jeder Punkt mit Owner und Deadline. Maximal fünf — mehr wird nicht umgesetzt.
- Was gut lief: Auch das gehört rein. Blameless heißt nicht, dass alles schlecht war.
Plattform-Postmortems sind öffentlich intern — alle Stream-Teams dürfen lesen. Transparenz baut Vertrauen und verhindert Gerüchte.
Praxis: Tabletop-Exercise für einen Platform-Incident
Bevor der echte Incident kommt, simuliere einen:
- Szenario wählen: „Container-Registry ist unreachable — kein Pull, kein Push, kein Deploy.”
- Rolle verteilen: IC, Technical Lead, Kommunikation, Scribe (Timeline).
- 30 Minuten durchspielen: Alert kommt → Severity setzen → Status-Channel → Diagnose-Schritte → Mitigation (Pull-Through-Cache? Failover-Registry?) → Resolution.
- Debrief: Wo fehlte ein Runbook? Wer wurde nicht informiert? Welche Diagnose-Schritte dauerten zu lang?
- Action Items: Runbook ergänzen, Alert-Routing prüfen, Status-Page aktualisieren.
Ein Tabletop kostet eine Stunde und spart im echten Incident Stunden — besonders bei der Kommunikation, die in der Hitze vergessen wird.
Typische Stolperfallen
Jedes Ticket ist SEV-1: Wenn alles dringend ist, pagerd niemand mehr. Severity muss diszipliniert sein.
Kein IC bei Multi-Team-Incidents: Der beste Debugger und der Kommunikator in einer Person — beides leidet.
Postmortem ohne Action Items: Dokumentation ohne Konsequenz. Lieber drei Items mit Deadline als zehn ohne Owner.
Schuld-Zuweisung: „Team X hat zu viele Builds gestartet” statt „Concurrency-Limits fehlten”. Blameless-Kultur oder keine Postmortems.
Incident endet mit Mitigation, nicht mit Fix: Registry-Failover als Workaround, aber Root Cause (Storage voll) offen — der Incident kommt zurück.
Interview-Vorbereitung
Auf „Wie managst du Incidents als Platform Team?” antwortest du: Unterschied (Multi-Team-Impact, Kaskadeneffekte, unklare Ownership) → Severity (SEV-Schema mit Plattform-Kriterien) → Kommunikation (IC, Status-Channel, Stakeholder-Matrix) → Postmortem (blameless, SLO-Impact, Action Items mit Owner).
Follow-ups:
- „Platform-Incident vs. App-Incident?” — Blast Radius (alle Teams vs. ein Service), Routing-Regel (wer kann remedieren?), Kommunikationsumfang.
- „Wann brauchst du einen IC?” — Ab SEV-1 oder wenn mehr als zwei Teams betroffen — auch im kleinen Team.
- „Was ist ein gutes Postmortem?” — Timeline, Root Cause + System Cause, quantifizierter SLO-Impact, max. fünf Action Items, öffentlich intern.
Zusammenfassung
Incident Management für Platform Teams unterscheidet sich durch Multi-Team-Impact, Kaskadeneffekte und Kommunikationsdruck. Severity-Klassen, Incident Commander und ein zentraler Status-Channel sind Voraussetzung, nicht Luxus. Postmortems quantifizieren SLO-Impact und erzeugen Action Items mit Owner — blameless, aber konsequent. Tabletop-Exercises vor dem ersten echten SEV-1 sind die günstigste Versicherung.
Damit Incidents seltener und weniger schwerwiegend werden, braucht es kontrollierte Changes — in der nächsten Lektion: Upgrade-Strategien und Blast-Radius-Kontrolle.