Problem Yönetiminde Kök Neden Analizi: BT Ekipleri İçin Adım Adım Yöntem

Problem yönetimi olay yönetiminden nerede ayrılır?

Olay yönetiminin işi hizmeti en kısa sürede normale döndürmektir. Servis masası bir kesintiyi geçici bir müdahaleyle kapattığında olay biter, ama aynı kesintinin neden yaşandığı sorusu açık kalır. Problem yönetimi bu soruyu üstlenir: bir ya da birden çok olayın altında yatan nedeni bulur, kalıcı çözümü tasarlar ve bilinen hatayı herkesin görebileceği biçimde kayıt altına alır.

Pratikte bu süreçlerin zaman ufku farklıdır. Olay yöneticisi dakikalarla ve etki alanıyla uğraşır, problem yöneticisi ise kalıp ve eğilimle. Olayı kapatan kişi genellikle sorunu en iyi bilen kişidir; yine de kök neden çalışmasını ayrı bir kayıtta, ayrı bir sahiple yürütmek gerekir. Aksi halde servis masasının yoğunluğu analizi her seferinde erteler ve ekip aynı yangını yeniden söndürür.

ITIL 4 bu ayrımı bir uygulama (practice) olarak ele alır ve problem yönetimini olay ile değişiklik yönetimiyle birlikte düşünür. Kök neden bulunduktan sonra çözümün üretim ortamına alınması genellikle değişiklik yönetiminden geçer; çözümün hangi yapılandırma öğesini etkilediği ise CMDB kayıtlarından okunur.

Kök neden çalışması hangi tetikleyiciyle ve hangi kayıtla başlar?

Her olay için kök neden analizi yapılmaz; bu hem pahalıdır hem de ekibi yorar. Problem kaydı açmak için kullanılan yaygın tetikleyiciler şunlardır: • Aynı yapılandırma öğesinde ya da aynı hizmette tekrarlayan olaylar • Etkisi yüksek, tek seferlik ama yeniden olabilecek büyük bir kesinti • Servis masası verisinde yükselen bir eğilim, örneğin aynı kategoride artan çağrılar • Geçici çözümle kapatılan ama nedeni bilinmeyen olaylar

Analize başlamadan önce eldeki malzemeyi toplayın: ilgili olay kayıtları, her olayın zaman damgaları, etkilenen hizmet ve yapılandırma öğeleri, aynı pencerede yapılan değişiklikler, izleme sisteminin uyarıları ve günlük (log) dosyaları. Olayları kategoriye göre değil, ortak yapılandırma öğesine ve zamana göre gruplamak çoğu zaman gizli ilişkiyi ortaya çıkarır. Örneğin farklı kategorilerde açılmış birkaç çağrı, hepsi aynı veritabanı kümesine bağlı olduğu için aslında tek bir problemin belirtisi olabilir.

Problemi kayda geçirirken olay numaralarını, belirtiyi, etkiyi ve ilk hipotezi yazın. Problem kaydında sahibin kim olduğu net değilse çalışma sahipsiz kalır.

Hangi yöntemler kullanılır: 5 Neden, balık kılçığı, zaman çizelgesi

Yöntem seçimi sorunun yapısına bağlıdır. 5 Neden tekniği, tek bir zincirleme nedensellik içeren durumlarda hızlıdır: her yanıta "bu neden oldu?" diye sorarak yüzeyden derine inilir. Zayıf yanı, analizi yapan kişinin bilgisiyle sınırlı kalması ve tek bir zincire kilitlenmesidir. Balık kılçığı (Ishikawa) diyagramı ise olası nedenleri insan, süreç, teknoloji, ortam gibi başlıklar altında toplar ve ekibi tek bir açıklamaya sabitlenmekten korur.

BT'de en güçlü yöntemlerden biri olay zaman çizelgesidir. Belirtinin ilk görüldüğü andan geriye doğru şu soruları sırayla işlersiniz: bu pencerede ne değişti, hangi dağıtım yapıldı, hangi yapılandırma güncellendi, hangi sertifika ya da lisans süresi doldu, hangi bağımlı hizmet yavaşladı. Değişiklik korelasyonu da buna eşlik eder: değişiklik takvimi ile olay başlangıcı karşılaştırılır.

Karmaşık, birden çok katmanlı durumlarda hata ağacı ya da bağımlılık haritası kullanılır. Uygulama, veritabanı, ağ ve depolama arasında hangi bağımlılığın kırıldığı görsel olarak izlenir. Yapay zeka ile otomatik analiz konusunu ayrı bir yazıda ele aldık; burada insan merkezli klasik yöntemlere odaklanıyoruz.

Örnek akış: yavaşlayan bir iç uygulamanın kök nedeni nasıl bulunur?

Örneğin insan kaynakları portalı her ayın aynı günlerinde yavaşlıyor ve servis masası her seferinde uygulama sunucusunu yeniden başlatarak olayı kapatıyor. Bir problem kaydı açılır ve çalışma şu sırayla ilerler.

