Proda işləyir: bu nədir, niyə yaranır və nə təhlükə yaradır

“Proda işləyir” ifadəsi nə deməkdir

“Proda işləyir” — bu, proqramçı mühitində kodun produksiya serverində işlədiyi, lakin test mühitində və ya həmkarının lokal maşınında işləməkdən imtina etdiyi vəziyyəti bildirən sabit ifadədir. Zahirən bu “problem yoxdur” kimi səslənir, halbuki əslində problem var — sadəcə produksiya mühitində təkrarlanmır. Uyğunsuzluğun kökü mühitlər arasında konfiqurasiya, versiya və məlumat fərqlərindədir.

İfadə digər tanınmış bəhanənin — “Məndə lokal işləyir” ifadəsinin əksi olaraq yaranıb. Əgər proqramçı “lokal işləyir” deyirsə, səhv yalnız başqalarında var. Əgər “proda işləyir” — səhv yalnız stejinqdə və ya test mühitindədir, produksiya isə təmizdir. Taleyin ironiyası: hər iki halda problem realdır, sadəcə baxan şəxsdə özünü göstərmir. DevOps Research and Assessment (DORA) 2023 tədqiqatına görə, yerləşdirmə avtomatlaşdırması yüksək səviyyədə olan komandalar belə uyğunsuzluqlarla 3 dəfə az qarşılaşır.

Biznes baxımından “proda işləyir” vəziyyəti göründüyündən təhlükəlidir. Stejinqdə səhv varsa, lakin produksiyada yoxdursa, proqramçı onu görməməzlikdən gələ bilər — və sonrakı yerləşdirmədə səhv produksiyaya keçəcək. Müvəqqəti rahatlıq istifadəçilərin təzyiqi altında həll edilməli olan gələcək problemə çevrilir.

Proqramçılar niyə “proda işləyir” deyirlər

Bu ifadənin davamlılığının psixoloji səbəbi — müdafiə refleksi. Stejinqdə səhv görən, lakin produksiyada görməyən proqramçı şüuraltı olaraq problemi dəyərsizləşdirə bilər: “produksiyada hər şey qaydasındadırsa, bu təcili deyil”. Klassik idrak yanlışlığı — sağ qalanın səhvi, burada produksiyanın görünən uğuru potensial təhlükədən üstün gəlir.

İkinci səbəb — qeyri-müəyyən məsuliyyət. Produksiya işləyirsə, stejinq işləmirsə, günahkar mühit olur, kod yox. Proqramçı səhvə görə məsuliyyəti öz üzərindən götürərək onu DevOps mühəndisinə və ya administratora atır. Atlassian State of DevOps 2022 məlumatlarına görə, vahid yerləşdirmə mühiti olmayan komandalarda (Docker, Kubernetes) belə məsuliyyət yerdəyişmələri 60% daha tez-tez baş verir.

Üçüncü səbəb — sıfır dayanma müddəti ilə buraxılış qorxusu. Proqramçı stejinqdə səhvi düzəldib yeniləməni yerləşdirsə, bu təkrar kod nəzərdən keçirmə, test etmə və deploy tələb edəcək. “Proda işləyir” ifadəsi düzəlişi növbəti buraxılışa qədər təxirə salmağa imkan verir, cari yükü azaldır. Təxirə salınmış düzəliş — komandalarda texniki borcun yığılmasının əsas səbəblərindən biridir.

Tərtibat və produksiya mühitləri arasındakı fərq

Produksiya və stejinq heç vaxt tamamilə eyni olmur — bu, miqyas, yük və məlumat fərqlərinə görə texniki cəhətdən mümkün deyil. Ancaq əsas parametrlər uyğun olmalıdır: əməliyyat sistemi versiyası, kompilyator, interpretator, verilənlər bazası, veb-server və layihənin bütün asılılıqları. Ən azı bir parametr fərqlənirsə — kodun davranışı dəyişə bilər.

Mühitlər arasında əsas fərqlərə aşağıdakılar daxildir:

• Avadanlıq — prosessor, RAM miqdarı, disk növü (SSD vs HDD) vaxtlamaya və çoxaxınlılığa təsir edə bilər
• Şəbəkə mühiti — firewall, DNS, proxy, yük balanslaşdırıcıları yalnız produksiyada mövcuddur
• Verilənlər bazasındakı məlumatlar — stejinqdə adətən test məlumatları, real istifadəçi qeydləri isə gözlənilməz nümunələrə malikdir
• Asılılıqların versiyaları — kitabxananın hətta kiçik yeniləməsi kodun davranışını dəyişə bilər
• Mühit dəyişənləri — API açarları, tokenlər, funksiya bayraqları mühitlər arasında fərqlənə bilər

Konteynerləşdirmə bu problemlərin çoxunu həll edir. Produksiya üçün yığılmış Docker təsviri stejinqdə də istifadə edilməlidir. Yeganə fərq — mühit dəyişənləri və həcm montajlarıdır. Docker State of Application Development 2023 məlumatlarına görə, bütün mühitlər üçün vahid təsvir istifadə edən komandalar uyğunsuzluqların sayını 74% azaldır.

Produksiyada davranış uyğunsuzluğunun tipik səbəbləri

Birinci və ən çox yayılmış səbəb — asılılıqların müxtəlif versiyaları. Proqramçı paketi lokal olaraq --save bayrağı ilə quraşdırır, lakin package.json və ya lock-faylı yeniləməyi unudur. Produksiyaya yerləşdirmə zamanı başqa versiya quraşdırılır ki, bu da fərqli davranır. npm ekosistemi üçün lock-fayl problemi tam həll edir, digər paket menecerləri üçün — analoji mexanizmlər (Gemfile.lock, Podfile.lock, pubspec.lock).

