Geliştirmede prodüksiyon yanıyor — nedir, nedenleri ve eylem algoritması

“Prodüksiyon yanıyor” ne demek ve arıza türleri

“Prodüksiyon yanıyor” (her şey çöktü) ifadesi, prodüksiyon ortamının hatalı çalıştığı ve kullanıcıların etkilendiği bir durumu tanımlar. Arıza, uygulamanın tamamen kullanılamaması (boş ekran, 502 hatası), kısmen kullanılamaması (ödeme modülü çalışmıyor ancak diğer işlevler mevcut) veya performans düşüşü (aşırı yavaş yükleme) olarak ortaya çıkabilir. Olayın şiddeti, etkilenen kullanıcıların yüzdesi ve kesinti süresi ile belirlenir.

Atlassian Statuspage'e (2025) göre, 2024'te mobil uygulamalar için ortalama kesinti süresi olay başına 27 dakikaydı. En yaygın nedenler: dağıtım sonrası kod gerilemesi (%34), bulut sağlayıcı kesintisi (%22), veritabanı sorunları (%18), yapılandırma hataları (%15) ve DDoS saldırıları (%11). Ana sonuç: arızaların çoğu dış etkenlerden değil, ekibin kendi yaptığı değişikliklerden kaynaklanır.

Bir crash (istemci tarafında uygulama çökmesi) ile backend kesintisi (sunucu kullanılamaz) arasında ayrım yapmak önemlidir. Crash genellikle istemci kodunun hotfix'i ile düzeltilirken, backend kesintisi altyapı değişiklikleri veya hizmetin yeniden dağıtımını gerektirir. İzleme metrikleri: istemci için — crash'siz oran, sunucu için — 5xx hata oranı ve p95 gecikmesi. APM (Uygulama Performans İzleme) — Sentry, New Relic, Datadog — arıza türünü hızla belirlemeye yardımcı olur.

Olay şiddeti: P0, P1, P2 ve sınıflandırma kriterleri

Birleşik bir şiddet sınıflandırması, hızlı yanıtın temelidir. Bu olmadan ekip, harekete geçmek yerine “bunun ne kadar acil olduğunu” tartışarak zaman kaybeder. Klasik ölçek: P0 (kritik) — uygulama tamamen kullanılamaz veya kullanıcı verileri sızıyor, yanıt süresi — anında; P1 (yüksek) — kullanıcıların %50+'sı için kritik işlev çalışmıyor, yanıt süresi — 15 dakika; P2 (orta) — bazı kullanıcılar için kritik olmayan işlev kullanılamaz, yanıt süresi — 1 saat.

P0 anında yükseltme gerektirir: nöbetçi mühendis mevcut tüm işleri durdurur ve olaya odaklanır. Sorun 10 dakika içinde çözülmezse — teknik lider dahil olur. 30 dakika sonra — mühendislik yöneticisine yükseltme. P0 olayları için tüm süreçleri ihlal etmek kabul edilebilir: tam kod incelemesi olmadan hotfix yapmak, doğrudan prodüksiyona dağıtmak, dal koruma kurallarını görmezden gelmek. Acil durum geçersiz kılma ekip düzeyinde önceden kararlaştırılmalıdır.

Şiddet tablosu

Şiddeti düşük tahmin etmemek son derece önemlidir. P2 olarak sınıflandırılan P0 ve P1 olayları, gecikmiş yanıta ve artan kesinti süresine yol açar. Kural: şüpheniz varsa — P0 olarak ayarlayın. Fazla sınıflandırma eksik sınıflandırmadan daha iyidir: kurtarma için bir saat kaybetmektense fazladan bir toplantı yapmak daha iyidir.

İlk 10 dakika: arıza sırasında eylem algoritması

Sayaç başlar: bir uyarı veya kullanıcıdan mesaj geldiği andan itibaren. İlk 10 dakika en önemlisidir. Algoritma: 1) sorunu onaylayın — sorunun gerçek olduğundan emin olun (yanlış alarm değil); 2) kanamayı durdurun — etkiyi hemen azaltın (rollback, feature toggle, uç nokta engelleme); 3) iletişim — genel #incident kanalında durumu yazın: ne oldu, şiddet, ne yapılıyor. İlk 10 dakika kök neden analizine harcanmaz.

Kanamayı durdurmaya paralel olarak, bir mühendis teşhise başlarken diğeri iletişimi yönetir. İletişim kanalları: Slack #incident kanalı (ekipler için), durum sayfası (kullanıcılar için), e-posta/SMS yükseltme (yönetim için). Her 15 dakikada bir — bilgi içeren durum güncellemesi: ne biliniyor, ne yapılıyor, tahmini kurtarma süresi. Durum sayfası (StatusPage, Statuspal), harici kullanıcılar için çalışma süresini ve olay geçmişini görüntüler.

Kanama nasıl durdurulur: rollback, feature toggle ve hotfix

İlk ve en önemli kural: sorunu prodüksiyonda çözmeye çalışmayın. Yeni bir sürüm arızaya neden olduysa — önceki kararlı sürüme geri dönün. Arıza, bir feature toggle arkasındaki belirli bir özellikten kaynaklanıyorsa — sadece toggle'ı kapatın. Ne rollback ne de toggle mevcutsa — minimum diff ile hotfix uygulayın. Rollback en güvenli seçenektir çünkü zaten çalışan bir duruma geri döner.

