På prod fungerar det: vad det är, varför det uppstår och varför det är farligt

Vad betyder frasen “på prod fungerar det”

“På prod fungerar det” — detta är ett etablerat uttryck bland utvecklare som beskriver en situation där koden fungerar på produktionsservern men vägrar att fungera i testmiljön eller på en kollegas lokala maskin. Utåt låter det som “inget problem”, men i verkligheten finns problemet — det reproduceras bara inte i produktionsmiljön. Orsaken till skillnaden ligger i skillnader i konfigurationer, versioner och data mellan miljöerna.

Frasen uppstod som en motsats till en annan känd ursäkt — “Hos mig lokalt fungerar det”. Om utvecklaren säger “lokalt fungerar det” betyder det att buggen bara finns hos andra. Och om “på prod fungerar det” — finns buggen bara på staging eller i testmiljön, men produktionen är ren. Ödets ironi: i båda fallen är problemet verkligt, det visar sig bara inte hos den som tittar. Enligt forskningen från DevOps Research and Assessment (DORA) 2023 stöter team med hög nivå av driftsättningsautomatisering på sådana skillnader 3 gånger mer sällan.

Ur affärssynpunkt är situationen “på prod fungerar det” farligare än den verkar. Om buggen finns på staging men inte i produktion kan utvecklaren ignorera den — och vid nästa driftsättning kommer felet att hamna i produktion. Tillfällig lättnad förvandlas till ett framtida problem som måste lösas under användarnas press.

Varför säger utvecklare “på prod fungerar det”

Den psykologiska orsaken till att frasen består — försvarsreflex. En utvecklare som ser buggen på staging men inte i produktion kan omedvetet bagatellisera problemet: “om allt är bra i produktion är det inte brådskande”. En klassisk kognitiv bias — överlevnadsfelet, där produktionens synliga framgång väger tyngre än det potentiella hotet om framtida haveri.

Den andra orsaken — diffust ansvar. Om produktionen fungerar och staging inte gör det, är miljön boven, inte koden. Utvecklaren fråntar sig ansvaret för buggen och skjuter över det på DevOps-ingenjören eller administratören. Enligt Atlassian State of DevOps 2022 förekommer sådana ansvarsövervältringar 60% oftare i team utan enhetlig driftsättningsmiljö (Docker, Kubernetes).

Den tredje orsaken — rädsla för release med noll driftstopp. Om utvecklaren fixar buggen på staging och rullar ut korrigeringen kräver detta ny code review, testning och deploy. Frasen “på prod fungerar det” möjliggör uppskjutande av korrigeringen till nästa release, vilket minskar den aktuella belastningen. Uppskjuten korrigering — en av huvudorsakerna till ackumulering av teknisk skuld i team.

Skillnad mellan utvecklings- och produktionsmiljöer

Produktion och staging är aldrig helt identiska — detta är tekniskt omöjligt på grund av skillnader i skala, belastning och data. Nyckelparametrar måste dock överensstämma: versionen av operativsystemet, kompilatorn, interpretatorn, databasen, webbservern och alla projektets beroenden. Om minst en parameter skiljer sig — kan kodens beteende förändras.

Huvudskillnaderna mellan miljöerna inkluderar:

• Hårdvara — processor, RAM-mängd, disktyp (SSD vs HDD) kan påverka timing och flertrådning
• Nätverksmiljö — brandvägg, DNS, proxy, lastbalanserare finns bara i produktion
• Data i databasen — på staging finns vanligtvis testdata, medan verkliga användarposter har oväntade mönster
• Versioner av beroenden — även en mindre uppdatering av ett bibliotek kan ändra kodens beteende
• Miljövariabler — API-nycklar, tokens, funktionsflaggor kan skilja sig mellan miljöer

Containerisering löser de flesta av dessa problem. Docker-avbildningen som byggs för produktion bör användas även på staging. Den enda skillnaden — miljövariabler och volymmonteringar. Enligt Docker State of Application Development 2023 minskar team som använder en enhetlig avbildning för alla miljöer antalet avvikelser med 74%.

Typiska orsaker till beteendeavvikelser i produktion

Den första och vanligaste orsaken — olika versioner av beroenden. En utvecklare installerar ett paket lokalt med flaggan --save, men glömmer att uppdatera package.json eller låsfilen. Vid driftsättning i produktion installeras en annan version som beter sig annorlunda. För npm-ekosystemet löser låsfilen problemet helt, för andra pakethanterare — liknande mekanismer (Gemfile.lock, Podfile.lock, pubspec.lock).

