Prodon működik: mi ez, miért fordul elő és miért veszélyes

Mit jelent a „prodon működik” kifejezés

„Prodon működik” — ez egy bevett kifejezés a fejlesztők körében, amely azt a helyzetet írja le, amikor a kód az éles szerveren működik, de nem hajlandó működni a tesztkörnyezetben vagy a kolléga lokális gépén. Külsőleg úgy hangzik, hogy „nincs probléma”, pedig valójában a probléma létezik — csak nem reprodukálódik az éles környezetben. Az eltérés gyökere a környezetek közötti konfigurációs, verzió- és adatbeli különbségekben rejlik.

A kifejezés egy másik ismert kifogás — „Nálam lokálisan működik” — ellentéteként jött létre. Ha a fejlesztő azt mondja, „lokálisan működik”, az azt jelenti, hogy a hiba csak másoknál van. Ha pedig „prodon működik” — a hiba csak stagingen vagy a tesztkörnyezetben van, az éles környezet pedig tiszta. A sors iróniája: mindkét esetben a probléma valós, csak nem annál jelentkezik, aki nézi. A DevOps Research and Assessment (DORA) 2023 kutatása szerint a magas szintű telepítési automatizálással rendelkező csapatok 3-szor ritkábban találkoznak ilyen eltérésekkel.

Üzleti szempontból a „prodon működik” helyzet veszélyesebb, mint amilyennek látszik. Ha a hiba stagingen van, de élesben nem, a fejlesztő figyelmen kívül hagyhatja — és a következő telepítéskor a hiba átkerül az éles környezetbe. Átmeneti megkönnyebbülés egy jövőbeli problémává válik, amelyet a felhasználók nyomása alatt kell megoldani.

Miért mondják a fejlesztők, hogy „prodon működik”

A kifejezés fennmaradásának pszichológiai oka — védelmi reflex. Az a fejlesztő, aki stagingen látja a hibát, de élesben nem, tudat alatt lekicsinyelheti a problémát: „ha élesben minden rendben van, akkor ez nem sürgős”. Klasszikus kognitív torzítás — a túlélő hibája, ahol az éles környezet látható sikere felülmúlja a jövőbeli meghibásodás potenciális veszélyét.

A második ok — elmosódott felelősség. Ha az éles környezet működik, a staging pedig nem, a bűnös a környezet, nem a kód. A fejlesztő leveszi magáról a felelősséget a hibáért, áthárítva azt a DevOps-mérnökre vagy a rendszergazdára. Az Atlassian State of DevOps 2022 szerint az egységes telepítési környezet (Docker, Kubernetes) nélküli csapatokban 60%-kal gyakoribbak az ilyen felelősségáthárítások.

A harmadik ok — a nulla állásidővel történő kiadástól való félelem. Ha a fejlesztő kijavítja a hibát stagingen és kiadja a javítást, az újabb code review-t, tesztelést és deployt igényel. A „prodon működik” kifejezés lehetővé teszi a javítás elhalasztását a következő kiadásig, csökkentve az aktuális terhelést. Elhalasztott javítás — a technikai adósság felhalmozódásának egyik fő oka a csapatokban.

Különbség a fejlesztői és éles környezet között

Az éles környezet és a staging soha nem teljesen azonos — ez technikailag lehetetlen a méretbeli, terhelésbeli és adatbeli különbségek miatt. A legfontosabb paramétereknek azonban egyezniük kell: az operációs rendszer, a fordítóprogram, az értelmező, az adatbázis, a webszerver és a projekt összes függőségének verziója. Ha legalább egy paraméter eltér — a kód viselkedése megváltozhat.

A környezetek közötti fő különbségek a következők:

• Hardver — processzor, RAM mennyisége, lemez típusa (SSD vs HDD) befolyásolhatja az időzítést és a többszálúságot
• Hálózati környezet — tűzfal, DNS, proxy, terheléselosztók csak élesben vannak jelen
• Adatbázisban lévő adatok — stagingen általában tesztadatok, míg a valódi felhasználói rekordok váratlan mintázatokkal rendelkeznek
• Függőségek verziói — egy könyvtár apró frissítése is megváltoztathatja a kód viselkedését
• Környezeti változók — API-kulcsok, tokenek, funkciójelzők eltérhetnek a környezetek között

Konténeresítés megoldja a problémák nagy részét. Az éles környezethez épített Docker-képet stagingen is használni kell. Az egyetlen különbség — a környezeti változók és a volumen csatolások. A Docker State of Application Development 2023 szerint azok a csapatok, amelyek egyetlen képet használnak az összes környezethez, 74%-kal csökkentik az eltérések számát.

Az éles viselkedés eltérésének tipikus okai

Az első és leggyakoribb ok — a függőségek eltérő verziói. A fejlesztő lokálisan telepíti a csomagot a --save jelzővel, de elfelejti frissíteni a package.json-t vagy a lock-fájlt. Éles környezetbe telepítéskor egy másik verzió kerül telepítésre, amely másképp viselkedik. Az npm ökoszisztémában a lock-fájl teljesen megoldja a problémát, más csomagkezelőknél — hasonló mechanizmusok (Gemfile.lock, Podfile.lock, pubspec.lock).

