Production web siteniz az önce çöktü. Bunu nasıl ele alırsınız?

Question

Accepted Answer

İlk öncelik **hizmeti geri getirmek, sonra nedeni bulmaktır** — azaltma, teşhisten önce gelir. Bir incident ilan eder, net roller atar ve baştan sona iletişim kurarak en hızlı güvenli kurtarmaya doğru ilerlerim.

## Önce stabilize et

- **Bir incident ilan et** ve tek bir kanal aç (war room / Slack thread) ki koordinasyon dağılmasın.
- **Roller ata**: kararları verecek bir **Incident Commander**, stakeholder'ları güncelleyecek bir **iletişim sahibi** ve araştırma yapacak **müdahale edenler**. Tech Lead olarak çoğu zaman IC rolünü ben üstlenirim ki mühendisler soruna odaklanabilsin.
- **En hızlı geri alınabilir düzeltmeye yönel.** Bir deploy outage ile ilişkiliyse, önce **rollback** yap, soruları sonra sor — kullanıcıları geri getirmek, haklı olmaktan daha önemlidir.

## Paralel olarak teşhis koy

- **Bariz sinyalleri** kontrol et: dashboard'lar, hata oranları, son deploy'lar, altyapı değişiklikleri, trafik patlamaları, süresi dolmuş sertifikalar.
- Bir hipotez kur, en ucuzunu önce test et ve **aynı anda beş şeyi değiştirmekten kaçın** — neyin işe yaradığını bilemezsin.

## Sürekli iletişim kur

Sessizlik panik doğurur. Haber olmasa bile düzenli bir tempoda güncelleme gönderirim:

```
[14:05] Araştırılıyor — checkout devre dışı, kullanıcıların ~%40'ı etkilendi. Sonraki güncelleme 14:20.
[14:20] Tespit edildi: hatalı deploy. Şimdi rollback yapılıyor. Tahmini süre 10 dk.
[14:35] Hizmet geri geldi. İzleniyor. Postmortem takip edecek.
```

## Kurtarmadan sonra

- Sadece "daha iyi görünüyor" değil, tam kurtarmayı doğrula.
- Birkaç gün içinde **blameless bir postmortem** yap: zaman çizelgesi, kök neden, tespit/düzeltmeyi yavaşlatan şey ve **sahipleriyle birlikte somut aksiyon maddeleri**.
- Çıktı, suçlanacak bir isim değil — sistemsel iyileştirmedir (daha iyi alert'ler, koruma bantları, rollback otomasyonu).

## Tuzaklar

- Kullanıcılar acı çekerken **azaltmadan önce hata ayıklamak**.
- **Tek bir karar vericinin olmaması**, böylece beş kişinin paralel olarak tahmin yürütmesi.
- Stakeholder'lara karşı **sessizliğe gömülmek**.
- **Bireyleri suçlamak** — bu, gelecekteki incident'ların bağlı olduğu dürüstlüğü öldürür.

## Neden önemli

Outage'lar kaçınılmazdır; onları nasıl yönettiğin ekip güvenini ve müşteri güvenini tanımlar. Sakin, role dayalı koordinasyon ile blameless takip, kötü bir günü daha güçlü bir sisteme dönüştürür — ve mühendislerine, başarısızlığın bir cadı avı değil, bir süreç olarak ele alındığını, dolayısıyla hızlı hareket etmenin güvenli olduğunu gösterir.