Staging lügt
Die Freigabe kam aus Staging, grün über die ganze Linie. Drei Wochen später brennt in Prod ein Pfad, den Staging nie gesehen hat.
- Datum
- Thema
- Staging-Parität
- Quellen
- 2
- Lesezeit
- 2 Min.
Das Muster kenne ich aus vielen Setups: Staging heißt „wie Prod, nur kleiner“. Meistens stimmt nur der zweite Teil des Satzes.
Abbildung als Text
Paritäts-Tabelle Staging gegen Prod mit fünf Zeilen: Injection (Sidecar fehlt oder veraltet gegen injiziert, aktuelle Revision), Policies (PERMISSIVE plus Default-Allow gegen STRICT plus Default-Deny), Egress (ALLOW_ANY gegen REGISTRY_ONLY plus ServiceEntries), CP-Revision (Rollout übersprungen gegen aktuelle Revision) und Limits (keine oder großzügig, kaum Last gegen eng gesetzt, unter echter Last). Die Staging-Spalte trägt je Zeile einen roten Abweichungs-Marker, die Prod-Spalte ist der Referenzzustand. Darunter die Paritäts-Checkliste: diese fünf Punkte je Umgebung prüfen, Abweichungen mit Grund dokumentieren. Pointe: Der billigste Incident ist der, der in Staging passiert.
Die Deltas, die ich am häufigsten finde, sitzen im Mesh selbst. Fünf Stück, in der Reihenfolge, in der sie mir in Incident-Calls begegnen.
Injection. In Staging läuft der Sidecar oft gar nicht oder in einer älteren Variante, weil das letzte Rollout dort übersprungen wurde. Wer ohne Proxy testet, testet ein anderes Netzwerk.
Policies. AuthorizationPolicy und PeerAuthentication stehen in Staging häufig lockerer, PERMISSIVE statt STRICT, Default-Allow statt Default-Deny (Post 15). Ein Request, der in Staging durchgeht, sagt nichts darüber, ob er in Prod überhaupt ankommt.
Egress. Ist Staging beim alten ALLOW_ANY geblieben (Post 16) und Prod längst auf REGISTRY_ONLY, meldet ein externer Aufruf in Staging Erfolg und läuft in Prod gegen die Wand, weil der ServiceEntry fehlt.
Revision. Zwei Umgebungen an zwei verschiedenen Control-Plane-Revisionen (Post 20) sind zwei verschiedene Meshes mit ähnlichem Namen.
Limits. In Staging läuft der Sidecar ohne enge Ressourcen-Limits und ohne echte Last. In Prod steht derselbe Proxy eng gesetzt am Anschlag, unter der Last, die den Unterschied macht. Wer die Sidecar-Kosten aus Post 22 in Staging misst, bekommt deshalb saubere Zahlen für ein anderes System.
Die meisten Incidents, die „nur in Prod reproduzierbar“ waren, entpuppten sich am Ende als (Teil-)Menge dieser Liste, nachträglich nach der ungewollten Nachtschicht erstellt.
Eine Kopie von Prod bis aufs letzte Byte ist nie realistisch. Realistisch ist eine Paritäts-Checkliste für diese fünf Punkte, plus eine bewusste Entscheidung: Wo Staging abweicht, steht die Abweichung mit Grund im Dokument. Alles andere ist ein Incident, der auf seinen Prod-Termin wartet.
Die Rechnung dahinter ist einfach. Der billigste Incident ist der, der in Staging passiert. Jede Abweichung, die Staging durchwinkt, wandert nach Prod. Dort kostet sie das Gleiche, nur mit massivem Kunden-Feedback.
Staging, das nicht wenigstens die Mesh-Konfiguration von Prod teilt, testet nicht eure Anwendung. Es testet ein anderes System, das zufällig denselben Namen trägt.
Welches der fünf Deltas trifft euch am ehesten: Injection, Policies, Egress, Revision oder Limits?