Feature toggle (diğer adıyla feature flag), dağıtım olmadan kanamayı durdurmak için güçlü bir araçtır. Ödeme modülü toggle ile devre dışı bırakılmışsa — kullanıcılar hata ekranı almak yerine ödeme düğmesini görmez. Toggle, build gerektirmez, mağaza incelemesi gerektirmez ve saniyeler içinde etkili olur. Her kritik özellik, sunucu düzeyinde (uzak yapılandırma) devre dışı bırakma özelliğine sahip bir feature toggle arkasında olmalıdır. Feature flag — ilk savunma hattı.

Rollback mümkün değilse (örneğin, geri döndürülemez bir veritabanı geçişi nedeniyle) ve toggle yoksa — son çare: minimum değişiklikle hotfix. Hotfix, en son sürüm etiketinden oluşturulur, yalnızca arızayı gidermek için gerekli satırları içerir ve hızlı dağıtımdan geçer (“Hotfix — acil düzeltmeler” makalesine bakın). Altın kural: stabilizasyondan sonra, neden açık görünse bile her zaman kök neden analizi yapın.

Neden teşhisi: loglar, metrikler ve alarmlar

Kanamayı durdurduktan sonra (veya mühendis sayısı izin veriyorsa paralel olarak) teşhis başlar. İlk kaynak loglardır. Merkezi loglama (ELK, Grafana Loki, Datadog Logs), zaman damgası, kullanıcı kimliği veya istek kimliğine göre hataları bulmayı sağlar. Önemli: grep'in hızlı çalışması için loglar yapılandırılmış (JSON) olmalıdır. Yapılandırılmış loglama tüm hizmetler için zorunlu bir gerekliliktir.

İkinci kaynak metriklerdir. Grafana, Datadog, New Relic, hata artışının ne zaman, hangi uç noktalarda ve hangi durum kodlarıyla gerçekleştiğini gösterir. Dağıtım öncesi ve sonrası metriklerin karşılaştırılması, sorunu belirli bir hizmete veya uç noktaya lokalize etmeye yardımcı olur. RED metrikleri (Rate, Errors, Duration) — mikro hizmet izleme standardı.

Üçüncü kaynak dağıtık izlemedir (distributed tracing). Jaeger, Zipkin, Datadog APM, isteğin mikro hizmetler boyunca yolunu gösterir ve gecikmenin veya hatanın tam olarak nerede oluştuğunu belirler. İzleme, özellikle bir hizmetteki arızanın tüm bağımlı hizmetlerde hatalara neden olduğu basamaklı arızalarda kullanışlıdır. İzleme kimliği, istemciden tüm backend hizmetlerine iletilmelidir.

# kubectl ve loglarla hızlı teşhis örneği
# Hatalı pod'ları listele
kubectl get pods --field-selector=status.phase!=Running

# Çöken pod'un loglarını kontrol et
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Son 30 dakikanın hizmetindeki hataları ara
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Önemli: kanamayı durdurmadan önce nedeni teşhis etmeye çalışmayın. Kullanıcıların %50'si crash görüyorsa — önce rollback yapın, ardından araştırın. İstisna: bir rollback, doğrudan hotfix'ten daha uzun sürerse (örneğin, veri uyumsuzluğu nedeniyle). Bu durumda, hotfix'i hemen uygulayın ve stabilizasyondan sonra post-mortem yapın. Düzeltmeden önce teşhis, kesinti süresini artıran tehlikeli bir kalıptır.

Post-mortem: suçlu aramadan olayları analiz etme

Post-mortem (olay incelemesi olarak da adlandırılır), çözümden 24–72 saat sonra gerçekleştirilen yapılandırılmış bir olay analizidir. Amacı: arızanın neden meydana geldiğini, izleme ve testlerin neden prodüksiyondan önce yakalamadığını ve tekrarı önlemek için süreçlerde neyin değiştirilmesi gerektiğini anlamaktır. Suçsuz kültür temel bir ilkedir: post-mortem, belirli kişilerin hatalarını değil, süreçleri, araçları ve iletişimi tartışır.

Post-mortem belgesinin yapısı: zaman çizelgesi (zaman damgalarıyla olay sırası), etki (etkilenen kullanıcılar, süre, finansal kayıplar), kök neden (teknik ana neden), tespit (nasıl keşfedildiği, neden daha önce yakalanmadığı), yanıt (ne yapıldığı, daha hızlı ne yapılabilirdi), aksiyon maddeleri (sorumlular ve son tarihlerle belirli görevler). Aksiyon maddeleri S.M.A.R.T. olmalıdır: belirli, ölçülebilir, atanabilir, gerçekçi ve zaman sınırlı.

Prodüksiyon arızasından sonra tipik aksiyon maddeleri: sessiz kalan metrik için izleme ve uyarı eklemek; kaçırılan durum için test kapsamını genişletmek; benzer bir durum için adım adım algoritma içeren bir sayfayı runbook'a eklemek; yanlış kullanılan araç hakkında ekip eğitimi düzenlemek. Her aksiyon maddesi, olayın tekrarlanma olasılığını azaltan somut bir değişikliktir.