Tek kök neden efsanesi: olaylar neden tek bir nedenden çıkmaz?

Tek kök neden varsayımı, sistemleri hâlâ tek parça makineler gibi düşündüğümüz bir dönemin mirasıdır. Bir dişli kırılır, makine durur; dişliyi bulur, değiştirir, yola devam edersiniz. Bugünün hizmet ortamları böyle çalışmıyor. Sanallaştırılmış altyapılar, birbirine zincirlenmiş hizmetler, üçüncü taraf bileşenler ve her gün değişen konfigürasyonlar, teker teker zararsız görünen küçük kusurların bir araya gelmesine sahne oluyor.

Yaşanmış bir örüntüyü ele alalım: bir güvenlik yaması, belgelenmemiş bir bağımlılığı değiştirir. İzleme aracı bu bileşeni kapsam dışında bırakmıştır, çünkü sözleşme yenilenirken kapsam listesi güncellenmemiştir. Nöbetçi mühendis uyarıyı görmez, çünkü uyarı hiç üretilmemiştir. Kesinti raporuna hangi "tek" neden yazılmalı? Yama mı, izleme boşluğu mu, sözleşme maddesi mi?

Hizmet yönetimi en iyi uygulamaları bu gerçeği açıkça kabul eder: hatalar, hizmet yönetiminin dört boyutunun herhangi birinden gelebilir:

• Organizasyon ve insanlar
• Bilgi ve teknoloji
• Ortaklar ve tedarikçiler
• Değer akışları ve süreçler

Üçüncü taraf sözleşmesindeki bir eksik madde, bir bileşen arızası kadar olası bir kesinti nedenidir; yalnızca daha az görünürdür.

Bu yüzden yalnızca teknik yığında arama yapan bir araştırma, resmin en fazla çeyreğini görür. Önemsiz görünen belirtiler de aynı yanılgının parçasıdır: kritik olmayan bir sistemdeki küçük bir hata, yüksek erişilebilirlik için tasarlanmış bir ortamda zincirin ilk halkası olabilir.

Peki araştırma nasıl yapılmalı? İki kural belirleyicidir:

1. Bulunan ilk olası nedenle durmayın. "5 Neden" tekniği bir zincir değil, bir ağ olarak kullanılmalı; her "neden" sorusunun birden fazla cevabı olabileceği kabul edilmelidir. Hata ağacı analizi birleşen faktörleri görünür kılar; bileşen arızası etki analizi ise hangi kusurun hangi hizmeti nasıl etkileyeceğini önceden haritalar.
2. Araştırmanın çıktısı bir suçlu değil, bir "bilinen hata" kaydıdır. Nedenler anlaşıldığında kurum bilinçli bir karar verebilir: kalıcı düzeltme mi, hatayı izole eden kalıcı bir geçici çözüm mü, yoksa olay yönetimini o hata için optimize etmek mi? Her hatayı düzeltmek her zaman rasyonel değildir; ama her hatayı bilmek her zaman rasyoneldir.

Tek kök neden aramak, raporu erken kapatmanın en zarif yoludur; sistemi anlamanın değil. Olgun kurumlar problemleri tek bir iş listesinde yönetir, tekrar eden problem türleri için modeller kurar ve kapattıkları her kaydı kurumsal hafızanın parçası olarak saklar. Bir sonraki kesintiye verilecek en iyi cevap, bir önceki kesintiden öğrenilmiş olandır.