Funktioniert auf Prod: Was es ist, warum es auftritt und warum es gefährlich ist

Was bedeutet „funktioniert auf Prod“

„Funktioniert auf Prod“ ist ein feststehender Ausdruck unter Entwicklern, der eine Situation beschreibt, in der Code auf dem Produktionsserver funktioniert, sich aber weigert, in der Testumgebung oder auf dem lokalen Rechner eines Kollegen zu arbeiten. Äußerlich klingt es wie „ kein Problem“, obwohl das Problem tatsächlich existiert — es kann nur in der Produktionsumgebung nicht reproduziert werden. Die Ursache der Diskrepanz liegt in unterschiedlichen Konfigurationen, Versionen und Daten zwischen den Umgebungen.

Der Satz entstand als Gegenstück zu einer anderen bekannten Ausrede — „Auf meinem Rechner funktioniert es“. Wenn ein Entwickler sagt „es funktioniert lokal“, existiert der Bug nur für andere. Wenn aber „es funktioniert auf Prod“, tritt der Bug nur im Staging oder in der Testumgebung auf, während die Produktion sauber ist. Die Ironie des Schicksals: in beiden Fällen ist das Problem real, es zeigt sich nur nicht bei der Person, die hinschaut. Laut der DevOps Research and Assessment (DORA) 2023 Studie stoßen Teams mit hohem Automatisierungsgrad beim Deployment 3-mal seltener auf solche Diskrepanzen.

Aus geschäftlicher Sicht ist die Situation „funktioniert auf Prod“ gefährlicher als sie scheint. Wenn ein Bug im Staging, aber nicht in der Produktion vorhanden ist, könnte der Entwickler ihn ignorieren — und dann geht der Fehler mit dem nächsten Deployment in die Produktion. Eine vorübergehende Erleichterung verwandelt sich in ein zukünftiges Problem, das unter dem Druck der Benutzer behoben werden muss.

Warum Entwickler „funktioniert auf Prod“ sagen

Der psychologische Grund für die Beständigkeit des Satzes ist ein Schutzreflex. Ein Entwickler, der einen Bug im Staging, aber nicht in der Produktion sieht, kann das Problem unbewusst herunterspielen: „Wenn in der Produktion alles gut ist, ist es nicht dringend“. Ein klassischer kognitiver Bias — Survivorship Bias, bei dem der sichtbare Erfolg der Produktion die potenzielle Bedrohung eines zukünftigen Ausfalls überwiegt.

Der zweite Grund ist verschwommene Verantwortung. Wenn die Produktion funktioniert, aber das Staging nicht, ist die Umgebung schuld, nicht der Code. Der Entwickler entledigt sich der Verantwortung für den Bug und schiebt sie auf den DevOps-Ingenieur oder Administrator. Laut dem Atlassian State of DevOps 2022 kommen in Teams ohne einheitliche Deployment-Umgebung (Docker, Kubernetes) solche Schuldzuweisungen 60% häufiger vor.

Der dritte Grund ist die Angst vor einem Release ohne Ausfallzeit. Wenn der Entwickler den Bug im Staging behebt und die Korrektur ausrollt, erfordert dies eine weitere Code-Review, Tests und Deployment. Der Satz „funktioniert auf Prod“ erlaubt es, die Korrektur bis zum nächsten Release zu verschieben und die aktuelle Arbeitslast zu reduzieren. Aufgeschobene Korrekturen sind eine der Hauptursachen für die Anhäufung technischer Schulden in Teams.

Unterschied zwischen Entwicklungs- und Produktionsumgebungen

Produktion und Staging sind nie vollständig identisch — das ist technisch unmöglich aufgrund von Unterschieden in Umfang, Last und Daten. Allerdings müssen die Schlüsselparameter übereinstimmen: die Version des Betriebssystems, Compilers, Interpreters, der Datenbank, des Webservers und aller Projektabhängigkeiten. Wenn auch nur ein Parameter abweicht, kann sich das Verhalten des Codes ändern.

Die wichtigsten Unterschiede zwischen den Umgebungen umfassen:

• Hardware — Prozessor, RAM-Größe, Festplattentyp (SSD vs HDD) können Zeitabläufe und Multithreading-Leistung beeinflussen
• Netzwerkumgebung — Firewall, DNS, Proxy, Load-Balancer sind nur in der Produktion vorhanden
• Daten in der DB — im Staging befinden sich normalerweise Testdaten, während echte Benutzerdaten unerwartete Muster aufweisen
• Abhängigkeitsversionen — selbst ein Minor-Update einer Bibliothek kann das Codeverhalten ändern
• Umgebungsvariablen — API-Schlüssel, Tokens, Feature-Flags können zwischen Umgebungen variieren

Containerisierung löst die meisten dieser Probleme. Das gleiche für die Produktion erstellte Docker-Image sollte auch im Staging verwendet werden. Der einzige Unterschied sind Umgebungsvariablen und Volume-Mounts. Laut dem Docker State of Application Development 2023 reduzieren Teams, die ein einheitliches Image in allen Umgebungen verwenden, Diskrepanzen um 74%.

Typische Ursachen für abweichendes Verhalten in der Produktion

Die erste und häufigste Ursache sind unterschiedliche Abhängigkeitsversionen. Ein Entwickler installiert ein Paket lokal mit dem Flag --save, vergisst aber, die package.json oder die Lock-Datei zu aktualisieren. Bei der Bereitstellung in der Produktion wird eine andere Version installiert, die sich anders verhält. Für das npm-Ökosystem löst die Lock-Datei das Problem vollständig; für andere Paketmanager gibt es analoge Mechanismen (Gemfile.lock, Podfile.lock, pubspec.lock).

