Wenn Prod brennt, ist „schnell irgendwas deployen“ der kürzeste Weg zu mehr Feuer. Hier ist dein pragmatisches 1x1: erst stabilisieren, dann fixen – mit Guardrails.
Freitag 16:47. Ein Update zieht dir den Boden weg: Checkout kaputt, Login tot, API 500t. Und plötzlich werden aus „wir deployen entspannt“ ganz schnell „wer hat SSH?“ und „mach einfach schnell live“.
Dieses Muster ist bekannt – und die Gegenmittel auch: Incident Response ist ein Prozess, kein Heldentum. Ziel ist nicht „perfekt“, sondern schnell wieder stabil mit minimalem Risiko für neue Schäden. In SRE-Sprache: stop the bleed, dann Ursachenarbeit.
- Stabilisieren first: Blast Radius klein halten (Feature aus, Route sperren, Rollback).
- Rollback ist oft schneller als ein „cleverer“ Hotfix (und meist risikoärmer).
- Hotfix nur minimal: ein Problem, ein Fix, keine „wenn wir schon dabei sind“-Änderungen.
- Deploy mit Guardrails: Canary/Blue-Green, Monitoring, klarer Abbruchpunkt.
- Danach Postmortem: blameless, konkret, mit Action Items (sonst wiederholt es sich).
Erst stabilisieren, dann fixen: die Reihenfolge rettet dich
Der häufigste Fehler bei Freitags-Incidents ist nicht „zu langsam“, sondern zu hektisch. Gute Incident-Response trennt sauber:
- Mitigation: Schaden begrenzen (Traffic umleiten, Feature deaktivieren, Rollback).
- Remediation: Ursache beheben (Hotfix, Patch, Dependency-Upgrade, Config-Fix).
- Learning: Postmortem + dauerhafte Maßnahmen (Runbooks, Tests, Alerting).
Dieses Denken (und „blameless postmortems“) ist in SRE/DevOps etabliert, weil es Teams schneller und zuverlässiger macht.
Das 1x1: 8 Schritte für Notfall-Fixes ohne Panik-Deploy
1) Triage: Was ist kaputt – und wie schlimm?
Definiere den Impact: Welche User? Welche Kernfunktion? Umsatz? Datenintegrität? Dann priorisieren: erst das stoppen, was wirklich weh tut.
- Minimal: Status (Down/Degraded), betroffene Komponenten, Startzeit, erste Vermutung.
- Wichtig: eine Person „koordiniert“, nicht alle gleichzeitig „fixen“.
2) Blast Radius klein halten (bevor du debugst)
Dein Ziel ist: weniger Schaden. Nicht „Root Cause in 5 Minuten“.
- Feature Flag / Kill Switch: Problemfeature aus, Rest bleibt stabil.
- Config-Toggle: z.B. Third-Party abschalten, Timeout hoch/runter, Fallback aktivieren.
- Traffic drosseln: Rate limit, Wartungsmodus nur für betroffene Route.
3) Entscheide: Rollback, Roll-forward oder Disable?
Das ist der wichtigste Entscheid. Rollback ist oft die schnellste Stabilisierung – sofern dein Rollback wirklich funktioniert (das ist ein Prozess-Thema, kein Glück)
4) Fix-Strategie wählen (minimal, reversibel, beobachtbar)
Notfall-Fix heißt: kleinster möglicher Patch mit klarem Rückweg.
- Minimal Diff: ein Fix, keine Refactors, keine „nebenbei Updates“.
- Reversibel: Flag/Config bevorzugen, wenn möglich.
- Beobachtbar: Log/Metrik für „Fix wirkt“ (z.B. Fehlerquote sinkt).
5) Test-Scope: Smoke Tests statt Test-Religion
Du testest jetzt nicht „alles“. Du testest: den kaputten Pfad + die 1–2 kritischsten Nachbarpfade (Regression-Risiko).
- Smoke: Login/Checkout/Core API, abhängig vom Incident.
- Daten: Edge Cases (leere Werte, Sonderzeichen, große Payloads) – da sterben Hotfixes gern.
6) Deploy-Guardrails: so wird der Deploy „langsam schnell“
Wenn möglich: Canary (kleiner Traffic-Anteil) oder Blue-Green (schneller Switch). Das sind bewährte Deployment-Muster, um Risiko zu begrenzen.
- Stop-Kriterium: ab welcher Error-Rate/Latency brichst du ab?
- Rollback-Plan: „Wenn X, dann zurück auf Version Y“ – vorher klar.
7) Monitoring: “Fix ist live” ist kein Erfolg
Erfolg ist: Metriken sind wieder normal. Mindestens: 5xx-Rate, Latenz, Kern-Conversion (falls vorhanden) und Logs für den kaputten Pfad.
- Quick Win: Ein Dashboard/Link pro Incident in die Kommunikation.
- Quick Win: Error-Tracking auf Deploys taggen (Version/Commit).
8) Nach dem Brand: Postmortem + 3 konkrete Maßnahmen
Ohne Postmortem ist es nur Glück, wenn’s nicht wieder passiert. Blameless heißt: Ursache im System suchen (Prozess/Tests/Monitoring), nicht im Menschen.
- Beispiel Actions: Dependency-Update-Policy, Feature Flag Kill Switch, „rollback tested“ in Pipeline.
- Wichtig: Action Items müssen owner + Termin haben, sonst sterben sie.
Vergleich: Welche Notfall-Option passt wann?
| Option | Wann sinnvoll | Risiko | Speed | Quick Win |
|---|---|---|---|---|
| Rollback | Fehler kam mit letztem Deploy | niedrig–mittel (wenn rollback getestet) | hoch | Rollback-Button/Script + DB-Migrations-Strategie klären |
| Feature Flag / Kill Switch | Ein Feature verursacht Schaden | niedrig | sehr hoch | Flags standardmäßig für risky Features einbauen |
| Config-Fix | Timeouts, Endpoints, Third-Party, Limits | mittel | hoch | Config versionieren, Changes loggen |
| Hotfix (Code) | Bug sitzt im Code und ist klar | mittel–hoch (Regression) | mittel | Minimal Diff + Canary + sofortiges Monitoring |
| Traffic-Shaping | Überlast/Spikes/Abuse | mittel | hoch | Rate Limits/WAF Regeln als Standard |
So setzt du’s um
So setzt du’s um: 30-Minuten-Notfall-Runbook
- Declare Incident: Kanal/Thread, ein Coordinator, Status „Degraded/Down“.
- Stop the bleed: Flag aus / Rollback / Traffic drosseln – zuerst Stabilität.
- Hypothese: was hat sich geändert? letzter Deploy? Dependency? Config? Third-Party?
- Fix wählen: kleinster Patch + Rückweg + Stop-Kriterium.
- Deploy guardrailed: Canary/Blue-Green, Monitoring links, Abbruchpunkt klar.
- Confirm: Metriken normal, Fehler weg, dann Abschluss.
- Postmortem-Termin: spätestens nächste Woche, mit 3 Action Items.
Mini-Use-Case: „Dependency Breaking Change“
- Sofort: Rollback auf letzte funktionierende Version oder Feature/Route deaktivieren.
- Fix: Dependency pinnen (Lockfile), kompatible Version wählen, dann geplant updaten.
- Prevent: Update-Policy + Changelog-Check + Staging/Canary verpflichtend.
Typische Fehler & wie du sie vermeidest
- Fehler: Erst debuggen, dann stabilisieren. Fix: Mitigation first (Blast Radius klein).
- Fehler: Hotfix wird ein „Mini-Release“. Fix: Minimal Diff, alles andere später.
- Fehler: Kein klarer Abbruchpunkt beim Deploy. Fix: Stop-Kriterien + Rollback-Plan vorher.
- Fehler: Monitoring erst nach dem Deploy. Fix: Dashboard/Alerts vorher öffnen und verlinken.
- Fehler: Postmortem wird Schuldzuweisung. Fix: blameless, systemisch, Action Items mit Owner.
Fazit: Notfall-Fixes sind ein Prozess, kein Adrenalin-Sport
Der beste Freitags-Fix ist der, der Stabilität zuerst liefert und den Blast Radius klein hält. Rollback/Disable sind oft die schnellsten Freunde. Hotfixes sind ok – aber nur mit Guardrails.
Nächster Schritt: Schreib dir ein 1-Seiten-Runbook (Triage → Mitigation → Deploy → Monitoring → Postmortem) und bau mindestens einen Kill Switch für dein riskigstes Feature. Dann fühlt sich Freitag schon ganz anders an.
FAQ
Wann ist Rollback besser als ein Hotfix?
Wenn der Fehler mit dem letzten Deploy kam und du ein zuverlässiges Rollback hast, ist Rollback oft der schnellste Weg zur Stabilität. Danach kannst du sauber analysieren und fixen.
Ist „am Freitag nicht deployen“ eine echte Regel?
Die eigentliche Regel ist: nicht deployen, wenn du es nicht beobachten/rollbacken kannst. Wenn du Guardrails (Canary/Blue-Green), Monitoring und Rollback hast, ist der Wochentag weniger magisch.
Was ist der Unterschied zwischen Hotfix und Roll-forward?
Hotfix ist meist ein kleiner Patch „on top“, um sofort zu stabilisieren. Roll-forward heißt: du gehst nicht zurück, sondern lieferst eine korrigierte neue Version nach vorn aus (oft mit Canary/Guardrails). Beide brauchen klare Stop-Kriterien.
Wie setze ich Canary Releases „in klein“ um?
Auch ohne Mega-Plattform geht das: zwei Versionen parallel (z.B. zwei Deployments), ein kleiner Traffic-Anteil oder nur interne Nutzer auf die neue Version, Monitoring prüfen, dann ausrollen. Das Muster ist gut dokumentiert.
Was gehört in ein gutes Incident-Runbook?
Triage-Schritte, Mitigation-Optionen (Rollback/Flag/Config), Links zu Dashboards/Logs, klare Kommunikation (wer, wo, wie), und ein Postmortem-Template. Das ist genau die Art Standardisierung, die SRE empfiehlt.
Wie verhindere ich Breaking Changes durch Dependencies?
Lockfiles/Version-Pinning, Updates über CI mit Tests, und staged rollouts (Canary). Für Open-Source-Dependencies sind automatisierte Updates plus Review der Release Notes ein bewährtes Muster, wie es auch in „Accelerate“ (DevOps-Forschung) als Teil stabiler Delivery beschrieben wird.