GitOps im Incident: Wann Argo CD hilft und wann es im Weg steht

GitOps ist eines der besseren Betriebsmodelle für Kubernetes. Es gibt Teams eine überprüfte Source of Truth, wiederholbare Deployments, einen sichtbaren Audit Trail und einen Weg zurück, wenn jemand versehentlich live im Cluster Änderungen macht. Für den normalen Plattformbetrieb ist das genau richtig.

Aber Incidents sind kein normaler Plattformbetrieb.

Um 02:00 Uhr, wenn Produktion steht und eine Konfiguration sofort geändert werden muss, können dieselben Eigenschaften plötzlich hinderlich wirken. Ein Controller setzt einen manuellen Fix zurück. Ein Pull Request wartet auf jemanden, der schläft. Nur eine Person hat Argo-CD-Rechte. Der Cluster ist technisch "korrekt", weil er Git entspricht, aber das Geschäft ist trotzdem down.

Das ist kein Grund, GitOps abzuschaffen. Es ist ein Grund, das Incident-Modell vor dem Incident zu entwerfen.

In Kubernetes-Communities taucht diese Spannung regelmäßig auf. In einem r/kubernetes-Thread wurde diskutiert, ob "GitOps" zu "Git + Operations" wird, sobald Menschen direkt in Produktion patchen. Die nützlichsten Antworten waren nicht ideologisch. Sie beschrieben das echte Betriebsproblem: Manchmal muss man zuerst das Feuer löschen, aber danach diszipliniert zu Git als Source of Truth zurückkehren.

Der Thread lohnt sich, weil er nach echter Produktionsarbeit klingt, nicht nach Konferenz-GitOps.

Wofür GitOps gut ist

GitOps funktioniert, weil es Mehrdeutigkeit reduziert. Der gewünschte Zustand des Systems liegt in Git. Der Controller vergleicht diesen Zustand mit dem Live-Cluster und gleicht Abweichungen aus. Dadurch bekommt das Team eine klare Antwort auf die Frage: "Was soll laufen?"

In einem gesunden Setup verbessert das mehrere Dinge gleichzeitig:

• Änderungen laufen durch Review statt aus der Shell-History einzelner Personen.
• Produktionszustand kann aus einem Repository reproduziert werden.
• Drift wird sichtbar, statt im Cluster zu verschwinden.
• Rollbacks werden normale Git-Operationen.
• Teams können über die Plattform sprechen, ohne dass jede Person Cluster-Admin braucht.

Der Fehler ist anzunehmen, dass ein System für Steady-State-Delivery automatisch auch Notfallbetrieb abdeckt.

Das Incident-Problem

Incidents komprimieren Zeit. Sie verändern auch die Kosten des Wartens.

Im normalen Delivery-Prozess ist "PR öffnen und Review abwarten" eine Stärke. Während eines Ausfalls kann es zum Engpass werden. Im Normalbetrieb ist "manuelle Cluster-Änderungen werden zurückgesetzt" ein Sicherheitsfeature. Während eines Incidents kann es die einzige funktionierende Mitigation rückgängig machen.

Typische Fehlerbilder sind vorhersehbar:

• Kein Notfallpfad: Das Team kann nur über den normalen PR-Weg deployen.
• Zu wenige privilegierte Operatoren: Eine Person kann Sync pausieren, einen Fix-Branch setzen oder Produktionsänderungen freigeben.
• Self-Heal arbeitet gegen Mitigation: Ein direkter kubectl patch wird zurückgesetzt, bevor klar ist, ob er hilft.
• Drift wird binär behandelt: Jede Abweichung von Git gilt gleich schlimm, auch wenn sie kurzlebig und absichtlich ist.
• Keine Reconciliation-Deadline: Der Service läuft wieder, aber niemand portiert den Fix zurück nach Git.
• Kein Audit-Link: Incident-Timeline, Git-Commits, Argo-Events und Live-Änderungen hängen nicht zusammen.

Das Problem ist nicht, dass GitOps zu streng oder Operatoren undiszipliniert sind. Viele Teams implementieren den Happy Path und lassen den Notfallpfad als Folklore liegen.

Break-Glass ist kein Anti-Pattern

Ein kontrollierter Break-Glass-Pfad schwächt GitOps nicht. Er sorgt dafür, dass GitOps Produktionskontakt überlebt.

Der Unterschied zwischen gutem und schlechtem Break-Glass ist nicht, ob Menschen den normalen Pfad umgehen können. Der Unterschied ist, ob der Umweg bewusst, protokolliert, zeitlich begrenzt und nachgeführt ist.

Ein praktisches Modell beantwortet vorher:

• Wer darf während eines Produktions-Incidents GitOps-Reconciliation pausieren oder ändern?
• Wie wird Zugriff erteilt, geloggt und überprüft?
• Kann der On-Call ein Argo-CD-Application-Target temporär auf einen Fix-Branch setzen?
• Wann ist direktes kubectl erlaubt?
• Was muss im Incident Record stehen?
• Wie schnell muss jede Notfalländerung zurück nach Git?
• Welche Alerts feuern, wenn Reconciliation zu lange pausiert?

