Kubernetes Incident Response: Strategie und Prozesse fuer Production-Ausfaelle

Ein Production-Ausfall um 3 Uhr nachts ohne klaren Prozess fuehrt zu Chaos. Wer wird informiert? Wer entscheidet? Welche Befehle muessen laufen? Ohne definierte Kubernetes Incident Response verlaengert sich die Ausfallzeit dramatisch -- und damit die Kosten.

Dieser Artikel liefert ein komplettes Incident-Management-Framework: von Severity-Leveln ueber Runbooks bis zum Post-Mortem-Prozess.

TL;DR

Definieren Sie vier Severity-Level (S1-S4) mit klaren Response-Zeiten und Eskalationspfaden.
Richten Sie eine On-Call-Rotation mit mindestens zwei Personen pro Schicht ein -- ein einzelner Admin ist kein Notfallkonzept.
Erstellen Sie Kubernetes-spezifische Runbooks fuer die haeufigsten Ausfallszenarien (CrashLoop, Node Down, Certificate Expiry, etcd).
Fuehren Sie nach jedem S1/S2-Incident ein blameless Post-Mortem durch und dokumentieren Sie Action Items.
Integrieren Sie SLOs und SLIs, damit Incidents automatisch erkannt und eskaliert werden.

Warum ein Incident-Response-Framework unverzichtbar ist

Ohne definierten Prozess passiert bei einem Kubernetes-Ausfall immer dasselbe: Jemand bemerkt das Problem, schreibt in einen Chat, mehrere Leute schauen gleichzeitig drauf, keiner koordiniert, und am Ende hat niemand dokumentiert, was passiert ist.

Die Folgen:

Laengere Ausfallzeiten -- ohne klaren Ablauf dauert die Diagnose doppelt so lang
Hero Culture -- immer dieselbe Person wird geweckt, Burnout ist vorprogrammiert
Wiederholung -- ohne Post-Mortem passiert derselbe Fehler wieder
Compliance-Risiko -- NIS2 und DSGVO fordern dokumentierte Incident-Prozesse

Ein strukturierter Kubernetes Incident Response Prozess reduziert die MTTR (Mean Time To Recovery) typischerweise um 40-60%.

Severity-Level: S1 bis S4

Jeder Incident braucht sofort eine Einstufung. Die Severity bestimmt, wer informiert wird, wie schnell reagiert werden muss und welche Kommunikationskanaele aktiv werden.

Severity-Matrix

# severity-matrix.yaml
# Incident Severity Definitionen fuer Kubernetes-Betrieb

severity_levels:
  S1_critical:
    beschreibung: "Komplettausfall Production, Datenverlust, Security Breach"
    beispiele:
      - "Cluster komplett nicht erreichbar"
      - "etcd Quorum verloren"
      - "Datenbankkorruption in Production"
      - "Unbefugter Zugriff auf Cluster"
    response_zeit: "15 Minuten"
    eskalation: "Sofort -- Incident Commander + Management"
    kommunikation: "War Room (Slack/Teams), Status Page, Kunden-Benachrichtigung"
    on_call: "Primaer + Sekundaer + Engineering Lead"

  S2_high:
    beschreibung: "Teilausfall Production, Performance-Degradation ueber 50%"
    beispiele:
      - "Mehrere Nodes NotReady"
      - "Ingress-Controller antwortet nicht"
      - "Zertifikate abgelaufen"
      - "HPA skaliert nicht, Latenz steigt"
    response_zeit: "30 Minuten"
    eskalation: "On-Call-Team, Engineering Lead informieren"
    kommunikation: "Incident-Channel, interne Status-Updates"
    on_call: "Primaer + Sekundaer"

  S3_medium:
    beschreibung: "Einzelne Services betroffen, Workaround moeglich"
    beispiele:
      - "Ein Deployment in CrashLoopBackOff"
      - "PVC Pending fuer nicht-kritischen Service"
      - "Monitoring-Luecken"
    response_zeit: "2 Stunden"
    eskalation: "On-Call primaer"
    kommunikation: "Incident-Ticket erstellen"
    on_call: "Primaer"

  S4_low:
    beschreibung: "Kosmetische Probleme, keine User-Auswirkung"
    beispiele:
      - "Warning-Events in non-prod Namespace"
      - "Deprecation Warnings"
      - "Non-critical Pod Restarts"
    response_zeit: "Naechster Werktag"
    eskalation: "Ticket-System"
    kommunikation: "Backlog-Eintrag"
    on_call: "Keine sofortige Reaktion noetig"

