Sunucu çöktü, düzeltildi, herkes rahatladı. Üç ay sonra aynı arıza tekrar yaşandı ve kimse ilk seferinde ne yapıldığını hatırlamıyor. Aradaki eksik halka, yazılmamış bir kök neden analizidir.
Bu yazı, arıza sonrası analiz raporunu ele alıyor.
Amaç Ne Değildir?
Kök neden analizinin ne olmadığını netleştirmek gerekir:
- Suçlu bulma belgesi değildir.
- Formalite değildir.
- Sadece teknik bir metin değildir.
- Tek bir nedeni işaret etmek zorunda değildir.
Birinci madde belirleyicidir: suçlu arayan bir analiz kültüründe insanlar bilgi saklar ve rapor gerçeği yansıtmaz — o andan itibaren analiz süreci işe yaramaz hâle gelir.
Amaç, aynı arızanın tekrar yaşanmasını engellemektir. Bunun için ne olduğunun dürüstçe yazılması gerekir.
Dördüncü madde ise gerçekçidir. Ciddi arızaların çoğu tek bir nedenden değil, üst üste gelen birkaç eksiklikten doğar.
Raporda Ne Olmalı?
| Bölüm | İçerik |
|---|---|
| Özet | Ne oldu, ne kadar sürdü, kimi etkiledi |
| Zaman çizelgesi | Dakika dakika olaylar |
| Etki | Sayısal olarak |
| Kök neden | Teknik açıklama |
| Neden erken fark edilmedi | İzleme boşluğu |
| Neden bu kadar sürdü | Müdahale engelleri |
| Aksiyonlar | Sorumlu ve tarihle |
Beşinci ve altıncı satırlar çoğu raporda eksiktir ve en değerli olanlardır: arızanın nedenini bulmak kadar, neden geç fark edildiğini ve onarımın neden uzun sürdüğünü anlamak da gerekir.
Aynı arıza tekrar yaşanabilir. Ama beş dakikada fark edilip on dakikada çözülürse, etkisi tamamen farklı olur.
Yedinci satırdaki "sorumlu ve tarihle" ifadesi kritiktir. Sorumlusu ve tarihi olmayan bir aksiyon maddesi hiçbir zaman yapılmaz.
Zaman Çizelgesinin Gücü
En yararlı bölüm genellikle zaman çizelgesidir:
- Sorunun gerçekte ne zaman başladığı.
- İlk belirtinin ne zaman göründüğü.
- Ne zaman fark edildiği.
- Müdahalenin ne zaman başladığı.
- Nedenin ne zaman anlaşıldığı.
- Ne zaman çözüldüğü.
Bu altı nokta arasındaki boşluklar, iyileştirme fırsatlarını doğrudan gösterir: ikinci ile üçüncü nokta arasındaki süre izleme eksikliğini, dördüncü ile beşinci arasındaki süre ise teşhis araçlarının yetersizliğini ölçer.
Bu ölçüm subjektif değildir. Süreler yazıldığında hangi tarafın daha çok iyileştirme gerektirdiği kendiliğinden ortaya çıkar.
Birinci ile ikinci nokta arasındaki fark ise sessiz bozulmayı gösterir. Sorun genellikle görünmesinden çok önce başlamıştır.
Nedenin Derinine İnmek
İlk bulunan neden nadiren asıl nedendir:
| Seviye | Örnek |
|---|---|
| Belirti | Site yanıt vermedi |
| Yakın neden | Disk doldu |
| Bir alt seviye | Günlük dosyaları temizlenmiyordu |
| Kök neden | Temizleme görevi sessizce başarısız oluyordu |
| Sistemsel neden | Zamanlanmış görevler izlenmiyordu |
Son satır en değerli çıktıdır: "disk doldu" bulgusunda durursanız sadece diski büyütürsünüz; "zamanlanmış görevler izlenmiyor" bulgusuna inerseniz henüz yaşanmamış onlarca arızayı da önlersiniz.
Bu derinleşme, her cevaba tekrar "neden?" diye sorarak yapılır. Genellikle dört ya da beş soru sonrasında sistemsel nedene ulaşılır.
Fazla derine inmenin de sınırı vardır. "Bütçe yetersizdi" gibi kontrol edilemez bir noktaya varmak, aksiyon üretmez.
Aksiyon Maddeleri
Raporun tek kalıcı çıktısı aksiyonlardır:
- Somut olmalı. "Daha dikkatli olalım" aksiyon değildir.
- Sorumlusu olmalı. Bir kişi.
- Tarihi olmalı.
- Önceliklendirilmeli. Hepsi acil olamaz.
- Takip edilmeli.
Beşinci madde çoğu sürecin öldüğü yerdir: yazılan ama takip edilmeyen aksiyon maddeleri, bir sonraki aynı arızanın raporunda yeniden yazılır — ve kimse bunun tekrar olduğunu fark etmez.
Basit bir çözüm, açık aksiyon maddelerinin düzenli gözden geçirilmesidir. Kapanmayan maddeler görünür olmalıdır.
Dördüncü madde ise gerçekçilik getirir. On beş aksiyon maddesi çıkaran bir rapor, hiçbirini yaptırmaz.
Raporu Paylaşmak
Rapor kimlerle paylaşılmalıdır?
- Teknik ekibin tamamı. Öğrenme fırsatı.
- Yönetim. Yatırım kararları için.
- Etkilenen müşteriler. Uygun bir özet.
Üçüncü madde tartışmalıdır ama doğru yapıldığında güven artırır: arızayı ve alınan önlemleri dürüstçe anlatan bir müşteri bildirimi, sessiz kalmaktan çok daha iyi karşılanır.
Müşteriye giden metin teknik detaydan arındırılmalı ama gerçeği gizlememelidir. Ne olduğu, ne kadar sürdüğü ve tekrarını önlemek için ne yapıldığı yeterlidir.
Birinci madde ise kurumsal öğrenmeyi sağlar. Bir kişinin öğrendiği ders, paylaşılmazsa şirket öğrenmemiş olur.
Her Arıza İçin Gerekir mi?
| Durum | Rapor |
|---|---|
| Müşteriyi etkileyen kesinti | Mutlaka |
| Veri kaybı riski oluşan olay | Mutlaka |
| Tekrar eden küçük sorun | Evet, birleşik olarak |
| Kıl payı atlatılan olay | Evet, çok değerli |
| Tek seferlik önemsiz hata | Gerekmez |
Dördüncü satır çok az kuruluşun uyguladığı ama en verimli olan yaklaşımdır: kesintiye dönüşmeden yakalanan olaylar, aynı bilgiyi hiçbir maliyet ödemeden verir.
Yedeklemenin bozuk olduğunu bir kayıp yaşamadan fark etmek, tam olarak bu türden bir olaydır ve incelenmeyi hak eder.
Beşinci satır ise süreci boğmamak içindir. Her küçük hataya rapor yazmak, ciddi raporların da okunmamasına yol açar.
Bu tür analizlerde donanım kayıtlarına ve sağlayıcı olay geçmişine erişmek gerekir; dedicated server altyapısı üzerinde donanım uyarıları ve müdahale kayıtları destek tarafında saklanır.
Sonuç
Kök neden analizinin işe yaraması iki şeye bağlıdır. Birincisi kültürdür: suçlu arayan bir ortamda insanlar bilgi saklar ve rapor gerçeği yansıtmaz. İkincisi derinliktir — "disk doldu" bulgusunda durursanız sadece diski büyütürsünüz, "zamanlanmış görevler izlenmiyor" bulgusuna inerseniz henüz yaşanmamış onlarca arızayı önlersiniz. Aksiyon maddelerine mutlaka sorumlu ve tarih yazın; takip edilmeyen maddeler bir sonraki aynı arızanın raporunda yeniden yazılır.
Sıkça Sorulan Sorular (SSS)
Raporda hangi bölümler olmalı?
Özet, zaman çizelgesi, sayısal etki, kök neden, neden erken fark edilmediği, neden onarımın uzun sürdüğü ve sorumlu-tarihli aksiyonlar. Son iki soru çoğu raporda eksiktir ve en değerlileridir — aynı arıza tekrar olsa bile hızlı fark edilip çözülürse etkisi tamamen farklı olur.
Kök nedene nasıl inerim?
Her cevaba tekrar "neden?" diye sorarak. Genellikle dört ya da beş soru sonrasında sistemsel nedene ulaşılır. Ama sınırı vardır — "bütçe yetersizdi" gibi kontrol edilemez bir noktaya varmak aksiyon üretmez.
Müşteriyle paylaşmalı mıyım?
Etkilenen müşterilere uygun bir özet göndermek güveni artırır. Arızayı ve alınan önlemleri dürüstçe anlatan bir bildirim, sessiz kalmaktan çok daha iyi karşılanır. Metin teknik detaydan arındırılmalı ama gerçeği gizlememelidir.
Her arıza için rapor gerekir mi?
Hayır. Müşteriyi etkileyen kesintiler, veri kaybı riski oluşan olaylar ve tekrar eden sorunlar için gerekir. Kıl payı atlatılan olaylar da çok değerlidir çünkü aynı bilgiyi hiçbir maliyet ödemeden verir. Tek seferlik önemsiz hatalara rapor yazmak, ciddi raporların okunmamasına yol açar.
