На проду ради: шта је то, зашто настаје и чему је опасно

Шта значи фраза „на проду ради”

„На проду ради” — ово је ustaljeni izraz у окружењу програмера, који означава ситуацију када код ради на продукцијском серверу, али одбија да ради у тестном окружењу или на локалној машини колеге. Споља то звучи као „нема проблема”, иако у стварности проблем постоји — само се не репродукује у продукцијском окружењу. Корен разилажења је у разлици конфигурација, верзија и података између окружења.

Фраза је настала као antipod друге познате изговоре — „Код мене локално ради”. Ако програмер каже „локално ради”, значи грешка постоји само код других. А ако „на проду ради” — грешка постоји само на стејџингу или тестном окружењу, а продукција је чиста. Иронија судбине: у оба случаја проблем је реалан, само се манифестује код онога ко не гледа. Према истраживању DevOps Research and Assessment (DORA) 2023, тимови са високим нивоом аутоматизације развоја сусрећу се са оваквим разилажењима 3 пута ређе.

Са пословне тачке гледишта, ситуација „на проду ради” је опаснија него што изгледа. Ако грешка постоји на стејџингу, али не и на проду, програмер може да је игнорише — и тада ће при следећем деплоју грешка отићи на продукцију. Привремено олакшање претвара се у будући проблем који ће морати да се решава под притиском корисника.

Зашто програмери говоре „на проду ради”

Психолошки узрок постојаности фразе — одбрамбени рефлекс. Програмер који види грешку на стејџингу, али не и на проду, може подсвесно да умањује проблем: „кад је на продукцији све у реду, онда није хитно”. Класична когнитивна пристрасност — грешка преживелог, где видљиви успех продукције претеже потенцијалну претњу будућег квара.

Други узрок — замагљена одговорност. Ако продукција ради, а стејџинг не, кривац је окружење, а не код. Програмер скида одговорност за грешку са себе, пребацујући је на DevOps инжењера или администратора. Према Atlassian State of DevOps 2022, у тимовима без јединственог окружења за развој (Docker, Kubernetes) ова пребацивања одговорности дешавају се 60% чешће.

Трећи узрок — страх од издања са нултим застојем. Ако програмер поправи грешку на стејџингу и објави исправку, то ће захтевати поновни code review, тестирање и деплој. Фраза „на проду ради” омогућава одлагање исправке до следећег издања, смањујући тренутно оптерећење. Одложена исправка — један од главних узрока нагомилавања техничког дуга у тимовима.

Разлика између окружења за развој и продукције

Продукција и стејџинг никада нису потпуно идентични — то је технички немогуће због разлике у обиму, оптерећењу и подацима. Међутим, кључни параметри морају се поклапати: верзија оперативног система, компајлера, интерпретера, базе података, веб-сервера и свих зависности пројекта. Ако се макар један параметар разликује — понашање кода може се променити.

Главне разлике између окружења укључују:

• Хардвер — процесор, количина RAM-а, тип диска (SSD vs HDD) могу утицати на тајминг и рад вишедимензионалности
• Мрежно окружење — firewall, DNS, proxy, балансери оптерећења присутни су само на проду
• Подаци у бази — на стејџингу су обично тест подаци, а стварни кориснички записи имају неочекиване обрасце
• Верзије зависности — чак и мања измена библиотеке може променити понашање кода
• Променљиве окружења — API кључеви, токени, флег-ови функција могу се разликовати између окружења

Контејнеризација решава већину ових проблема. Docker имиџ направљен за продукцију треба користити и на стејџингу. Једина разлика — променљиве окружења и volume монтирања. Према Docker State of Application Development 2023, тимови који користе јединствени имиџ за сва окружења смањују број разилажења за 74%.

Типични узроци неусаглашености понашања на проду

Први и најчешћи узрок — различите верзије зависности. Програмер инсталира пакет локално са заставицом --save, али заборавља да ажурира package.json или lock-фајл. При деплоју на продукцију инсталира се друга верзија која се понаша другачије. За npm екосистем lock-фајл потпуно решава проблем, за друге менаџере пакета — аналогни механизми (Gemfile.lock, Podfile.lock, pubspec.lock).