İkinci səbəb — çatışmayan və ya artıq mühit dəyişənləri. Proqramçı lokal maşında .env faylından istifadə edir, lakin CI/CD pipeline və ya serverə müvafiq dəyişənləri əlavə etmir. Nəticə — kod API və ya verilənlər bazasına qoşulma xətası ilə çökür. GitLab DevSecOps Survey 2023 məlumatlarına görə, produksiyadakı hadisələrin 27% səhv mühit dəyişənləri ilə bağlıdır.

Üçüncü səbəb — verilənlər bazasının vəziyyəti. Stejinqdə VB produksiyada olmayan qeydlər ehtiva edə bilər və ya əksinə — miqrasiyalar çatışmır. Tipik ssenari: proqramçı cədvəldəki yeni sahə ilə işləyən kod yazır, lakin miqrasiya produksiyada hələ tətbiq olunmayıb. Geri uyğunluqla miqrasiya strategiyası — belə hallardan qaçmağın yeganə yoludur.

Dördüncü səbəb — regional və dil parametrləri. Tarixlərin formatlaşdırılması, kəsr ədəd ayırıcıları, mətn kodlaşdırması — bütün bunlar proqramçının lokal maşınında və serverdə fərqlənə bilər. Xüsusilə beynəlmiləlləşdirmə layihələri üçün aktualdır. Həll — tətbiq konfiqurasiyasında locale açıq şəkildə göstərmək və sistem parametrlərinə güvənməmək.

“Proda işləyir” problemini necə diaqnoz etmək olar

İlk addım — hər iki mühitin jurnallarını müqayisə etmək. Jurnal səviyyəsindəki fərq çox vaxt səbəbi gizlədir: produksiyada INFO, stejinqdə isə DEBUG aktiv ola bilər. Eyni jurnal səviyyəsini qurun və hər iki mühitin maşın müqayisəsinə imkan verən formatda yazdığına əmin olun. Mərkəzləşdirilmiş jurnal toplama sistemlərindən istifadə edin — Sentry, Datadog, ELK Stack.

İkinci addım — asılılıq versiyalarını yoxlamaq. Lock-faylları müqayisə edin, hər iki mühitdə quraşdırılmış paketlərin siyahısını çıxarın. Minor və ya patch versiyasındakı fərq — uyğunsuzluğun ən ehtimal olunan səbəbidir. npm ls, pip freeze, mvn dependency:tree kimi alətlər uyğunsuzluqları tez aşkarlamağa kömək edir.

Üçüncü addım — produksiya mühitini lokal olaraq bərpa etmək. Docker Compose və ya oxşar alətlərdən istifadə edərək produksiya infrastrukturunun dəqiq surətini qaldırın. Səhv lokal konteynerdə təkrarlanırsa — problem koddadır, mühitdə deyil. Təkrarlanmırsa — konfiqurasiyada fərq axtarın.

Dördüncü addım — funksiya bayraqlarını və A/B testlərini yoxlamaq. Ola bilər ki, produksiyada kod fərqli rejimdə işləyir, çünki səhv bayraq aktivdir. LaunchDarkly State of Feature Management 2023 məlumatlarına görə, produksiyada gözlənilməz davranışın 40%-ə qədəri səhv funksiya bayrağı dəyərləri ilə bağlıdır. Bütün mühitlər üçün vahid bayraq manifesti bu problemi həll edir.

Layihədə mühit uyğunsuzluğunun qarşısının alınması

Qarşısının alınmasının əsas aləti — Infrastructure as Code (IaC). Bütün mühitlər kodda təsvir edilməlidir: Dockerfile, docker-compose.yml, Terraform skriptləri və ya Ansible playbook-ları. Serverdə əl ilə dəyişikliklər qadağandır — hər bir konfiqurasiya dəyişikliyi depozitariy və kod nəzərdən keçirmədən keçir. Bu, bütün mühitlərin eyni konfiqurasiyaya malik olmasını təmin edir.

Əhəmiyyətinə görə ikinci alət — vahid CI/CD pipeline. Eyni qurma, sınama və yerləşdirmə skripti bütün mühitlər üçün istifadə edilməlidir. Fərq yalnız hədəf dəyişənlərindədir (URL, açarlar). Stejinq və produksiya üçün pipeline addımları fərqlənirsə — uyğunsuzluqlar qaçılmazdır.

Üçüncü alət — avtomatik məlumat sinxronizasiyası. Stejinqi müntəzəm olaraq (gündə bir dəfə və ya cədvəl üzrə) produksiya verilənlər bazasının anonimləşdirilmiş surəti ilə yeniləyin. Bu, kodu sintetik fixturlarda deyil, real məlumatlarda sınamağa imkan verir. Alətlər: PostgreSQL üçün pg_dump/pg_restore, MySQL üçün mysqldump, DataGrip kimi ixtisaslaşmış xidmətlər.

Dördüncü — uyğunsuzluqların monitorinqi. Stejinq və produksiya arasında fərqlər aşkarlandıqda bildirişlər qurun. Konfiqurasiya fayllarının heşlərini və ya quraşdırılmış paket versiyalarını müqayisə edən sadə skript saatlarla debug vaxtına qənaət edəcək. Profilaktika həmişə diaqnozdan ucuzdur: mühit uyğunsuzluğunun qarşısını almaq “proda işləyir” səhvinin səbəbini axtarmaqdan daha az səy tələb edir.