Root Cause Analysis | Enver Balci Blog

30 saniyelik özet

Root Cause Analysis, yani kök neden analizi, bir sorunun ortaya çıkmasını ve tekrar etmesini sağlayan koşulları kanıtlarla araştırır. Görünen belirtiyi, olayı başlatan tetikleyiciyi ve etkisini büyüten etkenleri ayırır. Amaç suçlu bulmak değil, hangi değişikliğin tekrar riskini azaltacağını belirlemektir. “Neden?” sorusunu art arda sormak yararlıdır; ancak her cevap doğrulanmalıdır. Karmaşık sorunlarda birden fazla neden ve bunların etkileşimi bulunabilir.

Neden önemli?

Bir sipariş yanlış müşteriye gönderildiğinde adresi düzeltmek acil sorunu çözebilir. Aynı durum tekrar ediyorsa bu müdahale yeterli değildir. Kullanıcı adresi yanlış seçmiş olabilir; ancak sistemin benzer kayıtları nasıl gösterdiği, hangi kontrolün yapıldığı ve verinin nereden geldiği de araştırılmalıdır.

Her olayı çalışan dikkatsizliğine bağlamak, yönetilebilir sistem koşullarını görünmez bırakır. Tersine, insan davranışını bütünüyle dışlamak da analizi eksiltir. Önemli olan davranışı bağlamıyla incelemektir: Kişi hangi bilgiye sahipti, hangi kısıt altında çalışıyordu ve hangi seçenekleri kullanabiliyordu?

Junior bir iş analisti için kök neden analizi, açıklama üretmek ile açıklamayı kanıtlamak arasındaki farkı öğretir. Yönetici için ise kaynak tahsisinin dayanağını güçlendirir. Eğitim, yeni ekran, ek kontrol veya sistem değişikliği farklı maliyetler taşır. Neden anlaşılmadan seçilen müdahale, etkili görünmesine rağmen tekrarları azaltmayabilir.

Endüstri mühendisliği açısından bu çalışma, çıktıda görülen sapmayı süreç koşullarıyla ilişkilendirmektir. Tek bir olaydan genel bir kural çıkarmadan, benzer işlemler ve karşıt örnekler incelenir. Sorun yaşanmayan koşullar, yaşananlar kadar açıklayıcı olabilir. Böylece iyileştirme önerisi alışkanlığa değil, araştırılmış bir ilişkiye dayanır.

Terim nedir?

Kök neden analizi, “neden oldu?” sorusuna sistematik cevap arayan yöntemler bütünüdür. Tek bir araca indirgenmez. Olay zaman çizelgesi, süreç incelemesi, görüşmeler ve işlem kayıtları birlikte kullanılabilir. Yöntem, problemin niteliğine ve erişilebilir kanıtlara göre seçilir.

Belirti, gözlenen olumsuz durumdur. Tetikleyici, olayın başlamasına yol açan gelişmedir. Katkıda bulunan etkenler ise olasılığı, etkiyi veya toparlanma süresini artırabilir. Bir sistemde kısa süreli bağlantı kaybı tetikleyici olabilirken, uygulamanın beklenmeyen çalışma düzenine uyum sağlayamaması etkiyi büyütebilir. Bu ayrım, yalnızca tetikleyiciyi önlemeye odaklanmayı engeller.

Beş Neden yöntemi, bir açıklamanın arkasındaki koşulları art arda sorgulamayı sağlar. Beş sayısı, her sorunda tam olarak o kadar soru sorulması gerektiği anlamına gelmez. Cevap “çalışan yanlış yaptı” ise araştırma bitmez; yanlış davranışı mümkün kılan bilgi, tasarım ve süreç koşulları incelenir. Her bağlantının kanıtı aranır.

Balık kılçığı diyagramı, olası nedenleri kategoriler altında düzenlemeye yardımcı olur. Ancak diyagrama yazılanlar doğrulanmış neden değil, araştırılacak açıklamalardır. Pareto analizi ise sorunları seçilen ölçüye göre sıralayarak öncelik değerlendirmesi sağlar. En sık görülen sorun, maliyet veya risk açısından her zaman en önemli sorun olmayabilir.

