Editing in Prod: Ein Liebesbrief an jeden SRE, der schon mal Glas zerbrochen hat

Es gibt eine Art von Panik, die sich nur um 2 Uhr morgens zeigt. Die Alerts schlagen an, Slack leuchtet auf, und irgendwo in den Schatten Ihres Terminals frisst sich ein Kubernetes-Deployment gerade selbst lebendig auf. Sie kennen den Ablauf: Git öffnen, einen PR einreichen, auf Genehmigung warten, ArgoCD synchronisieren lassen, vielleicht noch eine Kerze für gutes Gelingen anzünden. Nur breitet sich das Feuer schon aus, und heute Nacht warten Sie nicht.

Sie machen kubectl edit in Prod. Und wissen Sie was? Das ist okay.

In der Welt von GitOps, wo Infrastruktur Code ist und Deployments makellose, wiederholbare Rituale sein sollen, gibt es ein stilles, unausgesprochenes Einverständnis: Manchmal müssen Sie das Glas zerbrechen. Nicht aus Leichtsinn, sondern weil das System die Realität nicht eingeplant hat. Die Realität, in der Menschen schlafen, in der der einzige Ingenieur mit ArgoCD-Zugriff nicht erreichbar ist und in der die sorgfältig eingerichtete Sync-Policy Ihre Fixes schneller rückgängig macht, als Sie sie eintippen können.

Der DevOps-Traum trifft auf die 2-Uhr-Realität

Reden wir über GitOps, den heiligen Gral des modernen Kubernetes-Managements. Es verspricht Konsistenz, Auditierbarkeit und selbstheilende Infrastruktur. Tools wie ArgoCD und Flux beobachten Git-Repos laufend und stellen sicher, dass das Laufende dem Versionierten entspricht. Das klingt großartig, bis die Person, die Ihren Hotfix genehmigen kann, mitten im REM-Schlaf steckt und Ihr Cluster schreit.

Ein Nutzer brachte es am besten auf den Punkt: "Editieren Sie in Prod, während Sie auf die Genehmigung des PR warten. Manchmal müssen Sie einfach das Feuer löschen." Genau da liegt der Kernkonflikt, zwischen der verträumten CI/CD-Pipeline und dem kalten, einsamen Schlachtfeld des echten Ops-Alltags. Wenn Ihr Name auf dem Pager steht, löschen Ideale keine Incidents.

Die Sync-Schleife unter Druck

ArgoCD fühlt sich bei aller Schönheit wie ein rachsüchtiger Geist an, sobald man einen Notfall-Fix versucht. Es erkennt Ihre manuellen Änderungen und macht sie innerhalb von Millisekunden fröhlich rückgängig, nicht aus Boshaftigkeit, sondern weil es genau das tut, was ihm gesagt wurde. "Mit ArgoCD im Autoheal-Modus", schrieb ein Ingenieur, "können Sie so oft manuell editieren, wie Sie wollen. Es geht immer wieder zurück." Es ist Whack-a-Mole mit den eigenen YAML-Dateien.

Die Cleveren kennen den Workaround und deaktivieren Auto-Sync vorübergehend. Selbst das setzt aber die richtigen Zugriffsrechte voraus, die in mehr als einer Horrorgeschichte auf einen einzigen leitenden Ingenieur beschränkt sind, der gerade nicht erreichbar ist. Eine arme Seele sah acht Stunden am Stück zu, wie ArgoCD ihre kubectl-Änderungen rückgängig machte, weil niemand sonst den Sync stoppen konnte. Das ist ein Systemversagen.

GitOps ist nicht der Feind, schlechte Prozesse sind es

Die Spannung besteht nicht zwischen GitOps und kubectl, sondern zwischen starren Prozessen und den Menschen, die sie unterstützen sollen. Niemand sagt, Sie sollten jeden Tag Cowboy-Coding in Prod betreiben. Aber wenn Ihre Optionen "auf das Mergen des PR warten" und "Kundendaten verlieren" lauten, sieht kubectl edit plötzlich gar nicht mehr so böse aus.

Ein Principal SRE steuerte Weisheit bei: "Zugriff auf Prod sollte einen Breakglass-Account erfordern. Nichts Umständliches, nur überwacht, protokolliert und mit Pflicht zum Postmortem." Das ist die Balance. Machen Sie es leicht zu handeln und schwer zu vergessen. Für Ihren Job sollten Sie kein Gebet und keinen Slack-Rant brauchen.

Das eigentliche Verbrechen ist nicht der Edit in Prod, sondern der Bau von Systemen, die Ihren jungen SRE um 2 Uhr morgens allein mit dem Pager sitzen lassen, ohne Unterstützung und ohne Werkzeuge.

Cowboy-Kultur vs. Leitplanken, die funktionieren

Viele Organisationen kämpfen sich noch aus der Cowboy-DevOps-Kultur heraus. Sie kennen den Typ: keine Genehmigungen, keine Audits, nur Vibes und Root-Zugriff. Dann schlagen sie in die andere Richtung aus, wickeln jede Aktion in roten Bürokratie-Faden und schreiben Freigaben vor, die unter Druck nicht skalieren.

Die gesündesten Teams bauen für beides. Sie gehen davon aus, dass Incidents passieren werden, und geben Ingenieuren sichere, dokumentierte, umkehrbare Wege, um schnell zu handeln. Das kann bedeuten, Auto-Sync abzuschalten, ArgoCD auf einen temporären Patch-Branch zu zeigen oder, Schock, einen manuellen Edit mit klaren Rollback-Anweisungen zu machen. Wichtig ist, dass es eine bewusste Entscheidung ist und kein Akt der Verzweiflung.

GitOps, aber menschlich gemacht

Eine der differenzierteren Aussagen aus dem Feld: "GitOps ist nicht nur Git, das in den Cluster pusht. Es ist auch Reconciliation, Automatisierung und, wenn nötig, Kontrolle." Was GitOps-Puristen manchmal übersehen: Die beste Infrastruktur ist für die Menschen entworfen, die sie betreiben.

Das heißt, Platz für kontrollierbares Chaos zu schaffen, und es heißt zu verstehen, dass Selbstheilung selbstzerstörerisch werden kann, wenn die Selbstwahrnehmung fehlt. Und ja, es heißt auch anzuerkennen, dass ein Edit in Prod kein Versagen ist, sondern ein Signal, dass Ihr System eine bessere Notfalltür braucht.

Ein Liebesbrief, mit Logging

Also ein Hoch auf die, die aufgeblieben sind: die jungen Ingenieure, die den Pager bekamen, weil niemand sonst konnte, und die erfahrenen Kollegen, die ihnen die Werkzeuge und das Vertrauen gaben, zu handeln. Ein Hoch auch auf die, die den Sync deaktivierten, den Fix machten und dann das Postmortem schrieben, das allen beibrachte, was beim nächsten Mal zu tun ist.

Cowboys sind sie nicht. Sie sind Notfallpläne in Aktion. Halten Sie Ihr kubectl griffbereit, und erzählen Sie Git davon, sobald das Feuer gelöscht ist.