Die Severity wird vom ersten Responder gesetzt und kann vom Incident Commander angepasst werden. Im Zweifel immer hoeher einstufen -- herunterstufen ist einfach, zu spaet eskalieren ist teuer.

On-Call-Rotation einrichten

Eine funktionierende On-Call-Rotation ist das Rueckgrat jedes Incident-Response-Prozesses. Ohne sie haengt alles an Einzelpersonen.

Grundprinzipien

Mindestens 2 Personen pro Schicht -- Primaer und Sekundaer
Rotation alle 1-2 Wochen -- laenger fuehrt zu Burnout
Follow-the-Sun fuer verteilte Teams
Uebergabe-Ritual -- am Ende jeder Rotation werden offene Issues uebergeben
Kompensation -- On-Call-Dienst muss verguetet oder durch Freizeit ausgeglichen werden

PagerDuty Schedule als Code

# pagerduty-schedule.yaml (Terraform-kompatibel)
resource "pagerduty_schedule" "kubernetes_oncall" {
  name      = "Kubernetes Primary On-Call"
  time_zone = "Europe/Berlin"

  layer {
    name                         = "Primary"
    start                        = "2026-01-01T00:00:00+01:00"
    rotation_virtual_start       = "2026-01-01T00:00:00+01:00"
    rotation_turn_length_seconds = 604800  # 7 Tage
    users = [
      pagerduty_user.admin_1.id,
      pagerduty_user.admin_2.id,
      pagerduty_user.admin_3.id,
      pagerduty_user.admin_4.id,
    ]
  }

  layer {
    name                         = "Secondary"
    start                        = "2026-01-01T00:00:00+01:00"
    rotation_virtual_start       = "2026-01-08T00:00:00+01:00"
    rotation_turn_length_seconds = 604800
    users = [
      pagerduty_user.admin_2.id,
      pagerduty_user.admin_3.id,
      pagerduty_user.admin_4.id,
      pagerduty_user.admin_1.id,
    ]
  }
}

resource "pagerduty_escalation_policy" "kubernetes" {
  name      = "Kubernetes Escalation"
  num_loops = 2

  rule {
    escalation_delay_in_minutes = 15
    target {
      type = "schedule_reference"
      id   = pagerduty_schedule.kubernetes_oncall.id
    }
  }

  rule {
    escalation_delay_in_minutes = 15
    target {
      type = "user_reference"
      id   = pagerduty_user.engineering_lead.id
    }
  }
}

Alertmanager-Integration

# alertmanager-config.yaml
apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  namespace: monitoring
stringData:
  alertmanager.yml: |
    global:
      resolve_timeout: 5m

    route:
      receiver: 'default'
      group_by: ['alertname', 'namespace', 'severity']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      routes:
        - match:
            severity: critical
          receiver: 'pagerduty-critical'
          group_wait: 10s
          repeat_interval: 1h
        - match:
            severity: warning
          receiver: 'pagerduty-warning'
          repeat_interval: 4h

    receivers:
      - name: 'default'
        slack_configs:
          - channel: '#k8s-alerts'
            send_resolved: true
      - name: 'pagerduty-critical'
        pagerduty_configs:
          - routing_key_file: '/etc/alertmanager/secrets/pagerduty-key'
            severity: critical
            description: '{{ .CommonAnnotations.summary }}'
      - name: 'pagerduty-warning'
        pagerduty_configs:
          - routing_key_file: '/etc/alertmanager/secrets/pagerduty-key'
            severity: warning