Die zweite Ursache sind fehlende oder überschüssige Umgebungsvariablen. Ein Entwickler verwendet eine .env-Datei auf seinem lokalen Rechner, fügt die entsprechenden Variablen aber nicht in die CI/CD-Pipeline oder auf den Server ein. Das Ergebnis: Der Code stürzt mit einem API- oder Datenbank-Verbindungsfehler ab. Laut der GitLab DevSecOps Survey 2023 stehen 27% der Vorfälle in der Produktion im Zusammenhang mit falschen Umgebungsvariablen.

Die dritte Ursache ist der Datenbankzustand. Im Staging kann die Datenbank Einträge enthalten, die es in der Produktion nicht gibt, oder umgekehrt — Migrationen könnten fehlen. Ein typisches Szenario: Ein Entwickler schreibt Code, der mit einem neuen Feld in der Tabelle arbeitet, aber die Migration wurde noch nicht in der Produktion angewendet. Eine Migrationsstrategie mit Rückwärtskompatibilität ist der einzige Weg, solche Situationen zu vermeiden.

Die vierte Ursache sind regionale und Spracheinstellungen. Datumsformatierung, Dezimaltrennzeichen, Textkodierung — all das kann auf dem lokalen Rechner des Entwicklers und dem Server unterschiedlich sein. Dies ist besonders relevant für Projekte mit Internationalisierung. Die Lösung ist, das Gebietsschema explizit in der Anwendungskonfiguration anzugeben und sich nicht auf Systemeinstellungen zu verlassen.

Wie man das Problem „funktioniert auf Prod“ diagnostiziert

Der erste Schritt ist Logs von beiden Umgebungen zu vergleichen. Ein Unterschied im Logging-Level versteckt oft die Ursache: in der Produktion könnte INFO aktiviert sein, während im Staging DEBUG läuft. Konfigurieren Sie das gleiche Logging-Level und stellen Sie sicher, dass beide Umgebungen in einem Format schreiben, das einen maschinellen Vergleich ermöglicht. Verwenden Sie zentrale Log-Erfassungssysteme — Sentry, Datadog, ELK Stack.

Der zweite Schritt ist die Überprüfung der Abhängigkeitsversionen. Vergleichen Sie die Lock-Dateien, listen Sie die installierten Pakete in beiden Umgebungen auf. Ein Unterschied in einer Minor- oder Patch-Version ist die wahrscheinlichste Ursache für die Diskrepanz. Tools wie npm ls, pip freeze, mvn dependency:tree helfen, Unstimmigkeiten schnell zu identifizieren.

Der dritte Schritt ist die Produktionsumgebung lokal zu reproduzieren. Verwenden Sie Docker Compose oder ähnliche Tools, um eine exakte Kopie der Produktionsinfrastruktur zu erstellen. Wenn der Bug in einem lokalen Container reproduziert werden kann, liegt das Problem im Code, nicht in der Umgebung. Wenn nicht, suchen Sie nach einem Unterschied in der Konfiguration.

Der vierte Schritt ist Feature-Flags und A/B-Tests zu überprüfen. Möglicherweise läuft der Code in der Produktion in einem anderen Modus, weil das falsche Flag aktiviert ist. Laut dem LaunchDarkly State of Feature Management 2023 stehen bis zu 40% des unerwarteten Verhaltens in der Produktion im Zusammenhang mit falschen Feature-Flag-Werten. Ein einheitliches Flag-Manifest für alle Umgebungen löst dieses Problem.

Vermeidung von Umgebungsunterschieden im Projekt

Das wichtigste Präventionswerkzeug ist Infrastructure as Code (IaC). Alle Umgebungen sollten im Code beschrieben werden: Dockerfile, docker-compose.yml, Terraform-Skripte oder Ansible-Playbooks. Manuelle Änderungen auf dem Server sind verboten — jede Konfigurationsänderung durchläuft das Repository und Code-Review. Dies stellt sicher, dass alle Umgebungen die gleiche Konfiguration haben.

Das zweitwichtigste Werkzeug ist eine einheitliche CI/CD-Pipeline. Das gleiche Build-, Test- und Deployment-Skript sollte für alle Umgebungen verwendet werden. Der einzige Unterschied sind die Zielvariablen (URLs, Schlüssel). Wenn sich die Pipeline für Staging und Produktion in den Schritten unterscheidet, sind Diskrepanzen unvermeidlich.

Das dritte Werkzeug ist die automatische Datensynchronisation. Aktualisieren Sie regelmäßig (täglich oder nach Zeitplan) das Staging mit einer anonymisierten Kopie der Produktionsdatenbank. Dies ermöglicht das Testen von Code mit echten Daten anstelle von synthetischen Fixtures. Werkzeuge: pg_dump/pg_restore für PostgreSQL, mysqldump für MySQL, spezialisierte Dienste wie DataGrip.

Das vierte Werkzeug ist die Überwachung von Abweichungen. Richten Sie Benachrichtigungen ein, wenn Unterschiede zwischen Staging und Produktion erkannt werden. Ein einfaches Skript, das die Hashes von Konfigurationsdateien oder die Versionen installierter Pakete vergleicht, spart Stunden beim Debuggen. Prävention ist immer billiger als Diagnose: Umgebungsunterschiede zu verhindern erfordert weniger Aufwand, als die Ursache des Bugs „funktioniert auf Prod“ zu finden.