Staff/Principal (L6+)
⚡ÖZET VE TEKNİK CEVAP
Bir arıza çıktığında net olmayan öncelik tanımları iki büyük felakete yol açar:
1
Yetersiz Bildirim: Şirket cirosunun %20'sini vuran bir ödeme hatası 6 saat boyunca sıradan bir Jira bileti gibi bekletilir, veya
2
Gereksiz Alarm: Canlı olmayan bir test ortamı hatası için gece saat 03:00'te CTO ve CEO ayağa kaldırılır. Kurumsal bir Öncelik Eskalasyon Matrisi (Severity Matrix) net ve ölçülebilir sınırlar çizer:
1
SEV0 (Felaket): Aktif kullanıcıların %50'den fazlası ana iş akışını (ödeme, giriş) tamamlayamaz (CTO, Yazılım Direktörü ve CEO anında uyanır; her 15 dakikada bir durum özeti geçilir).
2
SEV1 (Kritik): Ana iş akışı kullanıcıların %10'undan fazlasında geçici çözümsüz bozulmuştur (30 dakikalık iletişim ritmi; SLA sayacı başlar).
3
SEV2 (Önemli): İkincil bir özellik bozuktur ancak geçici çözüm vardır (Saatlik güncelleme). Kriz bildirimleri 3 Parçalı Yönetici Şablonunu izlemelidir: Etki (Ne kadar kullanıcı/ciro etkilendi), Aksiyon (Şu an teknik olarak ne yapılıyor), ve Sonraki Güncelleme Zamanı (Bir sonraki duyurunun kesin saati).
Mühendislik El Kitabı & Mekanizma
6 Boyutlu Mimari Analiz⚙️1. Temel Çalışma Mekanizması
MekanizmaÖncelik matrisi otomasyonu PagerDuty/Opsgenie yönlendirme kurallarıyla çalışır:
1
Öncelik Tanımlama: Mühendisler Slack üzerinden olayı başlatır (
/incident declare sev1).2
Otomatik Yönetici Bildirimi: Sistem Yazılım Direktörüne, Müşteri Hizmetleri Liderine ve Hukuk Müşavirine anında SMS/Push bildirimi atar.
3
30 Dakikalık İletişim Sayacı: Kriz odasındaki bir bot son duyurudan bu yana 25 dakika geçtiğinde İletişim Liderini uyarır.
4
Standart Yönetici Bülteni: Bildirimler daima Mevcut Durum, Müşteri Etkisi (%), Kök Neden Hipotezi, Çözüm Planı ve Sonraki Duyuru Saatini içerir.
🎯2. Doğru Kullanım Senaryosu
KapsamKurumsal SaaS SLA yönetimi, müşteri hizmetleri kriz köprüleri, regülasyon kriz bildirimleri ve yönetici kriz iletişimi.
⚠️3. Prodüksiyon Arıza Modları
Kritik Risk- ✓Yöneticilere iş etkisini (etkilenen müşteri sayısı veya dakikalık ciro kaybı) anlatmadan 'Kubernetes podları crashlooping yapıyor' gibi anlamsız teknik jargonda mesajlar atmak
- ✓yöneticilerin baskısından korkulduğu için SEV1 ilan etmekten kaçınmak
📡4. Teşhis ve Telemetri Sinyalleri
Metrikler- ✓Kesinti anında CEO'nun mühendisleri kişisel telefonlarından tek tek araması
- ✓müşteri destek ekibinin arızayı sistem alarmlarından değil Twitter'daki öfkeli müşteri şikayetlerinden öğrenmesi
🛡️5. Önleme ve Mimari Bariyerler
Bariyerler- ✓Mühendislik el kitabında ölçülebilir Öncelik Matrisini açıkça yayınlayın
- ✓PagerDuty ile yönetici bildirimlerini otomatikleştirin
- ✓her 30 dakikada bir düzenli yönetici bülteni yayınlama kuralını zorunlu kılın
⚖️6. Mimari Ödünleşimler (Trade-offs)
ÖdünleşimOtomatik yönetici eskalasyonu üst yönetimi senkronize tutar ve müşteri güvenini korur; ancak yöneticilerde alarm yorgunluğu yaratmamak için çok net ve katı kriterler gerektirir.
📋
GERÇEK DÜNYA TELEMETRİSİVaka İncelemesi (TinyCTO Saha Örneği)
Büyük bir ödeme arızasında destek ekibine 2.000 bilet yağarken, mühendisler kimseye haber vermeden 50 dakika boyunca kendi aralarında hata ayıklamaya çalıştı. CEO arızayı en büyük kurumsal müşterinin sözleşmeyi iptal etmekle tehdit etmesiyle öğrendi. Şirket eskalasyon sürecini baştan kurdu: Ödeme hata oranı 2 dakika boyunca %3'ü geçerse otomatik SEV1 kuralı konuldu. Artık sistem 60 saniye içinde Yazılım Direktörünü ve Destek Liderini ayağa kaldırıyor ve her 20 dakikada bir
#yonetici-duyurulari kanalına iş odaklı durum bülteni geçiyor.İnteraktif Konsept Alıştırmaları
2 AlıştırmaQ1
Etkili bir Yönetici Kriz Bülteninde bulunması zorunlu 3 temel unsur nedir?
1. Ticari ve Müşteri Etkisi (etkilenen kullanıcı veya ciro oranı), 2. Yürütülen Aksiyon (uygulanan çözüm ve geri alma adımları), ve 3. Sonraki Güncelleme Saati (bir sonraki duyurunun kesin saati).
Q2
Kurumsal yazılım mühendisliğinde bir SEV0 olayını tanımlayan temel kriter nedir?
Müşterilerin büyük çoğunluğunun ana iş akışlarını (ödeme, sipariş) hiçbir geçici çözüm olmadan tamamen kullanamadığı ve şirketin ticari varlığını tehdit eden felaket seviyesindeki kesintidir.
Yönetici Seviyesi Kriz Eskalasyonu: Öncelik Matrisi, Paydaş İletişim Ritmi ve SLA İhlal Saatleri — Sıkça Sorulan Sorular
Yönetici kriz güncellemelerinde neden derin teknik jargondan kaçınılmalıdır?
Çünkü yöneticilerin veritabanı kilitleri veya çekirdek detayları yerine ticari etkiyi (etkilenen müşteri oranı, ciro kaybı, yasal riskler) anlamaya ve buna göre karar almaya ihtiyacı vardır.
Büyük kriz yönetiminde SLA İhlal Saati (SLA Breach Clock) nedir?
Sözleşmeyle taahhüt edilen müşteri SLA süreleri (%99,9 erişilebilirlik = ayda maksimum 43 dakika kesinti) dolmadan ve şirkete finansal tazminat cezası çıkmadan önceki kalan süreyi sayan canlı sayaçtır.
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸Öncelik Matrisleri kriz eskalasyonu için net ve ölçülebilir eşik değerleri belirler.
- ▸SEV0/SEV1 kesintileri üst yönetimi ve müşteri hizmetleri liderlerini otomatik ayağa kaldırır.
- ▸3 Parçalı Şablonu kullanın: Ticari Etki -> Yürütülen Aksiyon -> Sonraki Duyuru Saati.
- ▸Yönetici paniğini önlemek için her 15-30 dakikada bir düzenli bülten yayınlayın.
Yaygın Yanılgılar
- ✗Yanılgı: Yöneticilere haber vermeden önce arızanın tamamen çözülmesini beklemeliyiz (Gerçek: Devam eden arızayı gizlemek güveni yıkar; net zaman damgalarıyla erken haber verin).
- ✗Yanılgı: Olayın önceliği özneldir ve en çok bağıranın isteğine göre değişir (Gerçek: Öncelik seviyeleri hata oranı ve ciro kaybı gibi somut metriklerle katı kurallara bağlanmalıdır).
Karar Kılavuzu & Önceliklendirme
Kritik kesintiler sırasında üst yönetimi sakin ve senkronize tutmak için 30 dakikalık iş odaklı bülten ritmine sahip otomatik bir Öncelik Eskalasyon Matrisi kurun.
Doğrulanmış Kaynaklar & Referanslar
- [OFFICIAL_DOCUMENTATION]Google Site Reliability Engineering: Managing Incidents & Emergency Escalation— O'Reilly Media / Google SRE Book