A második ok — hiányzó vagy többlet környezeti változók. A fejlesztő .env fájlt használ a lokális gépen, de nem adja hozzá a megfelelő változókat a CI/CD pipeline-hoz vagy a szerverhez. Eredmény — a kód összeomlik az API-hoz vagy adatbázishoz való csatlakozási hibával. A GitLab DevSecOps Survey 2023 szerint az éles incidensek 27%-a helytelen környezeti változókhoz kapcsolódik.

A harmadik ok — az adatbázis állapota. Stagingen az adatbázis tartalmazhat olyan rekordokat, amelyek élesben nincsenek meg, vagy fordítva — hiányoznak a migrációk. Tipikus forgatókönyv: a fejlesztő olyan kódot ír, amely a tábla új mezőjével dolgozik, de a migrációt még nem alkalmazták élesben. Visszafelé kompatibilis migrációs stratégia — az egyetlen mód az ilyen helyzetek elkerülésére.

A negyedik ok — regionális és nyelvi beállítások. Dátumformázás, tizedes elválasztók, szövegkódolás — ezek mind eltérhetnek a fejlesztő lokális gépén és a szerveren. Különösen releváns a nemzetköziesítést alkalmazó projekteknél. Megoldás — a locale explicit megadása az alkalmazás konfigurációjában, és nem támaszkodni a rendszerbeállításokra.

A „prodon működik” probléma diagnosztizálása

Első lépés — a naplók összehasonlítása mindkét környezetben. A naplózási szint különbsége gyakran elrejti az okot: élesben INFO, stagingen DEBUG lehet bekapcsolva. Állítsa be ugyanazt a naplózási szintet, és győződjön meg arról, hogy mindkét környezet olyan formátumban ír, amely lehetővé teszi a gépi összehasonlítást. Használjon központosított naplógyűjtő rendszereket — Sentry, Datadog, ELK Stack.

Második lépés — a függőségek verzióinak ellenőrzése. Hasonlítsa össze a lock-fájlokat, listázza ki a telepített csomagokat mindkét környezetben. A minor vagy patch verzióbeli különbség — az eltérés legvalószínűbb oka. Az olyan eszközök, mint az npm ls, pip freeze, mvn dependency:tree, segítenek gyorsan feltárni az eltéréseket.

Harmadik lépés — az éles környezet lokális reprodukálása. Használja a Docker Compose-t vagy hasonló eszközöket az éles infrastruktúra pontos másolatának felállításához. Ha a hiba reprodukálódik a lokális konténerben — a probléma a kódban van, nem a környezetben. Ha nem reprodukálódik — keresse a különbséget a konfigurációban.

Negyedik lépés — a feature flag-ek és A/B tesztek ellenőrzése. Lehetséges, hogy élesben a kód más módban működik, mert a rossz jelző van bekapcsolva. A LaunchDarkly State of Feature Management 2023 szerint az éles környezetben tapasztalt váratlan viselkedés akár 40%-a is a helytelen feature flag értékekhez kapcsolódik. Egységes flag manifest az összes környezethez megoldja ezt a problémát.

A környezetek eltérésének megelőzése a projektben

A megelőzés fő eszköze — Infrastructure as Code (IaC). Az összes környezetet kódban kell leírni: Dockerfile, docker-compose.yml, Terraform szkriptek vagy Ansible playbook-ok. A kézi módosítások a szerveren tilosak — minden konfigurációs változtatás a repository-n és code review-n megy keresztül. Ez garantálja, hogy minden környezet azonos konfigurációval rendelkezik.

A második legfontosabb eszköz — egységes CI/CD pipeline. Ugyanazt a build, tesztelési és deploy szkriptet kell használni az összes környezethez. A különbség csak a célváltozókban van (URL, kulcsok). Ha a staging és az éles környezet pipeline-ja lépéseiben eltér — az eltérések elkerülhetetlenek.

A harmadik eszköz — automatikus adatszinkronizálás. Rendszeresen (naponta egyszer vagy ütemezés szerint) frissítse a staging-et az éles adatbázis anonimizált másolatával. Ez lehetővé teszi a kód tesztelését valós adatokon, nem szintetikus fixture-eken. Eszközök: pg_dump/pg_restore PostgreSQL-hez, mysqldump MySQL-hez, speciális szolgáltatások, mint a DataGrip.

Negyedik — az eltérések monitorozása. Állítson be értesítéseket a staging és az éles környezet közötti különbségek észlelésekor. Egy egyszerű szkript, amely összehasonlítja a konfigurációs fájlok hash-eit vagy a telepített csomagok verzióit, óráknyi hibakeresést takaríthat meg. A megelőzés mindig olcsóbb, mint a diagnózis: a környezetek eltérésének megelőzése kevesebb erőfeszítést igényel, mint a „prodon működik” hiba okának keresése.