Editing in Prod: Ein Liebesbrief an jeden SRE, der schon mal Glas zerbrochen hat
Es gibt eine bestimmte 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 eine Kerze für gutes Gelingen anzünden. Aber das Feuer breitet sich schon aus – und heute Nacht warten Sie nicht.
Sie machen kubectl edit in Prod.
Und raten Sie mal? 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 weil Sie leichtsinnig sind, 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. 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 kontinuierlich Git-Repos und stellen sicher, dass das, was läuft, dem entspricht, was versioniert ist. 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." Und das ist der Kernkonflikt – eine verträumte CI/CD-Pipeline gegen das kalte, einsame Schlachtfeld des echten Ops-Alltags. Denn wenn Ihr Name auf dem Pager steht, löschen Ideale keine Incidents.
Die Sync-Schleife unter Druck
ArgoCD kann sich bei aller Schönheit wie ein rachsüchtiger Geist anfühlen, wenn Sie versuchen, einen Notfall-Fix zu machen. 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 wie Whack-a-Mole mit den eigenen YAML-Dateien.
Die Cleveren kennen den Workaround: Auto-Sync vorübergehend deaktivieren. Aber selbst das setzt voraus, dass Sie die richtigen Zugriffsrechte haben, was – in mehr als einer Horrorgeschichte – auf einen einzigen leitenden Ingenieur beschränkt ist, der gerade unerreichbar 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 nicht nur frustrierend. Das ist ein Systemversagen.
GitOps ist nicht der Feind – schlechte Prozesse sind es
Die Spannung besteht nicht zwischen GitOps und kubectl. Sie besteht zwischen starren Prozessen und den Menschen, die sie eigentlich unterstützen sollen. Niemand sagt, Sie sollten jeden Tag Cowboy-Coding in Prod betreiben. Aber wenn Ihre Optionen "auf das Mergen des PR warten" oder "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, aber schwer zu vergessen. Sie sollten kein Gebet und keinen Slack-Rant brauchen, um Ihren Job zu machen.
Das eigentliche Verbrechen ist nicht das Editieren in Prod – es ist der Bau von Systemen, die Ihren jungen SRE um 2 Uhr morgens allein mit dem Pager sitzen lassen, ohne Unterstützung oder Werkzeuge.
Cowboy-Kultur vs. Leitplanken, die funktionieren
Viele Organisationen kämpfen sich noch immer 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 und wickeln jede Aktion in roten Bürokratie-Faden und verpflichtende Freigaben, 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 Entscheidung ist – 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, ist, dass die beste Infrastruktur für die Menschen entworfen ist, die sie betreiben.
Das bedeutet, Platz für kontrollierbares Chaos zu schaffen.
Das bedeutet zu verstehen, dass Selbstheilung selbstzerstörerisch sein kann, wenn man nicht auch Selbstwahrnehmung hat.
Und ja, das bedeutet anzuerkennen, dass "Editieren in Prod" kein Versagen ist – es ist ein Signal, dass Ihr System eine bessere Notfalltür braucht.
Ein Liebesbrief, mit Logging
Also, hier ist ein Hoch auf die, die aufgeblieben sind. Die jungen Ingenieure, die den Pager bekamen, weil niemand sonst konnte. Die erfahrenen Kollegen, die ihnen die Werkzeuge und das Vertrauen gaben, zu handeln. Die, die den Sync deaktivierten, den Fix machten und dann das Postmortem schrieben, das allen beibrachte, was beim nächsten Mal zu tun ist.
Sie sind keine Cowboys. Sie sind Notfallpläne in Aktion.
Halten Sie Ihr kubectl griffbereit – vergessen Sie nur nicht, Git davon zu erzählen, wenn das Feuer gelöscht ist.