Prod’a Çıkış Gecesi Yaşananlar: En Kusursuz Plan Neden Patlar?

Seri 2: Sahadan Hatalar – Bölüm 3

Saat gece yarısını geçmiş. Teams kanalında veya toplantı odasında gergin ama aynı zamanda işi bitirmiş olmanın getirdiği yorgun bir rahatlama var.

Tüm feature branch’ler birleştirilmiş, staging ortamında regression testleri başarıyla tamamlanmış, checklist’teki maddelerin yanına tek tek yeşil tikler atılmış. "Deployment Plan" adıyla açılan dökümanda adım adım kimin ne yapacağı yazıyor. Her şey kağıt üzerinde kusursuz.

Ve o beklenen onay verilir: "Prod'a alıyoruz."

İlk on dakika sessizlik hakimdir. Servisler ayağa kalkar, smoke testler koşulur, ilk sipariş başarılı geçer. Tam herkes bilgisayarını kapatıp derin bir nefes almaya hazırlanırken, birden monitoring ekranında kırmızı bir pik belirir. Müşteri hizmetlerinden ilk çağrı düşer, ardından log akışı çılgın gibi akmaya başlar.

Kusursuz plan, gerçek hayatın sert duvarına çarpmıştır.

Staging Ortamının Sahte Cenneti

Yazılım geliştirirken en çok aldandığımız yerlerden biri test ve staging ortamlarıdır. Ne kadar izole edersek edelim, ne kadar benzetmeye çalışırsak çalışalım; o ortamlar steril birer laboratuvardır.

Prod ise vahşi doğadır.

Laboratuvarda her şey öngörülebilir bir ritimde akar. Veritabanında kilitlenme (deadlock) yaratacak kadar eşzamanlı işlem yoktur. Network gecikmeleri ideal seviyededir. Dış entegrasyonlar stabil cevaplar döner. En önemlisi; staging ortamında sisteme bağlanan kullanıcılar sistemi bilen, makul davranan mühendislerdir.

Oysa prod ortamında milyonlarca gerçek insan vardır. Biri sayfayı peş peşe yirmi kez yeniler, diğeri aynı butona iki cihazdan aynı saniyede basar, bir diğeri ise üç yıldır güncellenmemiş eski bir tarayıcıdan garip karakterler içeren bir form doldurmaya çalışır.

Canlıya çıkış gecelerinde planı patlatan şey genelde mimari hatalar değil; laboratuvar koşullarında asla aklımıza gelmeyen bu kaotik gerçekliktir.

"Bunu Zaten Basit Bir Config ile Çözmüştük" Yanılgısı

Geriye dönüp baktığımda, gece yarısı deployment krizlerinin büyük bir kısmının büyük kod değişikliklerinden değil, "ufak tefek" görünen detaylardan çıktığını görüyorum:

• Environment değişkenlerinin prod ortamına eksik kopyalanması,
• Veritabanı migration script’inin canlıdaki devasa tablo üzerinde dakikalarca kilit yaratması,
• Bir cache temizleme (invalidation) adımının unutulması yüzünden eski ve yeni servislerin birbirini anlamaması,
• Dışarıdan çağrılan bir üçüncü parti servisin rate limit sınırının test ortamında hiç zorlanmamış olması.

İşin kötüsü, bu detaylar genelde checklist’lerde en sona bırakılan, "Nasılsa iki dakikalık iş" denilerek önemsenmeyen adımlardır. Sistemler en karmaşık algoritmaların olduğu yerden değil, en çok ihmal edilen o küçük ayarlardan kırılır.

Kriz Anında Refleks: Suçlu Aramak mı, Rollback Yapabilmek mi?

Bir canlıya çıkış gecesinde bir ekibin gerçek olgunluğu, problem çıktığı andaki tavrıyla ölçülür.

Acemi ekiplerde ilk refleks genelde suçlu aramaktır: "Bu PR'ı kim onayladı?", "Bu senaryo test edilmiş miydi?", "DB migration'ı kim çalıştırdı?" Bu sorular o gece kimseye fayda sağlamaz. Sadece gerilimi artırır, insanları panikletir ve sağlıklı karar alma yetisini felç eder.

Olgun bir ekip ise planını sadece "her şeyin yolunda gitmesi" üzerine kurmaz. İyi bir test ve mühendislik kültürünün en önemli göstergesi, geri alma (rollback) planının ne kadar net ve uygulanabilir olduğudur.

Eğer sistemde beklenmedik bir aksaklık çıktığında on dakika içinde eski kararlı sürüme dönebiliyorsanız, o gece kaybetmiş sayılmazsınız. Sadece yarın sabah masaya oturup üzerinde sakince konuşacağınız değerli bir tecrübe edinmiş olursunuz. Ama geri dönüş yolunu baştan planlamadıysanız, canlı ortamda hotfix peşinde koşarken sistemi daha da derin bir bataklığa sürüklersiniz.

Masadaki Gerçek

Canlıya çıkış geceleri hiçbir zaman tamamen risksiz olmayacak. Yazılım yaşayan, nefes alan ve sürekli değişen bir organizma. Ne kadar test yazarsanız yazın, bilinmeyenlerin tamamını sıfırlayamazsınız.

Fakat tecrübe insana şunu öğretiyor: Kusursuz plan, hiç hata çıkmayacağını varsayan plan değildir. Kusursuz plan; işler ters gittiğinde ekibin paniklemeden, birbirini suçlamadan, soğukkanlılıkla durumu kontrol altına alabilecek reflekslere sahip olmasıdır.

Prod gecelerinin huzuru, yeşil yanan monitoring ekranlarından değil; ekibin o kaosla yüzleşebilme cesaretinden ve hazırlığından gelir.

Serinin son bölümünde, ekiplerin en çok düştüğü bir diğer tuzağı ele alacağız: Test Otomasyonunu "Tool Fetişizmi"ne Kurban Etmek.