Wenn diese Antworten nicht dokumentiert sind, hat die Plattform trotzdem einen Break-Glass-Prozess. Er ist nur implizit und wird im schlechtesten Moment entdeckt.

Ein besserer Incident-Workflow

Für die meisten Teams ist das richtige Modell nicht "nie den Cluster anfassen". Es ist: "Git bleibt der dauerhafte Zielzustand, auch wenn die schnellste Mitigation kurzzeitig woanders passiert."

Ein sinnvoller GitOps-Incident-Workflow:

1. Incident ausrufen und Operator benennen.
2. Entscheiden, ob die Mitigation schnell genug über Git geht.
3. Wenn ja: Fix-Branch oder Emergency-PR nutzen.
4. Wenn nein: kontrollierten Break-Glass-Zugriff nutzen und Änderung dokumentieren.
5. Self-Heal nur für betroffene Application oder Namespace pausieren.
6. Mit Produktionssignalen validieren, nicht nur mit Sync-Status.
7. Finalen Zustand nach Git zurückführen.
8. Reconciliation wieder aktivieren.
9. Prüfen, dass Git, Argo CD und Cluster übereinstimmen.
10. Drift-Fenster und Reconciliation-Commit im Incident Record verlinken.

So bleibt Git die dauerhafte Source of Truth, ohne die Realität zu ignorieren, dass Produktion manchmal eine schnelle, reversible Mitigation braucht.

Auf Drift-Alter alerten, nicht nur auf Drift

Eine nützliche Idee aus einer anderen Kubernetes-Diskussion: Alerting sollte auf Drift Age reagieren, nicht nur auf Existenz von Drift.

In diesem Thread wurde beschrieben, Hotfixes während Incidents zu erlauben, aber alles, was nicht zeitnah zurück nach Git kommt, als Prozessfehler zu behandeln.

Neue Drift während eines Incidents kann normal sein. Persistente Drift nach dem Incident ist das Problem.

Eine brauchbare Faustregel:

• Erwartete Drift wird ignoriert oder normalisiert.
• Neue Incident-Drift ist sichtbar, aber nicht zwingend ein Page.
• Persistente Drift erzeugt Arbeit.
• Wachsende Drift erzeugt Dringlichkeit.
• Pausierte Reconciliation hat immer Owner und Deadline.

Damit wird Drift vom Glaubenskrieg zum Betriebssignal.

Zugriff ist wichtiger als Toolwahl

Teams vergleichen oft Argo CD und Flux, als würde das Tool das Betriebsmodell entscheiden. Tut es nicht.

Wichtiger sind grundlegendere Fragen:

• Kann der On-Call sehen, was deployed ist?
• Kann er verstehen, warum Reconciliation fehlschlägt?
• Kann er Reconciliation sicher pausieren oder eingrenzen?
• Kann er eine Notfalländerung über einen schnellen Pfad routen?
• Kann die Plattform danach belegen, was passiert ist?

Wenn nur ein Senior Engineer Argo CD bedienen kann, wird GitOps zum Single Point of Failure. Wenn alle breit Cluster-Admin haben, wird GitOps optionales Theater. Der nützliche Mittelweg ist rollenbasierter Zugriff passend zur Incident-Verantwortung.

Woran man ein gutes Setup erkennt

Ein produktionsreifes GitOps-Setup braucht mehr als Controller und Repository. Mindestens sollte es geben:

• Dokumentierte Emergency-Change-Policy.
• Gescopte Argo-CD- oder Flux-Rechte für On-Call-Operatoren.
• Möglichkeit, Applications auf Fix-Branches zu setzen.
• Alerts für failed sync, degraded health und lange pausierte Reconciliation.
• Drift Detection, die erwartete Mutation von echter Konfigurationsdrift unterscheidet.
• Post-Incident-Pflicht, Live-State zurück nach Git zu führen.
• Runbooks für Rollback, Sync-Pause und erzwungene Reconciliation.
• Regelmäßiges Review der Produktions-GitOps-Rechte.

Das ist keine Bürokratie. So vermeidet man, das Betriebsmodell zu improvisieren, während Kunden bereits betroffen sind.

Der echte Test für GitOps ist nicht, ob normale Deployments über Git laufen. Das ist der einfache Teil.

Der echte Test ist, was passiert, wenn Produktion kaputt ist, Zeit zählt und der aktuelle Git-Zustand nicht der Zustand ist, den man für die nächsten 20 Minuten braucht.

Wenn das Team schnell mitigieren, Evidenz behalten, sauber reconciliieren und aus dem Drift-Fenster lernen kann, hilft GitOps. Wenn das Team auf eine Person wartet, gegen den Controller kämpft oder manuelle Änderungen wochenlang liegen bleiben, ist GitOps nur halb implementiert.