Na prodě funguje: co to je, proč vzniká a čím je nebezpečné

Co znamená fráze „na prodě funguje”

„Na prodě funguje” — je ustálený výraz v prostředí vývojářů, který označuje situaci, kdy kód funguje na produkčním serveru, ale odmítá pracovat v testovacím prostředí nebo na lokálním počítači kolegy. Navenek to zní jako „není problém”, i když ve skutečnosti problém existuje — jen se nereprodukuje v produkčním prostředí. Kořen rozdílu spočívá v rozdílnosti konfigurací, verzí a dat mezi prostředími.

Fráze vznikla jako protiklad jiné známé výmluvy — „U mě lokálně funguje”. Pokud vývojář říká „lokálně funguje”, znamená to, že chyba existuje jen u ostatních. A pokud „na prodě funguje” — chyba existuje jen na stagingu nebo v testovacím prostředí, ale produkce je čistá. Ironie osudu: v obou případech je problém reálný, jen se projevuje u někoho jiného než u toho, kdo se dívá. Podle výzkumu DevOps Research and Assessment (DORA) 2023 se týmy s vysokou úrovní automatizace nasazování setkávají s takovými rozdíly 3krát méně často.

Z obchodního hlediska je situace „na prodě funguje” nebezpečnější, než se zdá. Pokud je chyba na stagingu, ale ne v produkci, vývojář ji může ignorovat — a při příštím nasazení chyba přejde do produkce. Dočasná úleva se mění v budoucí problém, který bude muset být řešen pod tlakem uživatelů.

Proč vývojáři říkají „na prodě funguje”

Psychologický důvod setrvání této fráze — obranný reflex. Vývojář, který vidí chybu na stagingu, ale ne v produkci, může podvědomě bagatelizovat problém: „když je v produkci všechno v pořádku, tak to není naléhavé”. Klasická kognitivní zaujatost — chyba přeživšího, kde viditelný úspěch produkce převažuje nad potenciální hrozbou budoucího selhání.

Druhý důvod — rozmazaná odpovědnost. Pokud produkce funguje a staging ne, viníkem je prostředí, ne kód. Vývojář zbavuje sám sebe odpovědnosti za chybu a přesouvá ji na DevOps inženýra nebo správce. Podle Atlassian State of DevOps 2022 dochází v týmech bez jednotného prostředí nasazování (Docker, Kubernetes) k takovému přesouvání odpovědnosti o 60 % častěji.

Třetí důvod — strach z vydání s nulovým výpadkem. Pokud vývojář opraví chybu na stagingu a nasadí opravu, bude to vyžadovat nový code review, testování a deploy. Fráze „na prodě funguje” umožňuje odložit opravu na příští vydání, čímž snižuje aktuální zátěž. Odložená oprava — jeden z hlavních důvodů hromadění technického dluhu v týmech.

Rozdíl mezi vývojovým a produkčním prostředím

Produkce a staging nejsou nikdy zcela identické — to je technicky nemožné kvůli rozdílům v měřítku, zátěži a datech. Klíčové parametry by se však měly shodovat: verze operačního systému, kompilátoru, interpretu, databáze, webového serveru a všech závislostí projektu. Pokud se liší alespoň jeden parametr — chování kódu se může změnit.

Hlavní rozdíly mezi prostředími zahrnují:

• Hardware — procesor, množství RAM, typ disku (SSD vs HDD) mohou ovlivnit načasování a práci s více vlákny
• Síťové prostředí — firewall, DNS, proxy, load balancery jsou přítomny jen v produkci
• Data v databázi — na stagingu jsou obvykle testovací data, zatímco skutečné uživatelské záznamy mají neočekávané vzorce
• Verze závislostí — i malá aktualizace knihovny může změnit chování kódu
• Proměnné prostředí — API klíče, tokeny, příznaky funkcí se mohou mezi prostředími lišit

Kontejnerizace řeší většinu těchto problémů. Docker image vytvořený pro produkci by se měl používat i na stagingu. Jediný rozdíl — proměnné prostředí a připojení svazků. Podle Docker State of Application Development 2023 snižují týmy používající jednotný image pro všechna prostředí počet rozdílů o 74 %.

Typické příčiny neshody chování v produkci

První a nejčastější příčina — různé verze závislostí. Vývojář nainstaluje balíček lokálně s příznakem --save, ale zapomene aktualizovat package.json nebo lock soubor. Při nasazení do produkce se nainstaluje jiná verze, která se chová odlišně. Pro ekosystém npm lock soubor problém zcela řeší, pro ostatní správce balíčků — analogické mechanismy (Gemfile.lock, Podfile.lock, pubspec.lock).

