Im Flugbetrieb fliegt niemand einen kritischen Anflug allein, nur weil er sich sicher fühlt. Man bespricht den Ablauf, konfiguriert das Flugzeug, und eine zweite Person liest die wichtigen Werte zurück. Nicht, weil Piloten unfähig wären. Sondern weil müde, kompetente Menschen Dinge falsch lesen. Weil Kontextwechsel Fehler verstecken. Weil „ich habe es zweimal geprüft“ oft nur bedeutet, dass man dieselbe falsche Annahme zweimal geprüft hat.

Kollegen prüfen gemeinsam Arbeit auf einem Laptop

Foto von Brooke Cagle auf Unsplash

Kubernetes-Änderungen bringen in der Regel niemanden um. Ich sage das so direkt, weil der Vergleich mit der Luftfahrt leicht überstrapaziert wird. Sie können aber Daten löschen, Services freilegen, Kapazität abziehen oder aus einem Freitags-Deploy ein Wochenende in einer Störungsbesprechung machen. Die Gewohnheit aus dem Cockpit — vor dem Ausführen gegenzuprüfen — passt besser zu kubectl apply, als ich beim Berufswechsel erwartet hatte.

In diesem Beitrag geht es um eine schlanke Prüfungskultur für Konfigurationsänderungen: was man prüft, wer prüft und wie das gelingt, ohne eine Bürokratie zu bauen, die am Ende alle ignorieren.

Was „Gegenprüfung“ hier bedeutet

Ich meine kein formales Change Advisory Board für jeden Tippfehler in einer ConfigMap. Ich meine einen bewussten zweiten Blick auf Änderungen, bei denen der Wirkungsradius real ist.

Gegenprüfung bedeutet:

Jemand anderes als der Autor prüft die Änderung gegen die Absicht. Nicht „sieht gut aus“, sondern: „Das passt zu dem, was im Ticket vereinbart wurde.“

Kritische Felder werden laut genannt oder deutlich markiert. Namespace, Cluster-Kontext, Image-Tag, Anzahl der Replicas, Ingress-Host, Resource Limits, Secret-Referenzen, Helm Values, die Standardeinstellungen überschreiben.

Der Rollback wird vor dem Anwenden einmal ausgesprochen. Wenn man in einem Satz nicht erklären kann, wie man zurückkommt, hält man an.

Die Umgebung wird bestätigt. kubectl config current-context ist keine Zeremonie. Ich habe schon auf den falschen Cluster angewendet. Wahrscheinlich bin ich damit nicht allein.

In der Luftfahrt nannten wir Teile davon Challenge-and-Response. In Betriebsteams heißt es Zwei-Personen-Regel, Vier-Augen-Prinzip oder einfach „hol dir eine Prüfung“. Das Etikett ist weniger wichtig als das Verhalten: Eine Person führt aus, eine prüft, und die Rollen sind klar.

Warum allein anwenden schneller wirkt, es aber nicht ist

Wer das YAML geschrieben hat, füllt Lücken im Kopf. Man weiß, dass staging gemeint war, obwohl in der Datei production steht. Man weiß, dass der Image-Tag v2.1.4 der Hotfix ist und nicht der kaputte Build mit demselben Präfix. Man weiß, warum --force dort steht, weil man es vor drei Tagen im Standup erklärt hat.

Die prüfende Person trägt diese Vorgeschichte nicht mit. Sie liest, was wirklich auf der Seite steht.

Allein anzuwenden versteckt außerdem Zeitdruck. „Das muss vor der Demo raus“ ist die Art Satz, nach der Namespaces überschrieben werden. Eine zweite Person nimmt den Druck nicht weg, schafft aber einen Moment für: „Warte, dieser Service ist ClusterIP; wir brauchten LoadBalancer.“

Kleine Änderungen in Dev-Namespaces wende ich weiterhin allein an. Ich predige keine Reinheit. Ich meine: Die Strenge muss zum Risiko passen, und über dieses Risiko sollte man ehrlich sein.

Eine Preflight-Checkliste, die man wirklich nutzt

Checklisten scheitern, wenn sie vierzig Punkte lang sind und niemand sie liest. Das ist die kurze Liste, die ich vor Änderungen mit Wirkung auf die Produktionsumgebung nutze. Anpassen ist ausdrücklich erwünscht; es geht um Struktur, nicht um meine genaue Formulierung.

Absicht

  • Welches Problem löst diese Änderung?
  • Woran sieht man Erfolg: an Metriken oder am Verhalten?
  • Ist das die kleinste Änderung, die funktionieren kann?

