Wenn GitOps auf Notfall-Fixes trifft: Operative Lektionen mit ArgoCD
GitOps klingt auf dem Papier makellos. Man definiert die gesamte Infrastruktur und alle Deployments in Git, die Pipelines erledigen den Rest, und Tools wie ArgoCD halten alles im Cluster mit der versionskontrollierten Wahrheit im Einklang. Das ist die Art von DevOps-Traum, die auf jeder Cloud-Native-Konferenz Keynote-Zeit bekommt.
Infrastruktur in der echten Welt sieht allerdings anders aus als eine Keynote, eher wie ein Friedhof aus Kompromissen, nächtlichen Alerts und Feuerwehrübungen. Und wenn GitOps böse aus dem Ruder läuft, meist um 2 Uhr morgens, dann wacht nicht der Senior Engineer auf, der den Talk auf der KubeCon hält. Es ist der Junior SRE, der über kubectl edit schwitzt und hofft, dass seine Änderungen sich halten, bevor ArgoCD es bemerkt.
Das alles ist schmerzhaft und urkomisch real, und das Internet hat Geschichten dazu.
GitOps vs. Prod-Brände: Wer gewinnt?
Eine der häufigeren Frustrationen mit GitOps-Workflows ist, dass sie per Design starr sind. Das ist genau der Sinn der Sache, denn wir wollen manuelle Eingriffe eliminieren, Drift reduzieren und Wiederholbarkeit sicherstellen. Manchmal ist Wiederholbarkeit aber der Feind.
Stellen Sie sich vor: Die Produktion brennt. Die Pipeline ist langsam. Die Freigabe-Warteschlangen sind verstopft. Und ArgoCD, der loyale Vollstrecker Ihres deklarierten Zustands, macht Ihre Notfall-Fixes immer wieder rückgängig, weil sie nicht „den GitOps-Weg“ gegangen sind.
Genau das passierte einem Junior SRE, der mitten in der Nacht gepagt wurde. Konfrontiert mit einem Deployment-Problem, nutzte er kubectl edit, um die Sache zu flicken, und sah dann zu, wie ArgoCD seine Änderungen alle paar Minuten zurücksetzte. Der Clou: Die einzige Person mit Zugriff auf die ArgoCD-Plattform war nicht erreichbar. Am Ende standen acht Stunden Downtime, weil niemand die Automatisierung davon abhalten konnte, die Notfallarbeit rückgängig zu machen.
Solche Fälle passieren häufiger, als die meisten Teams zugeben wollen.
Drift Detection: Retter oder Saboteur?
Die Idee hinter Drift Detection ist edel: Jede Änderung außerhalb von Git soll markiert oder rückgängig gemacht werden. In Notfallszenarien wird das aber zum zweischneidigen Schwert. Wie ein Engineer es formulierte: „Manchmal muss man einfach das Feuer löschen.“
Dazu bleiben vielen Teams nur zwei Wege. Entweder setzen sie Drift Detection vorübergehend aus, beheben das Problem und aktivieren sie wieder, nachdem der PR gemergt wurde, falls das je passiert. Oder sie hacken sich mit Breakglass-Berechtigungen ins System, falls diese überhaupt existieren.
Und selbst dann liefert man sich ein Rennen mit der ArgoCD-Reconciliation-Loop. In manchen Setups macht sie den Fix in Millisekunden rückgängig, in anderen hat man vielleicht ein Drei-Minuten-Fenster, bevor sie den Cluster wieder in den kaputten Zustand zurücksetzt.
Das ArgoCD-Catch-22
Reden wir über ArgoCD, denn es taucht in fast jeder dieser Kriegsgeschichten auf. Es ist ein solides Tool und tut, was es verspricht. Aber es ist ihm egal, dass Ihre Freigabekette schläft oder dass Ihre CI-Pipeline ewig braucht. Es setzt den zuletzt deklarierten Zustand durch, egal wie veraltet der ist.
Das hat zu einigen … kreativen Lösungen geführt. Manche schalten Auto-Sync ab, indem sie das ArgoCD-Application-Objekt manuell bearbeiten (kubectl edit app argocd -n argocd). Andere leiten ArgoCD auf einen temporären PR-Branch um, um den langsamen Merge-Prozess zu umgehen. Und manche löschen einfach den ArgoCD-Server-Pod komplett, in der Hoffnung, dass er beim Zurückkommen seine Lektion gelernt hat (Spoiler: hat er nicht).
Das alles sind Verzweiflungstaktiken. Aber wenn die Produktion down ist, tritt Eleganz hinter Uptime zurück.
Warum haben Junioren überhaupt Prod-Zugriff?
Einer der am heißesten diskutierten Aspekte dieses Schlamassels ist die Zugriffskontrolle. Warum hat ein Junior SRE überhaupt Produktionsberechtigungen? Ist das ein Vertrauensbeweis, oder ein Zeichen, dass die On-Call-Rotation dringend umstrukturiert werden muss? Die Meinungen gehen auseinander.
Manche glauben, Junioren sollten nie First Responder für kritische Incidents sein. Andere argumentieren, dass man bei der Incident Response wirklich lernt, vorausgesetzt, ein Senior ist verfügbar, um mitzuschauen oder zu führen.
Das Problem liegt dabei nicht immer im Zugriff selbst, oft fehlt schlicht eine Support-Struktur. Einem Junior SRE die Schlüssel zur Produktion zu geben, ohne Guardrails, Anleitung oder einen klaren Breakglass-Prozess, ist fahrlässig.
Wie ein gutes Breakglass-Setup tatsächlich aussieht
Breakglass-Zugriff ist keine kontroverse Idee. Er soll genau für solche Situationen existieren, muss aber richtig gestaltet sein: auditierbar, sodass jede Nutzung protokolliert und überprüft wird; temporär, sodass der Zugriff automatisch abläuft; begründet, sodass jede Nutzung einen Grund und oft ein Postmortem verlangt; und zugänglich, sodass man nicht fünf Leute wecken oder eine Stunde warten muss, um ihn zu nutzen. Wenn Ihr „Notfallzugriff“ länger zum Entsperren braucht als die PR-Pipeline, wird er selbst zur Falle.
Ein Team beschrieb die Nutzung von AWS-IAM-Rollen, bei denen man über SSO eine spezielle „Breakglass“-Rolle annehmen kann, aber erst nach einem zusätzlichen Bestätigungsschritt. Das geht schnell, es ist sichtbar, und es zwingt Engineers, vor Änderungen zweimal nachzudenken, ohne sie zu blockieren, wenn jede Minute zählt.
Ist GitOps eigentlich das Problem?
Viele dieser Probleme entstehen durch eine schlechte Implementierung von GitOps.
Wenn Ihr GitOps-Flow zu langsam ist, um bei einem Incident nützlich zu sein, versagt das Pipeline-Design und nicht das Paradigma. Wenn Sie für ArgoCD-Zugriff auf einen einzigen Engineer angewiesen sind, haben Sie ein Menschen- und Prozessproblem und keine Tool-Beschränkung.
Und wenn Engineers das Gefühl haben, den Prozess brechen zu müssen, nur um Dinge schnell zu reparieren, bedeutet das wahrscheinlich, dass Ihr Prozess von Anfang an nicht für reales Chaos gebaut war.
Lektionen von der Front
Die Engineers in diesen Situationen sind erfinderisch. Sie wissen, dass das System zu retten manchmal bedeutet, die Regeln zu biegen. Aber sie sind auch frustriert, dass sie das müssen.
Ein paar Dinge könnten Teams tatsächlich tun, um GitOps-Schmerz in der Produktion zu reduzieren. Dokumentieren Sie das Notfall-Playbook, statt davon auszugehen, dass jeder weiß, wie man ArgoCD pausiert oder einen Sync umleitet; schreiben Sie es auf. Schaffen Sie schnelle Pfade für Prod-Hotfixes, denn wenn Ihr PR Stunden zum Mergen braucht, haben Sie kein Continuous Deployment, sondern Continuous Frustration. Richten Sie Webhooks in ArgoCD ein und verlassen Sie sich nicht länger auf Polling alle 3 Minuten, weil der Push-Modus schneller, weniger verwirrend und effizienter ist. Rotieren Sie den Zugriff, damit kritische Berechtigungen nicht von einer einzigen Person abhängen: Wenn Sie um 2 Uhr morgens jemanden brauchen, der Argo bearbeitet, sollte diese Person nicht unerreichbar sein.
Und vor allem: Führen Sie Postmortems durch. Wenn etwas richtig kaputtgeht, stellen Sie sicher, dass der nächste 2-Uhr-morgens-Responder mit mehr als nur Hoffnung arbeiten kann.
Fazit
GitOps funktioniert. Bei Ihrem Team wären wir uns da nicht so sicher.
Automatisierung ist nur so gut wie die Menschen dahinter. Und wenn die Menschen müde, unzureichend geschult oder ohne Unterstützung sind, können die besten Tools der Welt Sie nicht retten.
Also ja, ArgoCD heilt sich automatisch selbst. Aber es heilt nicht Ihre kaputten Prozesse, Ihren Mangel an Dokumentation oder das Fehlen eines Sicherheitsnetzes für Ihre jüngsten Engineers. Beheben Sie das, dann funktioniert GitOps auch im Ernstfall.