Kazanimlar:
- Bir olayın yaşam döngüsünü (tespit, triyaj, azaltma, çözüm, postmortem), MTTD/MTTR metriklerini ve 'önce azalt, sonra soruştur' ilkesini kavrayabilme
- Yapay zekayı olay anında hipotez daraltmak ve suçsuz (blameless) postmortem taslağı üretmek için kullanıp her kök nedeni veriyle doğrulayabilme
- Postmortem'i suçlamayan bir dille yazma ve olay verisini maskeleyerek paylaşma disiplinini uygulayabilme
Her sistem eninde sonunda bozulur. Fark, iyi ekiplerin bu kaçınılmaz olaya nasıl hazırlandığı ve nasıl öğrendiğidir. Incident (olay/vaka), hizmeti bozan veya bozma tehdidi taşıyan beklenmedik durumdur: bir servisin çökmesi, yanıt sürelerinin fırlaması, bir veri kaybı. Incident yönetimi, bu olayı olabildiğince hızlı tespit edip, azaltıp (mitigate), çözmek ve sonra ondan ders çıkarmaktır. DevOps ve SRE (Site Reliability Engineering — sistem güvenilirliği mühendisliği) profesyonelinin gecesini gündüzüne katan disiplin budur.
İki kritik metrik olayın kalitesini ölçer: MTTD (Mean Time To Detect — ortalama tespit süresi) ve MTTR (Mean Time To Recover — ortalama toparlanma süresi). Amaç ikisini de küçültmektir. YZ burada iki büyük değer katar: olay anında log ve metrikleri hızla özetleyip olası kök nedeni daraltmak, ve olay sonrası postmortem (olay sonrası inceleme raporu) taslağını hızla oluşturmak. Ama olayın gidişatına dair kararlar — hangi servisi kapatmak, geri almak (rollback), müşteriye ne demek — sizindir.
Bir olayın yaşam döngüsü
- Tespit (detect): Alarm çalar ya da müşteri şikâyeti gelir. Ne kadar erken, o kadar iyi.
- Triyaj (triage): Ne kadar ciddi? Etki alanı ne? Önem düzeyi (severity) atanır — genellikle SEV1 (en kritik, tüm sistem) ile SEV4 (küçük) arası.
- Müdahale ekibini topla. Kritik olaylarda bir incident commander (olay komutanı) koordinasyonu üstlenir.
- Azalt (mitigate): Önce kanamayı durdur — sıklıkla bir geri alma (rollback) veya bir bayrağı kapatma. Kök nedeni sonra bulursun.
- Çöz (resolve): Kalıcı düzeltmeyi uygula.
- Öğren (postmortem): Ne oldu, neden oldu, tekrarını nasıl önleriz?
İpucu: Olay anında en pahalı hatalardan biri, "önce tam kök nedeni bulayım" diye kanamayı durdurmayı geciktirmektir. Kural: önce azalt (servisi ayağa kaldır/geri al), sonra soruştur. Bir bilinen-iyi sürüme geri dönmek, çoğu zaman en hızlı azaltmadır.
Suçsuz postmortem kültürü
Sağlıklı ekiplerin belkemiği blameless postmortem (suçlamayan olay sonrası inceleme) kültürüdür: amaç "kim yaptı" değil, "hangi sistem ve süreç bu hataya izin verdi?" sorusudur. İnsanlar cezalandırılacağını bilirse hatayı gizler; gizlenen hata tekrarlanır. Postmortem bir suçlama tutanağı değil, bir öğrenme belgesidir.
İyi bir postmortem şunları içerir: özet, etki (kaç kullanıcı, ne kadar süre, ne kadar para), zaman çizelgesi (timeline), kök neden(ler), ne iyi gitti / ne kötü gitti, ve eyleme dönük maddeler (action items) — her biri bir sahibi ve tarihi olan somut önlemler.
Dikkat: YZ ile postmortem yazarken suçlayıcı dili (isim vererek "X kişisi hata yaptı") kesinlikle temizleyin. Ayrıca YZ'ye olay verisi verirken müşteri kimliklerini, iç IP'leri ve secret'ları maskeleyin — postmortem'ler genellikle geniş kitleyle paylaşılır.
Kök neden analizi: 5 Neden ve YZ
Klasik bir teknik "5 Neden" (5 Whys): bir soruna "neden?" diye üst üste sorarak yüzeysel belirtiden gerçek köke inersiniz. "Servis çöktü. Neden? Bellek doldu. Neden? Bir sızıntı vardı. Neden? Bir kütüphane güncellemesi... " YZ bu zinciri kurmakta ve olası dalları önermekte hızlıdır — ama her "neden"i verinizle doğrulamalısınız; YZ makul ama yanlış bir zincir de kurabilir.
Önem düzeyi (severity) tablosu
Seviye
Etki
Örnek
Müdahale
SEV1
Tüm sistem/kritik iş kaybı
Ödeme tamamen düştü
Anında, tüm ekip, komutan
SEV2
Büyük işlev bozuk
Girişler başarısız
Hızlı, nöbetçi + destek
SEV3
Kısmi/sınırlı etki
Bir rapor gecikiyor
Mesai içinde
SEV4
Küçük/kozmetik
Yazım hatası
Sıradan iş kuyruğu
Üç mini vaka
Vaka 1 — MTTR 45 dakikadan 8 dakikaya. Ödeme servisi çöktü. Nöbetçi mühendis, maskelenmiş logları ve son deploy bilgisini YZ'ye verip "son 20 dakikadaki en olası tetikleyici ne?" diye sordu. YZ, çöküşün son deploy'la aynı dakikada başladığını gösterdi. Mühendis hemen o sürümü geri aldı; servis 8 dakikada döndü. Kök neden (yeni sürümdeki bir bağlantı havuzu hatası) sonra rahatça araştırıldı.
Vaka 2 — postmortem taslağı 20 dakikada. Bir SEV2 sonrası ekip yorgundu ve rapor yazmaya mecali yoktu; genellikle rapor haftalarca ertelenirdi. Bu kez zaman çizelgesini ve olay notlarını YZ'ye verip suçsuz bir postmortem taslağı ürettiler. YZ, etki, timeline ve eyleme dönük maddeler için düzgün bir iskelet çıkardı; ekip 20 dakikada gerçeklerle doldurup yayınladı. Ders kaybolmadı.
Vaka 3 — yanlış kök neden yakalandı. Bir olayda YZ, "kök neden veritabanı aşırı yüklenmesi" dedi ve makul görünüyordu. Ama mühendis metrikleri doğruladı: veritabanı yükü olay anında normaldi. Gerçek neden bir dış DNS sorunuydu. YZ'nin ilk hipotezi akıcı ama yanlıştı; veriyle doğrulama, raporun yanlış bir sonuçla yayınlanmasını önledi.
Dört kopyalanabilir şablon
1) Olay anı hızlı triyaj:
Bir üretim olayı yaşıyoruz. Maskelenmiş belirtiler: [SEMPTOM].Son değişiklikler: [SON DEPLOY/DEĞİŞİKLİK]. Bana:(1) en olası 3 kök neden hipotezini olasılık sırasıyla,(2) her birini 1 dakikada doğrulayacak komut/metriği,(3) en hızlı GÜVENLİ azaltma adımını (ör. rollback) ver.Kesin konuşma; her hipotezi doğrulamam gerektiğini belirt.
2) Suçsuz postmortem taslağı:
Aşağıdaki olay notlarından suçlamayan (blameless) bir postmortemtaslağı yaz. Bölümler: Özet, Etki (kullanıcı/süre/maliyet),Zaman çizelgesi, Kök neden(ler), İyi gidenler, Kötü gidenler,Eyleme dönük maddeler (her biri sahip + tarih alanıyla).İsim verme, süreç ve sisteme odaklan. Notlar: [MASKELENMİŞ]
3) 5 Neden analizi:
Şu belirtiden başlayarak "5 Neden" zinciri kur: [BELİRTİ].Her adımda birden fazla olası dal varsa göster. Her "neden"inyanına, onu doğrulamam için bakacağım kanıtı (log/metrik) yaz.Sonunda hangi adımların henüz doğrulanmadığını işaretle.
4) Eyleme dönük madde üretme:
Bu kök nedene göre, aynı olayın tekrarını önleyecek eyleme dönükmaddeler öner. Her maddeyi: (a) önleme mi tespit mi azaltma mı,(b) tahmini eforu, (c) etkisi ile sınıflandır. En yükseketki/efor oranına göre sırala. Kök neden: [X]
Zayıf prompt / Güçlü prompt
Zayıf: "Servis çöktü, ne yapayım?"
Sonuç: bağlamsız; YZ genel geçer, olayınıza uymayan tavsiyeler sıralar, üstelik kesin bir kök neden uydurabilir.
Güçlü: "Üretim ödeme servisi 5 dakikadır 5xx veriyor. Son deploy 6 dakika önceydi. En olası 3 kök neden hipotezini olasılık sırasıyla ver, her birini doğrulayacak komutu söyle ve en hızlı güvenli azaltmayı öner. Kesin konuşma, doğrulamam gerektiğini belirt."
Fark: ikinci istem belirtiyi, zamanlamayı ve son değişikliği verir; hipotez + doğrulama + azaltma ister ve YZ'yi kesinlikten uzak tutar.
Sık yapılan hatalar
- Azaltmadan önce tam kök neden aramak. Kanamayı durdurmayı geciktirir, MTTR'yi büyütür.
- YZ'nin ilk hipotezini doğrulamadan yayınlamak. Akıcı ama yanlış kök nedenler rapora sızar.
- Suçlayıcı dil. İsim vererek yazılan postmortem, gizlemeyi ve tekrar hatayı besler.
- Eyleme dönük maddesiz rapor. Sahibi ve tarihi olmayan öneri hiç uygulanmaz.
- Olay verisini maskelemeden paylaşmak. Postmortem geniş kitleye gider; secret/kişisel veri sızar.
- Rollback yolunu önceden hazırlamamak. Geri alma pratik değilse azaltma yavaşlar.
Özetle
Incident yönetimi, kaçınılmaz olayları hızla tespit edip azaltmak, çözmek ve onlardan öğrenmektir; MTTD ve MTTR temel ölçütlerdir. Altın kural "önce azalt, sonra soruştur"dur ve bilinen-iyi sürüme geri dönmek çoğu zaman en hızlı azaltmadır. YZ, olay anında logları özetleyip hipotez daraltmakta ve olay sonrası suçsuz postmortem taslağı üretmekte çok değerlidir — ama her kök neden hipotezini veriyle doğrulamak, dili suçlamadan arındırmak ve olay verisini maskelemek sizin sorumluluğunuzdadır.
Uygulama görevi
Geçmiş (veya kurgusal) bir olayı ele alın. (1) "Olay anı hızlı triyaj" şablonuyla YZ'den hipotezler ve doğrulama adımları ürettirin; hangi hipotezin veriyle doğrulanabildiğini not edin. (2) "Suçsuz postmortem taslağı" şablonuyla bir rapor iskeleti çıkarıp gerçeklerle doldurun. (3) En az iki eyleme dönük madde tanımlayıp her birine bir sahip ve tarih atayın.
Kontrol listesi
- [ ] Olay anında önce azaltmayı (rollback/kapatma) düşündüm, kök nedeni sonraya bıraktım.
- [ ] YZ'nin her kök neden hipotezini log/metrikle doğruladım.
- [ ] Postmortem'i suçlamayan bir dille, süreç ve sisteme odaklı yazdım.
- [ ] Her eyleme dönük maddeye bir sahip ve bir tarih atadım.
- [ ] YZ'ye verdiğim olay verisinden secret ve kişisel bilgileri maskeledim.
- [ ] Önem düzeyini (severity) etkiye göre doğru atadım.