Umfang

  • Welcher Cluster, welcher Namespace und welche Workloads sind betroffen?
  • Hängt außerhalb dieses Diffs etwas vom neuen Wert ab?
  • Gibt es parallele Änderungen durch andere Menschen oder Pipelines?

Diff prüfen

  • Den ganzen Diff lesen, nicht nur den bearbeiteten Abschnitt.
  • Auf versehentliche Leerzeichen, falsche YAML-Einrückung und doppelte Keys achten.
  • Bei Helm: die gerenderte Ausgabe prüfen, nicht nur values.yaml. helm template oder helm diff upgrade, falls vorhanden.

Sicherheit

  • Probes, PDBs, HPA min/max — bleibt der Cluster während des Rollouts verfügbar?
  • Resource Requests/Limits — läuft ein Pod in OOM oder hungert eine Node aus?
  • Secrets — neue Referenzen, rotierte Keys, Verzögerungen bei externen Secrets?
  • NetworkPolicy oder Ingress — unbeabsichtigte Freigabe oder blockierter Datenverkehr?

Rollback

  • Ist die vorige Revision bekannt? (kubectl rollout history, Git revert, Helm rollback)
  • Sind Datenmigrationen rückwärtskompatibel?
  • Gibt es eine Zeitgrenze: Wann gilt es als gescheitert und wird zurückgerollt?

Kommunikation

  • Wer muss wissen, dass diese Änderung passiert?
  • Gibt es ein steriles Fenster oder einen Change Freeze?

Ausdrucken, anpinnen, ins PR-Template schreiben. Dieselbe Liste gilt für GitOps-Merges, wenn das Anwenden später über eine Pipeline passiert. Die Checkliste gehört zur Änderung, nicht speziell zu kubectl.

Vier Augen ohne Aufführung

Der typische Fehler beim Vier-Augen-Prinzip ist Checkbox-Kultur: Die prüfende Person genehmigt in dreißig Sekunden, weil sie vertraut oder zum Mittagessen will. Das ist schlechter als allein anzuwenden, weil Prozess dazukommt, aber keine Sicherheit.

Was hilft:

Prüfende Personen rotieren. Das immer gleiche Paar entwickelt gemeinsame blinde Flecken.

Prüfende Personen führen Befehle aus, nicht nur GitHub-Kommentare. Bei GitOps prüft man das gerenderte Manifest im PR. Bei imperativen Änderungen hält die zweite Person das zweite Terminal und bestätigt den Kontext, bevor Enter gedrückt wird.

Autor und ausführende Person trennen, wenn möglich. Bei GitOps ist der Merge die Autorenschaft; der Sync kann die Ausführung sein. In der kubectl-Welt bereitet der Autor den Branch vor, die ausführende Person wendet nach dem Zurücklesen an.

Die Prüfung zeitlich begrenzen. Fünf fokussierte Minuten sind besser als ein vages LGTM Stunden später, wenn niemand den Kontext noch im Kopf hat.

Weniger erfahrene Prüfer willkommen heißen. Eine weniger erfahrene Person, die fragt „warum ist das privileged?“, ist Gold wert. Ich habe mehr aus einfachen Fragen gelernt, die ich nicht beantworten konnte, als aus erfahrenem Nicken.

Was nicht hilft:

Zwei Direktoren für einen Tippfehler zu verlangen.

Prüfungen, die nur Formatierung betrachten.

Abnick-Bots mit menschlichem Avatar.

kubectl, Helm und GitOps brauchen jeweils eine etwas andere Brille

Die Checkliste ist dieselbe; die Werkzeuge bringen eigene Fallen mit.

kubectl apply

Kontext und Namespace sind das klassische Fehlerpaar. Ich sage sie laut: „Kontext ist prod-eu, Namespace ist payments.“

Bei server-side apply sollte man Field Ownership beachten, wenn CI und manuelle Änderungen gemischt werden. Der Diff lokal ist nicht zwingend der Diff, den der Apiserver zusammenführt.

Bei -f-Verzeichnissen prüfen, ob nicht ein altes Manifest aus einem Experiment mit eingelesen wird.

--dry-run=server ist die paar Sekunden wert, wenn die API Admission validieren kann.

Helm

Values-Dateien entfernen sich von Chart-Defaults auf Arten, die in einem einzeiligen PR unsichtbar bleiben. Rendern und vergleichen.

Chart-Versionen können Labels und Selectors so ändern, dass ReplicaSets verwaisen. Release Notes lesen.

Upgrades mit --wait: Weiß die prüfende Person, was „wait“ als Erfolg wertet? Eine kaputte Probe kann ewig blockieren.