Weitere Details zur Monitoring-Integration finden Sie in unserem Artikel zu Kubernetes Observability Stack.

Der Incident Commander: Rolle und Verantwortung

Bei S1- und S2-Incidents uebernimmt ein Incident Commander (IC) die Koordination. Der IC debuggt nicht selbst -- er koordiniert.

Aufgaben des Incident Commanders

Severity bestaetigen oder anpassen
War Room eroeffnen (Slack-Channel oder Teams-Call)
Rollen zuweisen -- wer debuggt, wer kommuniziert, wer dokumentiert
Zeitstempel fuehren -- was passiert wann
Entscheidungen treffen -- Rollback ja/nein, Kunden informieren ja/nein
Eskalieren wenn noetig
Incident schliessen und Post-Mortem einleiten

Kommunikation waehrend eines Incidents

# Incident-Channel erstellen (Slack CLI)
slack-cli channel create \
  --name "inc-2026-02-10-cluster-down" \
  --topic "S1: Production Cluster nicht erreichbar | IC: @max | Status: Investigating"

# Status-Update Template
# Alle 30 Minuten bei S1, alle 60 Minuten bei S2:
# ---
# Status Update [14:30 UTC]
# Severity: S1
# Status: Investigating -> Identified
# Zusammenfassung: etcd Leader Election fehlgeschlagen nach Node-Ausfall
# Naechste Schritte: etcd Member manuell entfernen, neuen Node provisionieren
# ETA: 30 Minuten
# ---

Kubernetes-spezifische Runbooks

Runbooks sind Schritt-fuer-Schritt-Anleitungen fuer bekannte Ausfallszenarien. Sie reduzieren die Abhaengigkeit von Einzelpersonen und beschleunigen die Diagnose.

Runbook 1: Pod CrashLoopBackOff

#!/bin/bash
# runbook-crashloop.sh
# Severity: S3 (einzelner Service) oder S2 (kritischer Service)

echo "=== CrashLoopBackOff Diagnose ==="

NAMESPACE=${1:-default}
POD=${2}

# Schritt 1: Aktuellen Status pruefen
echo "--- Schritt 1: Pod Status ---"
kubectl get pod "$POD" -n "$NAMESPACE" -o wide

# Schritt 2: Logs des letzten Crashes
echo "--- Schritt 2: Previous Logs ---"
kubectl logs "$POD" -n "$NAMESPACE" --previous --tail=100

# Schritt 3: Exit Code pruefen
echo "--- Schritt 3: Exit Code ---"
kubectl get pod "$POD" -n "$NAMESPACE" \
  -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'
echo ""

# Schritt 4: Events
echo "--- Schritt 4: Events ---"
kubectl get events -n "$NAMESPACE" \
  --field-selector involvedObject.name="$POD" \
  --sort-by='.lastTimestamp'

# Schritt 5: Resource Limits pruefen (OOMKilled = Exit 137)
echo "--- Schritt 5: Resource Limits ---"
kubectl get pod "$POD" -n "$NAMESPACE" \
  -o jsonpath='{range .spec.containers[*]}{.name}: limits={.resources.limits}, requests={.resources.requests}{"\n"}{end}'

# Schritt 6: ConfigMaps und Secrets pruefen
echo "--- Schritt 6: Umgebung pruefen ---"
kubectl describe pod "$POD" -n "$NAMESPACE" | grep -A5 "Environment\|ConfigMap\|Secret"

Eine detaillierte Anleitung zum CrashLoopBackOff-Debugging finden Sie in unserem CrashLoopBackOff Troubleshooting Guide.

Runbook 2: Node NotReady

#!/bin/bash
# runbook-node-notready.sh
# Severity: S2 (mehrere Nodes) oder S3 (einzelner Node mit Redundanz)

echo "=== Node NotReady Diagnose ==="

NODE=${1}

# Schritt 1: Node-Status
echo "--- Schritt 1: Node Status ---"
kubectl get node "$NODE" -o wide
kubectl describe node "$NODE" | grep -A10 "Conditions:"

