Was bedeutet Testen in Produktion für dich, und wie machst du es, ohne Dinge kaputt zu machen?

Es bedeutet, Verhalten gegen echten Traffic und echte Daten zu validieren, die keine Staging-Umgebung reproduzieren kann, mit Kontrollen, die den Schadensradius begrenzen. Die Techniken sind Feature Flags mit schrittweisem Rollout, Canary Releases, Synthetic Monitoring, das echte Journeys dauerhaft fährt, Shadow Traffic und automatisches Rollback anhand vorab definierter Metriken. Es ergänzt das Testen vor dem Release, es ersetzt es nicht.

Es bedeutet zu akzeptieren, dass Staging nie das Datenvolumen der Produktion hat, nicht ihren Traffic-Mix, nicht das Verhalten von Drittanbietern und nicht die zwölf Jahre seltsamer Datensätze, die echte Kunden erzeugt haben, und die Produktion bewusst zu nutzen, um zu lernen, was nur die Produktion lehren kann. Was das verantwortungsvoll statt leichtsinnig macht, ist die Begrenzung des Schadensradius. Neues Verhalten geht hinter ein Flag, standardmäßig aus, zuerst für interne Nutzer, dann ein Prozent, dann schrittweise breiter, mit vor dem Release definierten Metriken, die ein automatisches Rollback auslösen, statt während des Vorfalls darüber zu streiten. Daneben fahre ich Synthetic Monitoring: die kritischen Journeys, Registrierung, Login, Checkout, dauerhaft gegen die Produktion ausgeführt, damit wir es vor den Kunden merken und ein kaputter Drittanbieter sofort sichtbar ist. Für Backend-Änderungen mag ich außerdem Shadow Traffic, wo der neue Pfad echte Requests verarbeitet und Ergebnisse verglichen werden, ohne dass etwas ausgeliefert wird. Was ich immer klar sage: das ergänzt die früheren Schichten, es ersetzt sie nicht. Unit- und Integrationstests sichern weiterhin den Merge ab. Produktionsvalidierung als Grund zu nehmen, sie wegzulassen, ist der Weg, kaputte Software sehr selbstbewusst auszuliefern.