Ein Rollback mit Helm ist nicht immer symmetrisch, wenn Hooks oder CRDs geändert wurden. Das gehört ins Briefing.

GitOps (Argo CD und Verwandte)

Das Anwenden passiert später. Das ist gut für Prüfung und schlecht für Selbstzufriedenheit. Merge ist nicht Deployment; Sync ist Deployment. Wenn Auto-Sync aktiv ist, muss beides betrachtet werden.

Auf Override-Parameter, --force-Sync-Optionen und Prune-Einstellungen achten. Prune löscht Dinge, die nicht in Git stehen. Das ist mächtig und leicht zu genehmigen, ohne es wirklich zu verstehen.

Drift durch manuelles kubectl ist ein Vertrauensproblem. Wenn jemand letzte Woche die Produktionsumgebung gepatcht hat, kann die geprüfte Git-Änderung beim Sync mit dem Cluster kämpfen. Gegenprüfung heißt auch: „Ist der Live-Zustand das, was wir glauben?“

Multi-Source-Apps und Helm-Umbrellas vervielfachen Diff-Rauschen. Langsamer werden, wenn ein PR drei Charts und ein Kustomize-Overlay berührt.

PM-Denken ohne PM-Titel

Man braucht keinen Projektmanager, um bei Konfigurationsänderungen so zu denken. Man braucht ein Briefing.

Vor der Prüfung schreibt der Autor fünf Zeilen ins Ticket oder in die PR-Beschreibung:

  1. Erwartetes Ergebnis für Nutzer oder System.
  2. Betroffene Cluster und Namespaces.
  3. Schritte für den Rollback.
  4. Metriken oder Logs, die danach fünfzehn Minuten beobachtet werden.
  5. Zuständige Person im Bereitschaftsdienst, falls es schiefgeht.

Die prüfende Person hält die Änderung gegen diese fünf Zeilen. Wenn der Diff ein anderes Problem löst als das Ticket, stoppt man.

So funktionierten Flugbriefings: dieselben Daten, zwei Menschen, explizites Go/No-Go. PM-Denken heißt hier eigentlich: keine überraschenden Änderungen. Überraschungen gehören in Störungen, nicht in Deployments.

Wann mehr als eine Peer-Prüfung nötig ist

Manche Änderungen verdienen einen größeren Kreis:

  • Erster Einsatz einer neuen CRD oder eines Operators mit clusterweiten Rechten.
  • Änderungen an IAM, Zertifikatsvertrauen oder Identity Provider.
  • Änderungen an StorageClass oder Default-StorageClass.
  • Netzwerkpfade für regulierte Daten.
  • Alles, was gemeinsame Plattform-Namespaces berührt, auf die andere Teams angewiesen sind.

Eskalation ist keine Schande. Sie erkennt nur den Umfang an.

Ich habe Teams gesehen, die das übersprungen haben, weil das YAML klein aussah. Ein zehnzeiliger ClusterRoleBinding kann mehr erlauben als ein hundertzeiliges Deployment.

Was ich immer noch falsch mache

Ich werde schnell, wenn ich der Experte bin. Expertise lässt mich das Zurücklesen überspringen, weil „ich das schon hundertmal gemacht habe“. Genau dann wende ich das falsche Overlay an.

Ich behandle den Git-Merge als fertig, obwohl er nur die Hälfte ist. Der PR war geprüft; der Sync um zwei Uhr morgens nicht.

Ich vergesse, dass Prüfende Zeit für Kontext brauchen. Einen PR fallen zu lassen und „brauche das in zehn Minuten“ zu schreiben, garantiert Theater.

Ich wende allein an, wenn mir der Fehler peinlich ist, der zur Änderung geführt hat. Peinlichkeit ist kein Risikomodell.

Abschluss

Konfiguration gegenzuprüfen ist kein Misstrauen gegenüber Einzelnen. Es ist Respekt vor Komplexität und menschlichen Grenzen. Die Luftfahrt hat das nicht erfunden, weil Copiloten Dekoration wären. Sie hat es erfunden, weil ein Anflug sicherer ist, wenn zwei Menschen sich einig sind, was die Instrumente zeigen.

Beim nächsten Change, der jemanden wecken würde, wenn er scheitert: eine zweite Person, eine kurze Checkliste, Kontext und Rollback laut zurücklesen. Kein Guru nötig. Nur eine Gewohnheit, die müde Dienstagnachmittage überlebt.

Ein konkreter Anfang: ein Feld im PR-Template: „Prüfende Person hat Cluster/Namespace und Rollback verifiziert.“ Den Haken erst setzen, wenn jemand anderes als der Autor es laut gesagt hat. Kleine Reibung, echte Sicherheit.