Den andra orsaken — saknade eller överflödiga miljövariabler. Utvecklaren använder en .env-fil på den lokala maskinen men lägger inte till motsvarande variabler i CI/CD-pipelinen eller på servern. Resultat — koden kraschar med ett anslutningsfel till API eller databas. Enligt GitLab DevSecOps Survey 2023 är 27% av incidenterna i produktion relaterade till felaktiga miljövariabler.

Den tredje orsaken — databasens tillstånd. På staging kan databasen innehålla poster som inte finns i produktion, eller omvänt — migreringar saknas. Typiskt scenario: utvecklaren skriver kod som arbetar med ett nytt fält i en tabell, men migreringen har ännu inte tillämpats i produktion. Migreringsstrategi med bakåtkompatibilitet — det enda sättet att undvika sådana situationer.

Den fjärde orsaken — regionala och språkliga inställningar. Datumformatering, decimalavskiljare, textkodning — allt detta kan skilja sig på utvecklarens lokala maskin och servern. Särskilt relevant för projekt med internationalisering. Lösning — explicit ange locale i applikationskonfigurationen och inte förlita sig på systeminställningar.

Hur man diagnostiserar problemet “på prod fungerar det”

Första steget — jämför loggar från båda miljöerna. Skillnaden i loggningsnivå döljer ofta orsaken: i produktion kan INFO vara aktiverat, på staging DEBUG. Ställ in samma loggningsnivå och se till att båda miljöerna skriver i ett format som möjliggör maskinell jämförelse. Använd centraliserade system för logginsamling — Sentry, Datadog, ELK Stack.

Andra steget — kontrollera versioner av beroenden. Jämför låsfilerna, visa listan över installerade paket i båda miljöerna. Skillnad i minor- eller patchversion — den mest sannolika orsaken till avvikelse. Verktyg som npm ls, pip freeze, mvn dependency:tree hjälper att snabbt upptäcka avvikelser.

Tredje steget — reproducera produktionsmiljön lokalt. Använd Docker Compose eller liknande verktyg för att sätta upp en exakt kopia av produktionsinfrastrukturen. Om buggen reproduceras i en lokal container — ligger problemet i koden, inte i miljön. Om inte — sök efter skillnaden i konfigurationen.

Fjärde steget — kontrollera feature flags och A/B-tester. Kanske fungerar koden i produktion i ett annat läge för att fel flagga är aktiverad. Enligt LaunchDarkly State of Feature Management 2023 är upp till 40% av oväntat beteende i produktion relaterat till felaktiga värden på feature flags. Enhetligt flaggmanifest för alla miljöer löser detta problem.

Förebygga miljöskillnader i projektet

Huvudverktyget för förebyggande — Infrastructure as Code (IaC). Alla miljöer måste beskrivas i kod: Dockerfile, docker-compose.yml, Terraform-skript eller Ansible-playbooks. Manuella ändringar på servern är förbjudna — varje konfigurationsändring går genom repository och code review. Detta garanterar att alla miljöer har samma konfiguration.

Det näst viktigaste verktyget — enhetlig CI/CD-pipeline. Samma bygg-, test- och driftsättningsskript ska användas för alla miljöer. Skillnaden är bara i målvariablerna (URL, nycklar). Om pipeline för staging och produktion skiljer sig i steg — är avvikelser oundvikliga.

Det tredje verktyget — automatisk datasynkronisering. Uppdatera regelbundet (en gång om dagen eller enligt schema) staging med en anonymiserad kopia av produktionsdatabasen. Detta gör det möjligt att testa kod på verklig data, inte på syntetiska fixture. Verktyg: pg_dump/pg_restore för PostgreSQL, mysqldump för MySQL, specialiserade tjänster som DataGrip.

Det fjärde — övervakning av avvikelser. Konfigurera aviseringar vid upptäckt av skillnader mellan staging och produktion. Ett enkelt skript som jämför hashar av konfigurationsfiler eller versioner av installerade paket sparar timmar av felsökning. Förebyggande är alltid billigare än diagnostik: att förebygga miljöskillnader kräver mindre ansträngning än att söka efter orsaken till buggen “på prod fungerar det”.