Druhá příčina — chybějící nebo nadbytečné proměnné prostředí. Vývojář používá .env soubor na lokálním počítači, ale nepřidá odpovídající proměnné do CI/CD pipeline nebo na server. Výsledek — kód padá s chybou připojení k API nebo databázi. Podle GitLab DevSecOps Survey 2023 souvisí 27 % incidentů v produkci s nesprávnými proměnnými prostředí.

Třetí příčina — stav databáze. Na stagingu může databáze obsahovat záznamy, které v produkci nejsou, nebo naopak — chybět migrace. Typický scénář: vývojář píše kód pracující s novým polem v tabulce, ale migrace ještě nebyla aplikována v produkci. Migrační strategie se zpětnou kompatibilitou — jediný způsob, jak se takovým situacím vyhnout.

Čtvrtá příčina — regionální a jazyková nastavení. Formátování dat, oddělovače desetinných čísel, kódování textu — to vše se může lišit na lokálním počítači vývojáře a serveru. Zvláště relevantní pro projekty s internacionalizací. Řešení — explicitně uvést locale v konfiguraci aplikace a nespoléhat se na systémová nastavení.

Jak diagnostikovat problém „na prodě funguje”

První krok — porovnat logy obou prostředí. Rozdíl v úrovni logování často skrývá příčinu: v produkci může být zapnutý INFO, na stagingu DEBUG. Nastavte stejnou úroveň logování a ujistěte se, že obě prostředí zapisují ve formátu umožňujícím strojové porovnání. Používejte centralizované systémy sběru logů — Sentry, Datadog, ELK Stack.

Druhý krok — zkontrolovat verze závislostí. Porovnejte lock soubory, zobrazte seznam nainstalovaných balíčků v obou prostředích. Rozdíl v minor nebo patch verzi — nejpravděpodobnější příčina rozdílu. Nástroje jako npm ls, pip freeze, mvn dependency:tree pomohou rychle odhalit nesrovnalosti.

Třetí krok — reprodukovat produkční prostředí lokálně. Použijte Docker Compose nebo podobné nástroje k vytvoření přesné kopie produkční infrastruktury. Pokud se chyba reprodukuje v lokálním kontejneru — problém je v kódu, ne v prostředí. Pokud ne — hledejte rozdíl v konfiguraci.

Čtvrtý krok — zkontrolovat feature flags a A/B testy. Je možné, že v produkci kód pracuje v jiném režimu, protože je zapnutý nesprávný přepínač. Podle LaunchDarkly State of Feature Management 2023 souvisí až 40 % neočekávaného chování v produkci s nesprávnými hodnotami feature flags. Jednotný manifest přepínačů pro všechna prostředí tento problém řeší.

Prevence rozdílů prostředí v projektu

Hlavní nástroj prevence — Infrastructure as Code (IaC). Všechna prostředí musí být popsána v kódu: Dockerfile, docker-compose.yml, skripty Terraform nebo playbooky Ansible. Ruční změny na serveru jsou zakázány — každá změna konfigurace prochází repozitářem a code review. To zaručuje, že všechna prostředí mají stejnou konfiguraci.

Druhý nejdůležitější nástroj — jednotné CI/CD pipeline. Stejný skript sestavení, testování a nasazení by se měl používat pro všechna prostředí. Rozdíl je pouze v cílových proměnných (URL, klíče). Pokud se pipeline pro staging a produkci liší v krocích — rozdíly jsou nevyhnutelné.

Třetí nástroj — automatická synchronizace dat. Pravidelně (jednou denně nebo podle plánu) aktualizujte staging anonymizovanou kopií produkční databáze. To umožňuje testovat kód na skutečných datech, ne na syntetických fixture. Nástroje: pg_dump/pg_restore pro PostgreSQL, mysqldump pro MySQL, specializované služby jako DataGrip.

Čtvrtý — monitorování rozdílů. Nastavte upozornění při zjištění rozdílů mezi stagingem a produkcí. Jednoduchý skript porovnávající hashe konfiguračních souborů nebo verze nainstalovaných balíčků ušetří hodiny ladění. Prevence je vždy levnější než diagnostika: předcházení rozdílům prostředí vyžaduje méně úsilí než hledání příčiny chyby „na prodě funguje”.