“Prodda çalışıyor”: nedir, neden olur ve neden tehlikelidir

“Prodda çalışıyor” ifadesi ne anlama gelir

“Prodda çalışıyor” — geliştiriciler arasında yerleşmiş bir ifadedir ve kodun production sunucusunda çalıştığı ancak test ortamında veya bir meslektaşın yerel makinesinde çalışmayı reddettiği durumu belirtir. Dışarıdan “sorun yok” gibi duyulur, oysa aslında sorun vardır — sadece production ortamında tekrarlanmaz. Farklılığın kökeni, ortamlar arasındaki yapılandırma, sürüm ve veri farklılığında yatar.

Bu ifade, başka bir ünlü bahanenin — “Benim lokalimde çalışıyor” — antitezi olarak doğmuştur. Geliştirici “lokalimde çalışıyor” derse, hata yalnızca başkalarında vardır. “Prodda çalışıyor” derse — hata yalnızca staging veya test ortamında vardır, ancak production temizdir. Kaderin cilvesi: her iki durumda da sorun gerçektir, sadece bakan kişide görünmez. DevOps Research and Assessment (DORA) 2023 araştırmasına göre, yüksek düzeyde dağıtım otomasyonuna sahip ekipler bu tür farklılıklarla 3 kat daha az karşılaşır.

İş açısından bakıldığında, “prodda çalışıyor” durumu göründüğünden daha tehlikelidir. Staging’de hata varsa ancak prodda yoksa, geliştirici bunu görmezden gelebilir — ve bir sonraki dağıtımda hata productiona geçer. Geçici rahatlama, kullanıcıların baskısı altında düzeltilmesi gereken gelecekteki bir soruna dönüşür.

Geliştiriciler neden “prodda çalışıyor” der

İfadenin kalıcılığının psikolojik nedeni — savunma refleksi. Staging’de hata gören ancak prodda görmeyen bir geliştirici, bilinçsizce sorunu küçümseyebilir: “productionda her şey iyiyse, bu acil değildir”. Klasik bir bilişsel önyargı — hayatta kalan yanılgısı, production’ın görünür başarısının gelecekteki bir arızanın potansiyel tehdidinden daha ağır bastığı durum.

İkinci neden — belirsiz sorumluluk. Production çalışıyor ancak staging çalışmıyorsa, suçlu kod değil ortamdır. Geliştirici, hatanın sorumluluğunu üzerinden atarak DevOps mühendisine veya yöneticiye yükler. Atlassian State of DevOps 2022’ye göre, birleşik dağıtım ortamı (Docker, Kubernetes) olmayan ekiplerde bu tür sorumluluk aktarmaları %60 daha sık gerçekleşir.

Üçüncü neden — sıfır kesintili sürüm korkusu. Geliştirici staging’deki hatayı düzeltir ve düzeltmeyi dağıtırsa, bu yeniden code review, test ve dağıtım gerektirir. “Prodda çalışıyor” ifadesi, düzeltmeyi bir sonraki sürüme ertelemeye izin vererek mevcut yükü azaltır. Ertelenmiş düzeltme — ekiplerde teknik borç birikiminin ana nedenlerinden biridir.

Geliştirme ve production ortamları arasındaki fark

Production ve staging asla tamamen aynı olamaz — bu, ölçek, yük ve veri farklılıkları nedeniyle teknik olarak imkansızdır. Ancak temel parametreler eşleşmelidir: işletim sistemi sürümü, derleyici, yorumlayıcı, veritabanı, web sunucusu ve projenin tüm bağımlılıkları. En az bir parametre farklıysa — kodun davranışı değişebilir.

Ortamlar arasındaki temel farklılıklar şunları içerir:

• Donanım — işlemci, RAM miktarı, disk türü (SSD vs HDD) zamanlamaları ve çoklu iş parçacığı çalışmasını etkileyebilir
• Ağ ortamı — firewall, DNS, proxy, yük dengeleyiciler yalnızca prodda bulunur
• Veritabanındaki veriler — staging’de genellikle test verileri bulunurken, gerçek kullanıcı kayıtları beklenmedik desenlere sahiptir
• Bağımlılık sürümleri — bir kütüphanenin küçük bir güncellemesi bile kodun davranışını değiştirebilir
• Ortam değişkenleri — API anahtarları, tokenlar, özellik bayrakları ortamlar arasında farklılık gösterebilir

Konteynerizasyon bu sorunların çoğunu çözer. Production için oluşturulan Docker imajı staging’de de kullanılmalıdır. Tek fark — ortam değişkenleri ve volume bağlamaları. Docker State of Application Development 2023’e göre, tüm ortamlar için birleşik imaj kullanan ekipler, farklılıkların sayısını %74 oranında azaltır.

Prodda davranış uyuşmazlığının tipik nedenleri

