Production Incident: İlk 15 Dakika Kritik

Incident'ın ilk 15 dakikası, sonraki 3 saatini belirler. Bu cümle klişe gelebilir ama birçok incident'tan sonra net biliyorum: doğru karar verilen ilk 15 dakika, çözümü gerçekten 30 dakikada bitirir; yanlış karar verilen ilk 15 dakika incident'ı kolayca 6 saate çevirir.

Bu yazı bir "production incident playbook"u — iGaming platformunda yıllardır oluşturduğumuz, on-call'da başıma defalarca gelen senaryolardan yazılmış.

Dakika 1-3: "Ne oluyor?"

İlk sinyal genelde bir alarm: Grafana bir threshold'u geçti, Sentry'de yeni bir error pattern, ya da biri Slack'te "site yavaş" yazdı.

Bu aşamada yapılacak tek şey: neyin ne kadar kötü olduğunu anlamak. Aksiyon yok henüz.

• Kaç kullanıcı etkileniyor? (rate) → Kritik
• Hangi servisler etkileniyor? (scope) → Kritik
• Dakika bazında durum kötüleşiyor mu, stabil mi? (trend) → Kritik
• Veri kaybı var mı? (severity) → Kritik

Bu 4 soruya 3 dakikada cevap vermek lazım. Yoksa sonraki 12 dakika yanlış problemi çözersin.

Dakika 3-5: İletişimi aç

Slack'te incident kanalı aç (#inc-YYYYMMDD-HHmm gibi). Hemen. Bu kanalda sadece incident ekibi konuşur, tüm pingler buraya yönlendirilir, herkes buraya bakar.

Stakeholder'lara kısa bilgi ver:

"Oyun sunucusunda error oranı yükseldi, ~15% kullanıcı etkileniyor. İncelemekteyiz. 10 dakika içinde durum güncellemesi."

Detay verme. Spekülasyon yapma. Teşhis etmeye çalışma. Sadece durumu paylaş ve güncelleme sözü ver.

Dakika 5-10: Teşhis

Burada olabildiğince hızlı gözlem aracı kullan:

Grafana'da son 24 saat grafiği:

• Error rate — ne zaman başladı?
• Latency — yavaş mı oldu?
• Traffic — trafik değişti mi?
• Resource — CPU/RAM/disk?

Son deploy'lar:

"Son 1 saatte bir şey deploy edildi mi?"

Bu soru tek başına incident'ların %40'ını "oh, son deploy sorunluymuş" şeklinde çözer. Sentinel kontrol: "son deploy ne zaman?" + "alarm ne zaman başladı?" — eğer yakınsa, rollback önce konuş. Teşhis sonra.

Recent log'lar:

• Hata pattern'i nedir? (specific error vs generic 500)
• Belirli bir endpoint'te mi yoğunlaşıyor?
• Bir downstream servis çağrısı mı fail ediyor?

Dakika 10-15: Karar ver

Bu noktada iki yola ayrılır:

Yol A: Hızlı geri alma mümkün mü?

• Son deploy'un rollback'i tek komut mu? → Hemen yap.
• Feature flag kapatabilir mi? → Hemen kapat.
• Bir config değişikliği geri alınabilir mi? → Hemen al.

Rollback'in güzelliği: problemin kaynağını anında kaldırır, incident durur, sonra rahatça analiz yaparsın.

Önemli: rollback yapmaktan çekinme. "Ama yeni özellik gider" diye konuşma. Yeni özellik 4 saat sonra da gider — o arada 10.000 kullanıcı kötü deneyim yaşar.

Yol B: Rollback mümkün değil

Durumu stabilize et:

• Sorunlu servise gelen trafiği azalt (load balancer)
• Non-critical path'leri kapat (feature flag)
• Scale out (belki daha fazla pod işe yarar)
• Downstream'den gelen hatayı tolere et (circuit breaker aktif)

Amaç: incident'ın büyümesini durdurmak. Çözmek henüz değil.

Sonraki saatler: kök neden analizi

İlk 15 dakika bittiyse ve sistem stabil olduysa, asıl iş başlar:

• Timeline çıkart — ne oldu, ne zaman oldu, kim ne gördü
• Log derinliğine in — hangi kod path'i gerçekten bu davranışa neden oldu
• Fix yaz — proper bir düzeltme, hot-patch değil
• Deploy + test

Ama bu yol, ilk 15 dakika düzgün yürütülmezse çok daha uzun sürer.

Incident sırasında yapılacak 3 kötü şey

1. "Canım sıkıldı, bir şey yapayım" — panik hareketi. Rastgele pod restart, rastgele config değişikliği. Her rastgele hareket teşhisi zorlaştırır.

2. Spekülasyonu gerçekmiş gibi paylaşmak — "Sanırım DB bağlantı havuzu doldu" → Slack'e yazılır → yönetim panikler → sorunun gerçek sebebi Redis timeout'tu, şimdi iki problemi birden yönetmek zorundasın.

3. Tek başına çalışmak — her incident iki kişilik. Biri yönlendirir, diğeri teknik aksiyona girer. Tek başınaysan, hemen ikinci kişiyi bul.

Post-incident: blameless retro

Incident kapandıktan sonra 48 saat içinde blameless retrospective:

• Ne oldu?
• Nasıl fark ettik?
• Kim etkilendi, ne kadar?
• Nasıl çözdük?
• Nasıl önleyebiliriz?
• Hangi monitoring/alarm eksikti?

Son soru en önemlisi. Her incident kör noktaları açığa çıkarır; o kör noktaları kapatmak sonraki incident'ı önler.

Sonuç

Production incident'ı yönetmek bir beceri. Doğuştan gelmez, oluşur. İlk 5-10 incident'ında panik yaşarsın, 20. incident'tan sonra neredeyse otomatik akar. Bu yüzden on-call rotasyonunun bir değeri var — herkes bu pratik kası geliştirmeli.

İlk 15 dakika kuralı: acele etme, ama yavaşlama. Gözlemle, iletişim kur, karar ver, aksiyona geç. Geri kalanı çözülür.