Op prod werkt het: wat het is, waarom het ontstaat en waarom het gevaarlijk is

Wat betekent de frase „op prod werkt het”

„Op prod werkt het” — dit is een vaste uitdrukking in de ontwikkelaarsgemeenschap die een situatie beschrijft waarin code werkt op de productieserver maar weigert te werken in de testomgeving of op de lokale machine van een collega. Uiterlijk klinkt het als „geen probleem”, terwijl het probleem in werkelijkheid wel bestaat — het reproduceert zich alleen niet in de productieomgeving. De oorzaak van het verschil ligt in de verschillen in configuraties, versies en gegevens tussen omgevingen.

De frase is ontstaan als tegenhanger van een ander bekend excuus — „Bij mij lokaal werkt het”. Als een ontwikkelaar zegt „lokaal werkt het”, betekent dit dat de bug alleen bij anderen bestaat. En als „op prod werkt het” — bestaat de bug alleen op staging of in de testomgeving, maar is de productie schoon. Ironie van het lot: in beide gevallen is het probleem reëel, het manifesteert zich alleen niet bij degene die kijkt. Volgens het DevOps Research and Assessment (DORA) 2023-onderzoek krijgen teams met een hoog niveau van implementatieautomatisering 3 keer minder vaak te maken met dergelijke verschillen.

Vanuit zakelijk oogpunt is de situatie „op prod werkt het” gevaarlijker dan het lijkt. Als de bug op staging zit maar niet in productie, kan de ontwikkelaar het negeren — en bij de volgende implementatie gaat de fout naar productie. Tijdelijke verlichting verandert in een toekomstig probleem dat onder druk van gebruikers moet worden opgelost.

Waarom zeggen ontwikkelaars „op prod werkt het”

De psychologische reden voor het voortbestaan van de frase — verdedigingsreflex. Een ontwikkelaar die de bug op staging ziet maar niet in productie, kan het probleem onbewust bagatelliseren: „als alles goed is in productie, is het niet urgent”. Een klassieke cognitieve bias — de overlevingsfout, waarbij het zichtbare succes van productie zwaarder weegt dan de potentiële dreiging van een toekomstige storing.

De tweede reden — vage verantwoordelijkheid. Als productie werkt en staging niet, is de omgeving de schuldige, niet de code. De ontwikkelaar ontneemt zichzelf de verantwoordelijkheid voor de bug en schuift deze af op de DevOps-engineer of beheerder. Volgens Atlassian State of DevOps 2022 komen dergelijke verschuivingen van verantwoordelijkheid 60% vaker voor in teams zonder uniforme implementatieomgeving (Docker, Kubernetes).

De derde reden — angst voor een release met zero downtime. Als de ontwikkelaar de bug op staging repareert en de correctie uitrolt, vereist dit opnieuw code review, testen en deployen. De frase „op prod werkt het” stelt uitstel van de correctie tot de volgende release mogelijk, waardoor de huidige werkdruk afneemt. Uitgestelde correctie — een van de belangrijkste oorzaken van de opbouw van technische schuld in teams.

Verschil tussen ontwikkel- en productieomgevingen

Productie en staging zijn nooit volledig identiek — dit is technisch onmogelijk vanwege verschillen in schaal, belasting en gegevens. De belangrijkste parameters moeten echter overeenkomen: de versie van het besturingssysteem, compiler, interpreter, database, webserver en alle afhankelijkheden van het project. Als ten minste één parameter verschilt — kan het gedrag van de code veranderen.

De belangrijkste verschillen tussen omgevingen zijn:

• Hardware — processor, hoeveelheid RAM, schijftype (SSD vs HDD) kunnen timing en multithreading beïnvloeden
• Netwerkomgeving — firewall, DNS, proxy, load balancers zijn alleen aanwezig in productie
• Gegevens in de database — op staging zijn meestal testgegevens, terwijl echte gebruikersregistraties onverwachte patronen hebben
• Versies van afhankelijkheden — zelfs een kleine update van een bibliotheek kan het gedrag van code veranderen
• Omgevingsvariabelen — API-sleutels, tokens, feature flags kunnen verschillen tussen omgevingen

Containerisatie lost de meeste van deze problemen op. De Docker-image die voor productie is gebouwd, moet ook op staging worden gebruikt. Het enige verschil — omgevingsvariabelen en volume-mounts. Volgens Docker State of Application Development 2023 verminderen teams die één image voor alle omgevingen gebruiken het aantal verschillen met 74%.

Typische oorzaken van gedragsverschillen in productie

De eerste en meest voorkomende oorzaak — verschillende versies van afhankelijkheden. Een ontwikkelaar installeert een pakket lokaal met de vlag --save, maar vergeet package.json of het lock-bestand bij te werken. Bij implementatie in productie wordt een andere versie geïnstalleerd die zich anders gedraagt. Voor het npm-ecosysteem lost het lock-bestand het probleem volledig op, voor andere pakketbeheerders — vergelijkbare mechanismen (Gemfile.lock, Podfile.lock, pubspec.lock).