İlk ve en yaygın neden — farklı bağımlılık sürümleri. Geliştirici, paketi yerel olarak --save bayrağıyla kurar ancak package.json veya lock dosyasını güncellemeyi unutur. Prod’a dağıtımda farklı bir sürüm kurulur ve farklı davranır. npm ekosistemi için lock dosyası sorunu tamamen çözer, diğer paket yöneticileri için — benzer mekanizmalar (Gemfile.lock, Podfile.lock, pubspec.lock).

İkinci neden — eksik veya fazla ortam değişkenleri. Geliştirici yerel makinede .env dosyası kullanır ancak CI/CD pipeline’ına veya sunucuya ilgili değişkenleri eklemez. Sonuç — kod, API veya veritabanına bağlantı hatasıyla başarısız olur. GitLab DevSecOps Survey 2023’e göre, prod’daki olayların %27’si yanlış ortam değişkenleriyle ilişkilidir.

Üçüncü neden — veritabanının durumu. Staging’deki veritabanı, prod’da olmayan kayıtlar içerebilir veya tersi — migration eksik olabilir. Tipik senaryo: geliştirici, tablodaki yeni bir alanla çalışan kod yazar ancak migration henüz prod’a uygulanmamıştır. Geriye dönük uyumlu migration stratejisi — bu tür durumlardan kaçınmanın tek yoludur.

Dördüncü neden — bölgesel ve dil ayarları. Tarih biçimlendirme, ondalık ayırıcılar, metin kodlaması — bunların hepsi geliştiricinin yerel makinesi ve sunucuda farklılık gösterebilir. Uluslararasılaştırma içeren projeler için özellikle önemlidir. Çözüm — uygulama yapılandırmasında locale’i açıkça belirtmek ve sistem ayarlarına güvenmemek.

“Prodda çalışıyor” sorunu nasıl teşhis edilir

İlk adım — her iki ortamın günlüklerini karşılaştırmak. Günlük düzeyindeki fark genellikle nedeni gizler: prod’da INFO açıkken staging’de DEBUG olabilir. Aynı günlük düzeyini ayarlayın ve her iki ortamın makine karşılaştırmasına izin veren bir biçimde yazdığından emin olun. Merkezi günlük toplama sistemleri kullanın — Sentry, Datadog, ELK Stack.

İkinci adım — bağımlılık sürümlerini kontrol etmek. Lock dosyalarını karşılaştırın, her iki ortamda yüklü paketlerin listesini görüntüleyin. Küçük veya yama sürüm farkı — farklılığın en olası nedenidir. npm ls, pip freeze, mvn dependency:tree gibi araçlar tutarsızlıkları hızlıca belirlemeye yardımcı olur.

Üçüncü adım — production ortamını yerel olarak yeniden oluşturmak. Docker Compose veya benzer araçları kullanarak production altyapısının tam bir kopyasını oluşturun. Hata yerel kapsayıcıda tekrarlanırsa — sorun kodda, ortamda değil. Tekrarlanmazsa — yapılandırmadaki farkı arayın.

Dördüncü adım — özellik bayraklarını ve A/B testlerini kontrol etmek. Prod’da kod, yanlış bayrak etkin olduğu için farklı bir modda çalışıyor olabilir. LaunchDarkly State of Feature Management 2023’e göre, prod’daki beklenmeyen davranışların %40’ına kadar yanlış özellik bayrağı değerleriyle ilişkilidir. Tüm ortamlar için birleşik bayrak manifestosu bu sorunu çözer.

Projede ortam farklılıklarının önlenmesi

Önlemenin ana aracı — Infrastructure as Code (IaC). Tüm ortamlar kodla tanımlanmalıdır: Dockerfile, docker-compose.yml, Terraform betikleri veya Ansible playbook’ları. Sunucuda manuel değişiklikler yasaktır — yapılandırmadaki herhangi bir değişiklik depo ve code review’dan geçer. Bu, tüm ortamların aynı yapılandırmaya sahip olmasını sağlar.

İkinci en önemli araç — birleşik CI/CD pipeline’ı. Aynı derleme, test ve dağıtım betiği tüm ortamlar için kullanılmalıdır. Fark — yalnızca hedef değişkenlerde (URL, anahtarlar). Staging ve production için pipeline adımları farklıysa — farklılıklar kaçınılmazdır.

Üçüncü araç — otomatik veri senkronizasyonu. Düzenli olarak (günde bir kez veya programa göre) staging’i, production veritabanının anonimleştirilmiş bir kopyasıyla güncelleyin. Bu, sentetik fixture’lar yerine gerçek veriler üzerinde kod test etmeye olanak tanır. Araçlar: PostgreSQL için pg_dump/pg_restore, MySQL için mysqldump, DataGrip gibi özel hizmetler.

Dördüncü — farklılıkların izlenmesi. Staging ve production arasında farklılıklar tespit edildiğinde uyarılar ayarlayın. Yapılandırma dosyalarının hash’lerini veya yüklü paketlerin sürümlerini karşılaştıran basit bir betik, saatlerce hata ayıklamayı önler. Önleme her zaman teşhisten daha ucuzdur: ortam farklılığını önlemek, “prodda çalışıyor” hatasının nedenini aramaktan daha az çaba gerektirir.