Önce olay kayıtları toplanır; yavaşlamaların hep belirli saatlerde başladığı görülür. Sonra aynı pencerede çalışan zamanlanmış işler incelenir ve veritabanında yoğun bir toplu raporun aynı saatte tetiklendiği anlaşılır. İlk hipotez budur: rapor, ortak veritabanı kaynaklarını tüketiyor ve portal sorguları bekliyor.

Hipotezi doğrulamak için izleme verisi o saatlerde bekleme süreleriyle karşılaştırılır. Test ortamında rapor çalıştırıldığında portalın da yavaşladığı yeniden üretilirse hipotez güçlenir. Rapor zamanı kaydırıldığında yavaşlama ortadan kalkıyorsa, bu geçici çözümdür; kalıcı çözüm raporun sorgusunu iyileştirmek ya da ayrı bir okuma kopyasından çalıştırmaktır. Kalıcı çözüm değişiklik talebiyle üretime alınır, ardından problem kaydı kapatılmadan önce belirli bir gözlem dönemi izlenir. Bu akışta dikkat edilecek nokta, sunucuyu yeniden başlatmanın çözüm değil, belirtiyi gizleyen bir müdahale olduğunu kayıtta açıkça yazmaktır.

Kök nedeni nasıl doğrularsınız, bilinen hata kaydı nasıl tutulur?

Bulunan neden, kanıtla desteklenmedikçe hipotezdir. Doğrulama için şu sorulara cevap arayın: Bu neden olsaydı gözlemlediğimiz belirtiyi tam olarak açıklar mıydı? Nedeni ortadan kaldırdığımızda belirti kayboluyor mu? Aynı koşulları yeniden üretebiliyor muyuz? Bu sorulardan biri olumsuzsa analiz bitmemiştir.

Kalıcı çözüm hemen uygulanamıyorsa, ITIL terminolojisindeki gibi bilinen hata (known error) kaydı açılır. Kayıtta belirti, bilinen neden, geçici çözümün adımları ve kalıcı çözümün durumu yer alır. Servis masası ilgili olay geldiğinde bu kaydı bilgi tabanından bulup geçici çözümü uygular; böylece her çağrıda sıfırdan teşhis yapılmaz. Bilinen hata kayıtlarının erişilebilir, güncel ve arama yapılabilir olması, sürecin gerçek faydasını belirler.

Kalıcı çözüm üretildiğinde değişiklik kaydı problem kaydına bağlanır, bilinen hata kapatılır ve bilgi tabanı güncellenir. Ardından aynı kategoride olay trendi izlenir; düşmüyorsa kök neden eksik tespit edilmiş olabilir.

Kök neden analizinde sık yapılan hatalar

Birincisi, nedeni insana yüklemektir. "Operatör yanlış komut girdi" bir kök neden değildir; asıl soru, sürecin ve araçların bu hataya nasıl izin verdiğidir. Onay adımı, otomatik doğrulama ya da eğitim eksikliği gibi sistemik boşluklar aranmalıdır.

İkincisi, ilk makul açıklamada durmaktır. Belirtiyi açıklayan ilk neden çoğu zaman gerçek kök değil, bir ara halkadır. Üçüncüsü, kanıt toplamadan toplantıda fikir birliği aramaktır; ekip sesi yüksek olanın hipotezine yönelebilir. Dördüncüsü, problem kaydını kapatıp bilinen hata ve bilgi tabanı çıktılarını üretmemektir; analiz yapılmış ama bilgi ekibe ulaşmamış olur.

Beşincisi, süreç sahiplerini dışarıda bırakmaktır. Uygulama, altyapı, ağ ve güvenlik ekiplerinden temsilci olmadan yapılan analiz tek katmanda kalır. Son olarak, çözümü değişiklik yönetimi dışında uygulamak yeni bir olaya yol açabilir; kalıcı çözüm de kontrollü şekilde üretime alınmalıdır.

Bu beceriyi Mindset programlarında nerede geliştirirsiniz?

Servis masası, olay ve değişiklik yönetimi ekiplerinde çalışanlar ile BT hizmet yönetimi sorumluları için, BT Hizmet Yönetimi (ITIL 4) Temelleri programı problem, değişim ve yapılandırma yönetimini birlikte ele alan bir modül içerir; olay yönetimi ve servis masası uygulamaları da ayrı bir modüldür. Böylece kök neden çalışmasının hangi kayıtlardan beslendiğini ve çözümün hangi sürece aktarıldığını bütün olarak görürsünüz.

ISO 20000 BT Hizmet Yönetimi programı ise olay, problem ve değişiklik yönetimini standart gereklilikleri bağlamında işler; denetime hazır bir hizmet yönetim sistemi kuran kurumlar için uygundur. Kurumsal ekipler, kendi olay kayıtlarından anonimleştirilmiş örnek seçerek bu içeriği atölyeye dönüştürebilir.