Други узрок — недостајуће или вишак променљивих окружења. Програмер користи .env фајл на локалној машини, али не додаје одговарајуће променљиве у CI/CD пајплајн или на сервер. Резултат — код пада са грешком повезивања на API или базу података. Према GitLab DevSecOps Survey 2023, 27% инцидената на проду повезано је са некоректним променљивама окружења.

Трећи узрок — стање базе података. На стејџингу база података може садржати записе којих нема на проду, или обрнуто — недостају миграције. Типичан сценарио: програмер пише код који ради са новим пољем у табели, али миграција још није примењена на проду. Миграциона стратегија са уназадном компатибилношћу — једини начин да се избегну овакве ситуације.

Четврти узрок — регионална и језичка подешавања. Форматирање датума, раздвајачи разломљених бројева, кодирање текста — све се то може разликовати на локалној машини програмера и серверу. Посебно актуелно за пројекте са интернационализацијом. Решење — експлицитно навести locale у конфигурацији апликације и не ослањати се на системска подешавања.

Како дијагностиковати проблем „на проду ради”

Први корак — упоредити логове оба окружења. Разлика у нивоу логовања често скрива узрок: на проду може бити укључен INFO, а на стејџингу DEBUG. Подесите исти ниво логовања и уверите се да оба окружења пишу у формату који омогућава машинско поређење. Користите централизоване системе за прикупљање логова — Sentry, Datadog, ELK Stack.

Други корак — проверити верзије зависности. Упоредите lock-фајлове, прикажите листу инсталираних пакета на оба окружења. Разлика у minor или patch верзији — највероватнији узрок разилажења. Алати попут npm ls, pip freeze, mvn dependency:tree помоћи ће да брзо откријете неусаглашености.

Трећи корак — репродуковати окружење продукције локално. Користите Docker Compose или сличне алате за подизање тачне копије продукцијске инфраструктуре. Ако се грешка репродукује у локалном контејнеру — проблем је у коду, а не у окружењу. Ако се не репродукује — тражите разлику у конфигурацији.

Четврти корак — проверити feature flags и A/B тестове. Могуће је да на проду код ради у другом режиму зато што је укључен погрешан флег. Према LaunchDarkly State of Feature Management 2023, до 40% неочекиваног понашања на проду повезано је са некоректним вредностима feature flags. Јединствени манифест флег-ова за сва окружења решава овај проблем.

Спречавање разилажења окружења у пројекту

Главни алат за спречавање — Infrastructure as Code (IaC). Сва окружења морају бити описана у коду: Dockerfile, docker-compose.yml, Terraform скрипте или Ansible playbook-ови. Ручне измене на серверу су забрањене — свака промена конфигурације пролази кроз репозиторијум и code review. Ово гарантује да сва окружења имају исту конфигурацију.

Други алат по важности — јединствени CI/CD пајплајн. Исти скрипт за изградњу, тестирање и деплој мора се користити за сва окружења. Разлика је само у циљним променљивама (URL, кључеви). Ако се пајплајн за стејџинг и продукцију разликује по корацима — разилажења су неизбежна.

Трећи алат — аутоматска синхронизација података. Редовно (једном дневно или по распореду) ажурирајте стејџинг анонимизираном копијом продукцијске базе података. Ово омогућава тестирање кода на реалним подацима, а не на синтетичким фикстурама. Алати: pg_dump/pg_restore за PostgreSQL, mysqldump за MySQL, специјализовани сервиси попут DataGrip.

Четврти — мониторинг разилажења. Подесите обавештења при откривању разлика између стејџинга и продукције. Једноставан скрипт који упоређује хешеве конфигурационих фајлова или верзије инсталираних пакета уштедеће сате отклањања грешака. Превенција је увек јефтинија од дијагностике: спречавање разилажења окружења захтева мање напора него тражење узрока грешке „на проду ради”.