# Schritt 2: Kubelet-Status (SSH auf den Node)
echo "--- Schritt 2: Kubelet pruefen ---"
echo "Fuehren Sie auf dem Node aus:"
echo "  systemctl status kubelet"
echo "  journalctl -u kubelet --since '30 minutes ago' --no-pager | tail -50"

# Schritt 3: Disk Pressure pruefen
echo "--- Schritt 3: Disk Pressure ---"
kubectl describe node "$NODE" | grep -E "DiskPressure|MemoryPressure|PIDPressure"

# Schritt 4: Betroffene Pods identifizieren
echo "--- Schritt 4: Betroffene Pods ---"
kubectl get pods --all-namespaces --field-selector spec.nodeName="$NODE" \
  -o wide | grep -v Running

# Schritt 5: Pods evakuieren falls noetig
echo "--- Schritt 5: Evakuierung (manuell ausfuehren) ---"
echo "  kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --grace-period=60"
echo "  kubectl cordon $NODE"

Runbook 3: Certificate Expiry

#!/bin/bash
# runbook-cert-expiry.sh
# Severity: S1 (API Server Cert) oder S2 (Ingress Cert)

echo "=== Certificate Expiry Diagnose ==="

# Schritt 1: Kubernetes API Server Zertifikate pruefen
echo "--- Schritt 1: API Server Certs ---"
# Auf dem Control Plane Node:
echo "Fuehren Sie auf dem Control Plane aus:"
echo "  kubeadm certs check-expiration"

# Schritt 2: Ingress TLS Secrets pruefen
echo "--- Schritt 2: Ingress TLS Secrets ---"
for SECRET in $(kubectl get secrets --all-namespaces -o json | \
  jq -r '.items[] | select(.type=="kubernetes.io/tls") | "\(.metadata.namespace)/\(.metadata.name)"'); do
  NS=$(echo "$SECRET" | cut -d/ -f1)
  NAME=$(echo "$SECRET" | cut -d/ -f2)
  EXPIRY=$(kubectl get secret "$NAME" -n "$NS" -o jsonpath='{.data.tls\.crt}' | \
    base64 -d | openssl x509 -noout -enddate 2>/dev/null)
  echo "  $SECRET: $EXPIRY"
done

# Schritt 3: cert-manager Zertifikate pruefen
echo "--- Schritt 3: cert-manager Status ---"
kubectl get certificates --all-namespaces
kubectl get certificaterequests --all-namespaces | grep -v Approved

# Schritt 4: Kubeadm Zertifikate erneuern
echo "--- Schritt 4: Erneuerung (manuell ausfuehren) ---"
echo "  kubeadm certs renew all"
echo "  systemctl restart kubelet"

Runbook 4: etcd-Probleme

#!/bin/bash
# runbook-etcd.sh
# Severity: S1 -- etcd ist die kritischste Komponente

echo "=== etcd Diagnose ==="

# Schritt 1: etcd Cluster Health
echo "--- Schritt 1: Cluster Health ---"
echo "Fuehren Sie auf dem Control Plane aus:"
echo '  ETCDCTL_API=3 etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    endpoint health --cluster'

# Schritt 2: Member-Liste pruefen
echo "--- Schritt 2: Member Liste ---"
echo '  ETCDCTL_API=3 etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    member list -w table'

# Schritt 3: Performance pruefen
echo "--- Schritt 3: Disk Latency ---"
echo '  ETCDCTL_API=3 etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    check perf'

# Schritt 4: Backup erstellen (IMMER vor Aenderungen)
echo "--- Schritt 4: Backup ---"
echo '  ETCDCTL_API=3 etcdctl \
    --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db'

Zum Thema Backup-Strategien empfehlen wir unseren ausfuehrlichen Artikel zu Kubernetes Backup und Disaster Recovery.

Diagnostic Commands Cheat Sheet

Fuer die schnelle Diagnose waehrend eines Incidents:

# === Cluster-Uebersicht ===
kubectl get nodes -o wide
kubectl get pods --all-namespaces | grep -v Running | grep -v Completed
kubectl top nodes
kubectl top pods --all-namespaces --sort-by=memory | head -20

# === Control Plane Health ===
kubectl get componentstatuses 2>/dev/null || echo "Deprecated - nutze stattdessen:"
kubectl get --raw='/readyz?verbose'
kubectl get --raw='/healthz?verbose'

# === Events (letzte 30 Minuten) ===
kubectl get events --all-namespaces --sort-by='.lastTimestamp' | tail -30

# === Netzwerk-Diagnose ===
# DNS testen
kubectl run dns-test --rm -it --restart=Never --image=busybox:1.36 \
  -- nslookup kubernetes.default.svc.cluster.local

# Konnektivitaet testen
kubectl run net-test --rm -it --restart=Never --image=nicolaka/netshoot \
  -- curl -v --max-time 5 http://service-name.namespace.svc.cluster.local

# === Resource Pressure ===
kubectl describe nodes | grep -A5 "Allocated resources"
kubectl get pods --all-namespaces -o json | \
  jq '[.items[] | select(.status.phase=="Pending")] | length'

# === Ingress/Load Balancer ===
kubectl get ingress --all-namespaces
kubectl get svc --all-namespaces | grep LoadBalancer
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=50

Post-Mortem: Blameless und strukturiert

Nach jedem S1- und S2-Incident muss ein Post-Mortem stattfinden. Das Ziel ist nicht Schuldzuweisung, sondern systemische Verbesserung.

Post-Mortem Template

# post-mortem-template.yaml
incident:
  id: "INC-2026-0042"
  titel: "Production API nicht erreichbar fuer 47 Minuten"
  datum: "2026-02-10"
  severity: "S1"
  dauer: "47 Minuten (14:03 - 14:50 UTC)"
  incident_commander: "Max Mustermann"
  autoren: ["Max Mustermann", "Erika Musterfrau"]

zusammenfassung: |
  Am 10. Februar 2026 war die Production API fuer 47 Minuten
  nicht erreichbar. Ursache war ein fehlgeschlagenes etcd
  Compaction, das zu Disk Pressure auf allen drei Control
  Plane Nodes fuehrte.

timeline:
  - zeit: "14:03 UTC"
    ereignis: "Alert: API Server Response Time ueber 5s"
    typ: "detection"
  - zeit: "14:05 UTC"
    ereignis: "On-Call acknowledged, beginnt Diagnose"
    typ: "response"
  - zeit: "14:12 UTC"
    ereignis: "S1 deklariert, War Room geoeffnet"
    typ: "escalation"
  - zeit: "14:20 UTC"
    ereignis: "Ursache identifiziert: etcd Disk Pressure"
    typ: "identification"
  - zeit: "14:35 UTC"
    ereignis: "Alte etcd Revisions manuell bereinigt"
    typ: "mitigation"
  - zeit: "14:50 UTC"
    ereignis: "API Server antwortet normal, Incident resolved"
    typ: "resolution"

root_cause: |
  etcd Auto-Compaction war auf 'periodic: 24h' konfiguriert,
  aber die Datenbank wuchs durch haeufige ConfigMap-Updates
  schneller als die Compaction bereinigen konnte. Die Disk
  erreichte 95% Belegung, etcd stoppte Schreiboperationen.

contributing_factors:
  - "Kein Alert fuer etcd DB-Groesse konfiguriert"
  - "Compaction-Intervall nicht an Workload angepasst"
  - "Keine separate Disk fuer etcd Data Directory"

was_gut_lief:
  - "Alert fuer API Latenz hat schnell gegriffen"
  - "On-Call hat in unter 2 Minuten reagiert"
  - "Runbook fuer etcd war vorhanden und hilfreich"
  - "Kommunikation im War Room war strukturiert"

was_verbessert_werden_muss:
  - "Fehlender Alert fuer etcd Disk Usage"
  - "Kein automatisiertes etcd Compaction Monitoring"
  - "Runbook hatte keinen Abschnitt zu Disk Pressure"