Birlikte değişen iki ölçü, tek başına neden ilişkisini göstermez. Ürünün kullanımı azaldığında destek talepleri de artmış olabilir; ikisini etkileyen başka bir değişiklik bulunabilir. Analist, zaman sırasını ve açıklanan mekanizmayı araştırmalı, alternatif nedenleri değerlendirmelidir. Güven düzeyi düşük bir açıklama, kesin sonuç gibi sunulmamalıdır.

Analizin çıktısı yalnızca neden listesi değildir. Geçici önlem, kalıcı değişiklik, sorumlu kişi ve etkiyi doğrulama yöntemi de belirlenir. Her sorunda tekrarı tamamen ortadan kaldırmak mümkün olmayabilir. Amaç; tekrar olasılığını, etkisini veya fark edilmesine kadar geçen süreyi anlamlı biçimde azaltmaktır.

Gerçek vaka: GitHub’ın 2018 kesinti analizi

GitHub’ın yayımladığı olay analizine göre, 21 Ekim 2018’deki bakım sırasında bağlantı kaybı yaşandı. Bağlantı 43 saniyede geri geldi; buna rağmen hizmetlerdeki bozulma 24 saat 11 dakika sürdü. Kısa tetikleyici, uzun etkinin tamamını açıklamıyordu.

Otomatik sistem, veritabanlarının yazma görevini başka bölgedeki sunuculara taşımıştı. GitHub, bu davranışın yapılandırmaya uygun olduğunu; ancak uygulamalarının oluşan yeni düzene ve bölgeler arası gecikmeye yeterince uyum sağlayamadığını açıkladı. Veri tutarsızlıkları da güvenli geri dönüşü zorlaştırmıştı.

Şirketin açıkladığı sonraki adımlar arasında bölgeler arası geçişi sınırlayan yapılandırma değişikliği ve başarısızlık senaryolarını önceden sınama çalışmaları bulunuyordu. Buradan çıkarılabilecek ders, tetikleyiciyle etkiyi büyüten koşulların birlikte araştırılması gerektiğidir. Vaka, otomasyonun tamamen yanlış çalıştığını değil, yapılandırılmış davranışla uygulamanın beklentileri arasındaki uyumsuzluğu gösteriyor. Kaynak şirketin olay sonrası analizidir; açıklanan önlemlerin uzun vadeli etkisini tek başına kanıtlamaz.

Kaynak: Jason Warner, “October 21 post-incident analysis”, GitHub Blog, 30 Ekim 2018.

Varsayımsal örnek: Deneme hesapları neden ilk değere ulaşamıyor?

İşletmelere abonelikle stok yönetimi yazılımı sunan bir şirkette, deneme hesaplarının ilk stok raporunu oluşturma oranının düştüğünü düşünelim. İlk açıklama “karşılama ekranı yeterince anlaşılır değil” olsun. Bu bir neden hipotezidir; henüz doğrulanmış sonuç değildir.

Analist önce ölçünün tanımını ve veri kaydının değişip değişmediğini kontrol eder. Kullanıcı davranışı aynı kalırken rapor oluşturma olayı eksik kaydediliyor olabilir. Ölçüm sorunu dışlandıktan sonra düşüşün hangi müşteri gruplarında ve hangi tarihten itibaren görüldüğü araştırılır.

Farkın belirli bir veri bağlantısını kullanan hesaplarda yoğunlaştığı varsayılsın. Analist, bu hesapların kurulum adımlarını, destek kayıtlarını ve sistem hata kayıtlarını birlikte inceler. Bağlantı kurulmuş görünmesine rağmen stok verisinin aktarılmadığı ve kullanıcının sonraki adımı anlayamadığı bir durum bulunabilir.