De tweede oorzaak — ontbrekende of overbodige omgevingsvariabelen. Een ontwikkelaar gebruikt een .env-bestand op de lokale machine, maar voegt de bijbehorende variabelen niet toe aan de CI/CD-pipeline of op de server. Resultaat — de code crasht met een fout bij het verbinden met API of database. Volgens GitLab DevSecOps Survey 2023 is 27% van de incidenten in productie gerelateerd aan onjuiste omgevingsvariabelen.

De derde oorzaak — de toestand van de database. Op staging kan de database records bevatten die niet in productie zijn, of omgekeerd — migraties ontbreken. Een typisch scenario: een ontwikkelaar schrijft code die werkt met een nieuw veld in een tabel, maar de migratie is nog niet toegepast in productie. Migratiestrategie met achterwaartse compatibiliteit — de enige manier om dergelijke situaties te voorkomen.

De vierde oorzaak — regionale en taalinstellingen. Datumnotatie, decimale scheidingstekens, tekstcodering — dit alles kan verschillen op de lokale machine van de ontwikkelaar en de server. Bijzonder relevant voor projecten met internationalisatie. Oplossing — expliciet de locale opgeven in de applicatieconfiguratie en niet vertrouwen op systeeminstellingen.

Hoe het probleem „op prod werkt het” te diagnosticeren

De eerste stap — logs vergelijken van beide omgevingen. Het verschil in logniveau verbergt vaak de oorzaak: in productie kan INFO zijn ingeschakeld, op staging DEBUG. Stel hetzelfde logniveau in en zorg ervoor dat beide omgevingen in een formaat schrijven dat machinale vergelijking mogelijk maakt. Gebruik gecentraliseerde logs verzamelsystemen — Sentry, Datadog, ELK Stack.

De tweede stap — versies van afhankelijkheden controleren. Vergelijk lock-bestanden, toon de lijst met geïnstalleerde pakketten in beide omgevingen. Een verschil in minor- of patchversie — de meest waarschijnlijke oorzaak van divergentie. Hulpmiddelen zoals npm ls, pip freeze, mvn dependency:tree helpen snel inconsistenties op te sporen.

De derde stap — de productieomgeving lokaal reproduceren. Gebruik Docker Compose of vergelijkbare hulpmiddelen om een exacte kopie van de productie-infrastructuur op te zetten. Als de bug reproduceert in een lokale container — ligt het probleem in de code, niet in de omgeving. Zo niet — zoek dan het verschil in configuratie.

De vierde stap — feature flags en A/B-tests controleren. Mogelijk werkt de code in productie in een andere modus omdat de verkeerde vlag is ingeschakeld. Volgens LaunchDarkly State of Feature Management 2023 wordt tot 40% van het onverwachte gedrag in productie veroorzaakt door onjuiste waarden van feature flags. Eén manifest voor flags voor alle omgevingen lost dit probleem op.

Voorkomen van omgevingsverschillen in het project

Het belangrijkste hulpmiddel voor preventie — Infrastructure as Code (IaC). Alle omgevingen moeten in code worden beschreven: Dockerfile, docker-compose.yml, Terraform-scripts of Ansible-playbooks. Handmatige wijzigingen op de server zijn verboden — elke configuratiewijziging doorloopt de repository en code review. Dit garandeert dat alle omgevingen dezelfde configuratie hebben.

Het tweede belangrijkste hulpmiddel — uniforme CI/CD-pipeline. Hetzelfde build-, test- en deploy-script moet voor alle omgevingen worden gebruikt. Het verschil zit alleen in de doelvariabelen (URL, sleutels). Als de pipeline voor staging en productie verschilt in stappen — zijn divergenties onvermijdelijk.

Het derde hulpmiddel — automatische gegevenssynchronisatie. Werk staging regelmatig (eenmaal per dag of volgens schema) bij met een geanonimiseerde kopie van de productiedatabase. Hiermee kan code worden getest op echte gegevens in plaats van synthetische fixtures. Hulpmiddelen: pg_dump/pg_restore voor PostgreSQL, mysqldump voor MySQL, gespecialiseerde diensten zoals DataGrip.

Het vierde — monitoring van divergentie. Stel meldingen in bij detectie van verschillen tussen staging en productie. Een eenvoudig script dat hashes van configuratiebestanden of versies van geïnstalleerde pakketten vergelijkt, bespaart uren aan debugging. Preventie is altijd goedkoper dan diagnose: het voorkomen van omgevingsverschillen vereist minder moeite dan het zoeken naar de oorzaak van de bug „op prod werkt het”.