Reliability Friday 03: Incident Escalation Matrisi Nasıl Kurulur?

Kısa cevap: Güvenilirlik yalnızca araçlarla sağlanmaz. Sorumluluk verilen kişiye karar yetkisi verilmemişse, incident teknik sebeplerle değil onay beklerken uzar. Ve bu bekleme ölçülebilir bir maliyet: PagerDuty'nin 2026 raporuna göre kurumların %68'i teknoloji kesintilerinde saatte 300.000 doların üzerinde kayıp bildiriyor, %34'ü en az 500.000 dolar. Aynı araştırmada kesintinin ortalama dakika maliyeti 4.537 dolar ve bir incident'ın ortalama çözüm süresi 175 dakika.

Escalation matrisinizi aşağıdaki yedi satırla test edin: boş kalan her satır, gerçek bir kesinti anında kaybedilecek zamandır.

Don't Deploy on Friday. Verify on Friday.

Bu haftanın kontrolü

Bu hafta çalıştırılacak bir komut yok. Ekibinizin escalation matrisini açın ve şu yedi satırı doldurmayı deneyin:

Servis:                                  ?
Severity 1 tetiklenirse ilk aranan:      ?
Rollback kararını kim verir:             ?
Failover kararını kim verir:             ?
Müşteriye kim bilgi verir:               ?
On-call'un prod erişimi var mı (E/H):    ?
Son tatbikat / post-mortem tarihi:       ?

Cevabı "duruma göre değişir" olan satır, doldurulmamış satırdır. Kesinti anında o soruyu ilk kez soruyor olmak, cevabı aramakla geçen dakikalar demektir. Dakikası 4.537 dolar olan bir tabloda, rollback yetkisini aramakla geçen on beş dakikanın karşılığı yaklaşık 68.000 dolar; hiçbir mühendis bu sürede bir satır kod yazmıyor.

Severity tanımı yoksa matris de çalışmaz

Matrisin en sık atlanan kısmı, kimin arandığı değil neyin Severity 1 sayıldığı. Tanım yazılı değilse ilk beş dakika teknik değil müzakere olur: "bu Sev 1 mi, Sev 2 mi?" Tanım basit ve ölçülebilir olmalı; müşteri etkisi, etkilenen kullanıcı oranı ve gelir akışının durup durmadığı üzerinden yazılır, "önemli" gibi bir sıfat üzerinden değil.

Kontrol listesi

Matrisi doldurduktan sonra sekiz soruyla sınayın:

Incident anında ilk kim aksiyon alır?Karar yetkisi kimde?Rollback kararını kim verebilir?Failover kararını kim verebilir?Müşteri iletişimini kim yönetir?Escalation sırası net mi?On-call ekip gerekli erişimlere sahip mi?Post-mortem süreci var mı?

Özellikle yedincisi atlanır. On-call ekibi metrik, araç ve erişim verilmeden sorumlu tutmak yaygın bir hatadır; kişi çağrılır, sorunu görür, müdahale edemez.

Sekizincisi ise herkesin doğru bildiği ama azının yaptığı iş. Aynı araştırmada kurumların tamamı olay sonrası öğrenmenin gerekli olduğunu söylüyor, ancak yalnızca %48'i incident'ları yapılandırılmış bir öğrenmeye çeviriyor. Aradaki fark, her çeyrek aynı kesintiyi yeniden yaşayan ekiplerin tarifi.

Beklenen çıktı

Doldurulmuş bir Severity 1 satırı kabaca şuna benzer. Bu bir örnektir; roller sizin organizasyonunuza göre değişir:

Severity 1 incident
  Owner:            NOC / Operations
  Technical Lead:   Infrastructure Lead
  Business Owner:   Account / Service Owner
  Decision Rights:  Rollback ve failover yetkisi tanımlı
  Communication:    Customer Success + Service Desk
  Post-mortem:      48 saat içinde zorunlu

Önemli olan hangi unvanların yazdığı değil, her satırda bir isim olması. "Ekip" bir isim değildir.

Risk

Yetki ve sorumluluk net tanımlanmadığında üç şey olur:

Karar süreçleri yavaşlar. Rollback yapılabilecek dakikalar, rollback'i kimin onaylayacağını bulmakla geçer.Incident call'ları kalabalıklaşır. Kimin karar vereceği belli değilse herkes çağrılır; kalabalık köprü, karar hızını artırmaz düşürür.Aynı sorun tekrarlar. Post-mortem sahibi yoksa kök neden yazılmaz, yazılmayan kök neden giderilmez.

Bu üçü SLA taahhüdünüzü teknik bir sebep olmadan ihlal ettirebilir; sistem çalışır durumdayken kararsızlıkla kaybedilen süre de kesinti süresidir. 175 dakikalık ortalama çözüm süresinin ne kadarının teşhis, ne kadarının onay beklemek olduğunu ölçmeyen bir ekip, yanlış sorunu optimize eder.

Eclit notu

Devraldığımız operasyonlarda ilk hafta yaptığımız iş genellikle yeni bir izleme kurmak değil, bu yedi satırı doldurmak. Teknik iyileştirmenin karşılığı ancak kararın kimde olduğu yazılıysa görünür; aksi hâlde daha hızlı tespit edilen arıza, aynı süre onay bekler.

Ölçü tarafını Prometheus'u herkes kurdu yazısında ele almıştık; bu hafta aynı sorunun insan tarafındayız. Geçen hafta Kubernetes readiness probe'larını doğrulamıştık; o kontrol sistemin kendini doğru bildirmesiyle ilgiliydi. İkisi de aynı sorunun parçası: bir şeyin çalıştığını sanmakla çalıştığını bilmek arasındaki fark.

Süreç tasarımı ve önleyici bakım tarafı sistem güvenilirliği hizmetlerimizin kapsamındadır.

Every Friday. One Production Check.