Bu bulgu, ekranın sorunsuz olduğu anlamına gelmez. Olası neden zinciri daha ayrıntılıdır: Veri aktarımı başarısız oluyor, sistem bunu kullanıcıya açıklamıyor, kullanıcı rapor üretmek için gereken verinin gelmesini bekliyor. Teknik hata ile bilgilendirme eksikliği birlikte etkili olabilir. Her bağlantı ilgili kayıt ve gözlemle sınanır.

Araştırmada veri erişim koşullarındaki değişikliğin bazı bağlantıları etkilediği doğrulanırsa geçici önlem olarak etkilenen hesaplara yönlendirme sağlanabilir. Kalıcı çalışmada bağlantı davranışı, hata bildirimi ve başarısız aktarımın takibi ele alınır. Yalnızca karşılama ekranını değiştirmek, veri aktarımındaki sorunu çözmez.

Uygulama sonrasında bağlantının başarıyla tamamlanması ve ilk rapora ulaşma davranışı izlenir. Benzer koşullardaki hesaplarla karşılaştırma yapılır; müşteri dağılımındaki değişiklikler hesaba katılır. Sonucun iyileşmesi açıklamayı destekleyebilir, ancak başka eşzamanlı değişiklikler de değerlendirilmelidir. Müdahalenin işe yaradığını göstermek, analizin son adımıdır.

Yaygın üç hata

İlk makul açıklamada durmak. Bir nedenin kulağa mantıklı gelmesi yeterli değildir. Olay kayıtları, zaman sırası ve benzer örnekler açıklamayı desteklemelidir. Karşıt kanıtları özellikle arayın. Açıklama yalnızca bazı durumları kapsıyorsa hangi koşullarda geçerli olduğunu belirtin.
Tek neden bulmak için araştırmayı zorlamak. İşleyiş, kullanıcı davranışı ve teknik koşullar birlikte sorun yaratabilir. Bütün olayları tek bir zincire sığdırmak, önemli etkenleri dışarıda bırakır. Farklı neden yollarını kaydedin; her birinin hangi sonucu açıkladığını ve hangi kanıta dayandığını gösterin.
Düzeltmeyi doğrulamadan dosyayı kapatmak. Yeni kontrolün uygulanması, tekrar riskinin azaldığını kanıtlamaz. Sonuç ölçüsü ve değerlendirme koşulları önceden belirlenmelidir. Sorunun tekrar etmemesi de gözlem süresi, işlem hacmi ve koşullar dikkate alınmadan kalıcı başarı sayılmamalıdır.

Mini uygulama: Neden ve kanıt kartı

Bir sorunu araştırırken önce problemi tarafsız bir cümleyle yazın. Ardından her olası neden için aşağıdaki kartı doldurun.

Gözlenen sorun: Ne oldu, kim etkilendi?
Kapsam ve zaman: Hangi işlemlerde, hangi dönemde görüldü?
Olası neden: Hangi koşul bunu açıklıyor olabilir?
Mekanizma: Bu koşul sonucu nasıl oluşturuyor?
Destekleyen kanıt: Hangi kayıt veya gözlem var?
Karşıt kanıt: Hangi örnek bu açıklamayla uyuşmuyor?
Belirsizlik: Hangi bağlantı henüz doğrulanmadı?
Geçici önlem: Etki şimdi nasıl sınırlandırılacak?
Kalıcı müdahale: Hangi koşul değiştirilecek?
Doğrulama: Etki hangi ölçü ve koşullarla değerlendirilecek?

Kartları ekipçe değerlendirirken kanıtla desteklenen bulguları araştırılacak varsayımlardan ayırın. Seçilen müdahalenin hangi neden yolunu etkilediğini açıkça yazın. Böylece analiz, geçmişi açıklayan bir rapor olmanın yanında uygulanacak değişikliğin gerekçesini de oluşturur.

İlgili terimler

Problem Statement, As-Is Process, Domain Knowledge, Requirements Elicitation, Business Rule, Gap Analysis, KPI ve Metrics, Hypothesis, A/B Testing, Change Request ve Impact Analysis, Non-Functional Requirement