action_items:
  - beschreibung: "Alert fuer etcd Disk Usage ueber 80% einrichten"
    verantwortlich: "Erika Musterfrau"
    deadline: "2026-02-17"
    prioritaet: "P1"
    ticket: "OPS-1234"
  - beschreibung: "etcd Compaction auf 1h reduzieren"
    verantwortlich: "Max Mustermann"
    deadline: "2026-02-14"
    prioritaet: "P1"
    ticket: "OPS-1235"
  - beschreibung: "Separate SSD fuer etcd Data Directory"
    verantwortlich: "Max Mustermann"
    deadline: "2026-03-01"
    prioritaet: "P2"
    ticket: "OPS-1236"
  - beschreibung: "Runbook um Disk-Pressure-Szenario erweitern"
    verantwortlich: "Erika Musterfrau"
    deadline: "2026-02-17"
    prioritaet: "P2"
    ticket: "OPS-1237"

Post-Mortem Regeln

Blameless -- wir analysieren das System, nicht die Person
Innerhalb von 48 Stunden -- solange die Erinnerung frisch ist
Alle Beteiligten -- nicht nur der Incident Commander
Action Items mit Deadline und Owner -- sonst passiert nichts
Veroeffentlichen -- Transparenz schafft Vertrauen und Lerneffekte

SLO/SLI-Integration

Service Level Objectives und Indicators sind die Bruecke zwischen Business-Anforderungen und technischem Monitoring. Sie definieren, wann ein Incident vorliegt.

SLI-Definitionen fuer Kubernetes-Workloads

# prometheus-sli-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: sli-rules
  namespace: monitoring
spec:
  groups:
    - name: sli.availability
      rules:
        # SLI: Anteil erfolgreicher Requests
        - record: sli:availability:ratio
          expr: |
            sum(rate(http_requests_total{code=~"2..|3.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))

        # SLI: Anteil Requests unter 500ms
        - record: sli:latency:ratio
          expr: |
            sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m]))
            /
            sum(rate(http_request_duration_seconds_count[5m]))

    - name: slo.alerts
      rules:
        # Alert wenn Error Budget unter 20% faellt
        - alert: SLOErrorBudgetBurn
          expr: |
            1 - sli:availability:ratio > (1 - 0.999) * 5
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Error Budget wird zu schnell verbraucht"
            description: "Die aktuelle Fehlerrate verbraucht das monatliche Error Budget in unter 6 Tagen."

        # Alert wenn Latenz-SLO verletzt
        - alert: SLOLatencyBreach
          expr: |
            sli:latency:ratio < 0.95
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Latenz-SLO unter 95%"
            description: "Weniger als 95% der Requests werden unter 500ms beantwortet."

SLO-Definition

# slo-definition.yaml
slos:
  api_availability:
    sli: "sli:availability:ratio"
    target: 99.9%        # 43.8 Minuten Downtime pro Monat
    window: 30 Tage
    error_budget: 0.1%   # ca. 44 Minuten
    alert_burn_rate: 5x  # Alert bei 5-facher Burn-Rate

  api_latency:
    sli: "sli:latency:ratio"
    target: 95%           # 95% der Requests unter 500ms
    window: 30 Tage
    alert_threshold: 90%  # Alert unter 90%

  cluster_availability:
    sli: "Node Ready Ratio"
    target: 99.5%
    window: 30 Tage

Fuer eine tiefere Einfuehrung in Monitoring-Strategien lesen Sie unseren Artikel zu Kubernetes Monitoring und Observability.

Haeufige Fehler im Incident Management

1. Hero Culture

Ein einzelner "Kubernetes-Experte" wird bei jedem Problem geweckt. Das fuehrt zu Burnout und einem Single Point of Failure. Stattdessen: Wissen dokumentieren, Runbooks schreiben, On-Call rotieren.

2. Keine Dokumentation waehrend des Incidents

Wenn niemand mitschreibt, gibt es kein Post-Mortem. Loesung: Der Incident Commander oder ein dedizierter Scribe fuehrt ein Echtzeit-Log.

3. Zu viele Alerts

Wenn das On-Call-Telefon 50 Mal pro Nacht klingelt, werden Alerts ignoriert. Tunen Sie Ihre Alerts aggressiv: Jeder Alert muss eine Aktion erfordern.

# Alert-Qualitaet pruefen: Wie viele Alerts pro Woche?
# Ziel: unter 10 Pages pro On-Call-Schicht

# Alertmanager API abfragen
curl -s http://alertmanager:9093/api/v2/alerts | \
  jq '[.[] | select(.status.state=="active")] | length'

4. Post-Mortems ohne Follow-Up

Action Items ohne Deadline und Owner werden nie umgesetzt. Tracken Sie Action Items in Ihrem Ticket-System und reviewen Sie den Status woechentlich.

5. Kein regelmaessiges Incident-Training

Fuehren Sie vierteljaehrlich Incident-Drills durch. Simulieren Sie einen S1-Ausfall und ueberpruefen Sie, ob die Prozesse funktionieren.

# Beispiel: Chaos Engineering fuer Incident-Training
# (NUR in Staging/Test-Umgebungen)
kubectl delete pod -l app=critical-service -n staging
kubectl cordon staging-node-01
kubectl drain staging-node-01 --ignore-daemonsets --delete-emptydir-data

Mehr zum Thema Chaos Engineering finden Sie in unserem Artikel Chaos Engineering mit LitmusChaos.

Incident Response Automatisierung

Einige Incident-Response-Schritte lassen sich automatisieren, um die Reaktionszeit weiter zu verkuerzen.

Automatische Diagnostik bei Alert

# kubernetes-alert-diagnostics.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: incident-diagnostics
  namespace: monitoring
spec:
  template:
    spec:
      serviceAccountName: diagnostics-sa
      containers:
        - name: diagnostics
          image: bitnami/kubectl:1.29
          command:
            - /bin/bash
            - -c
            - |
              echo "=== Incident Diagnostics $(date) ==="
              echo "--- Cluster Status ---"
              kubectl get nodes -o wide
              echo "--- Unhealthy Pods ---"
              kubectl get pods -A | grep -v Running | grep -v Completed
              echo "--- Recent Events ---"
              kubectl get events -A --sort-by='.lastTimestamp' | tail -30
              echo "--- Top Resource Consumers ---"
              kubectl top pods -A --sort-by=memory | head -20
              echo "--- Control Plane Health ---"
              kubectl get --raw='/readyz?verbose' 2>/dev/null || echo "readyz not available"
      restartPolicy: Never
  backoffLimit: 1

Checkliste: Incident Response Readiness

Pruefen Sie, ob Ihr Team bereit ist:

On-Call-Rotation mit mindestens 4 Personen eingerichtet
Severity-Level definiert und dem Team bekannt
Alertmanager konfiguriert mit sinnvollen Thresholds
PagerDuty/Opsgenie mit Eskalation konfiguriert
Runbooks fuer die 5 haeufigsten Szenarien geschrieben
Post-Mortem-Template vorhanden und allen bekannt
Incident-Communication-Channel definiert (Slack/Teams)
Status Page fuer externe Kommunikation eingerichtet
SLOs definiert und Error Budget Monitoring aktiv
Vierteljaehrliche Incident-Drills geplant

Fazit

Kubernetes Incident Response ist kein Produkt, das man kauft, sondern ein Prozess, den man aufbaut und kontinuierlich verbessert. Die wichtigsten Bausteine sind: klare Severity-Level, eine faire On-Call-Rotation, praxisnahe Runbooks und konsequente Post-Mortems.

Investieren Sie jetzt in Ihren Incident-Response-Prozess -- die Kosten eines ungeplanten Ausfalls ohne Prozess uebersteigen die Investition um ein Vielfaches.

Fuer den Aufbau einer umfassenden Notfallstrategie empfehlen wir auch unseren Artikel zum Kubernetes Production-Ausfall Notfallplan.