Bir IT arızası yaşandığında teknik ekiplerin ilk refleksi genellikle aynıdır: Loglar incelenir, son değişiklikler kontrol edilir, sunucular ve uygulamalar tek tek değerlendirilir. Amaç, sorunun yalnızca görünen belirtisini ortadan kaldırmak değil, kök neden analizi yaparak problemin asıl kaynağını bulmaktır.
Fakat bazı durumlarda sorun ne karmaşık bir yazılım hatasıdır ne de çözümü saatler sürecek kadar teknik bir problemdir. Asıl problem, ekibin arızayı analiz etmek için ihtiyaç duyduğu verinin güncel olmamasıdır.
Hangi sunucu gerçekten aktif? Uygulama hangi makinede çalışıyor? Bu cihazda hangi yazılım sürümleri kurulu? Network üzerinde sonradan eklenen bir cihaz var mı? CMDB'deki kayıtlar mevcut altyapıyla gerçekten örtüşüyor mu?
Bu soruların cevapları net değilse, kök neden analizi başlamadan önce ekiplerin bir de envanter araştırması yapması gerekir.
Kök Neden Analizi Neden Uzuyor?
Kök neden analizi (Root Cause Analysis – RCA), bir IT olayının yalnızca semptomunu gidermek yerine, problemin ortaya çıkmasına neden olan temel faktörü belirlemeyi amaçlar. IT operasyonlarında bu süreç; incident kayıtları, değişiklikler, konfigürasyonlar, sunucular, uygulamalar ve diğer IT varlıkları arasındaki ilişkilerin birlikte değerlendirilmesini gerektirebilir.
Örneğin bir uygulamanın aniden yavaşladığını düşünelim. İlk bakışta problem uygulamanın kendisinde görünebilir. Ancak araştırma ilerledikçe farklı ihtimaller ortaya çıkabilir:
- Sunucu kaynakları yetersiz olabilir.
- Veritabanı bağlantısında problem yaşanıyor olabilir.
- Network üzerinde gecikme oluşmuş olabilir.
- Yeni bir yazılım veya patch uyumsuzluk yaratmış olabilir.
- Sanallaştırma katmanında kaynak problemi meydana gelmiş olabilir.
Bu ihtimalleri doğru şekilde değerlendirebilmek için teknik ekibin öncelikle hangi varlıkların ortamda bulunduğunu ve bu varlıkların birbirleriyle nasıl ilişkili olduğunu bilmesi gerekir.
Yani iyi bir kök neden analizi yalnızca loglara bakmakla başlamaz. Güvenilir ve güncel altyapı verisine dayanır.
Yanlış Envanter, Yanlış Teşhis Demektir
IT ortamları sürekli değişir. Yeni sunucular eklenir, cihazlar değiştirilir, sanal makineler oluşturulur, yazılımlar güncellenir ve bazı sistemler kullanım dışı kalır. Ancak envanter kayıtları bu değişikliklerin gerisinde kaldığında iki farklı gerçeklik ortaya çıkar: Kayıtlardaki IT ortamı ve gerçek IT ortamı.
Örneğin CMDB'de bir uygulamanın eski bir sunucuda çalıştığı görülürken gerçekte yeni bir sunucuya taşınmış olabilir. Bir güvenlik yazılımı kayıt üzerinde kurulu görünürken ilgili cihazdan kaldırılmış olabilir. Ya da ağa yeni eklenen bir cihaz hiçbir envanter kaydında bulunmayabilir.
Arıza sırasında ekip bu verileri referans aldığında analiz yanlış bir başlangıç noktası üzerinden ilerler.
Arızayı çözmek için neyi yönettiğinizi bilmiyorsanız, önce arızayı değil envanterinizi araştırmaya başlarsınız. Bu nedenle IT envanter yönetimi yalnızca cihazların listesini tutmakla ilgili değildir. Aynı zamanda incident, problem ve değişiklik yönetimi gibi operasyonların doğru veriyle ilerlemesini sağlayan temel katmanlardan biridir.
Kök Neden Analizi ile Envanter Verisi Arasındaki Bağlantı
Bir arızanın kaynağını araştırırken teknik ekiplerin ihtiyaç duyduğu en önemli bilgilerden biri, olayın gerçekleştiği IT varlığının güncel durumudur.
Sunucu gerçekten çalışıyor mu? Üzerinde hangi işletim sistemi ve yazılım sürümü var? Hangi uygulamalar bu sunucuya bağlı? Network üzerindeki konumu ne? Son dönemde üzerinde bir değişiklik yapıldı mı?
Bu bilgiler eksik veya yanlışsa, kök neden analizi sırasında farklı sistemlerin tek tek kontrol edilmesi gerekir. Böylece MTTR, yani ortalama çözüm süresi, teknik problemin kendisinden bağımsız olarak uzayabilir. Üstelik problem yalnızca zaman kaybı değildir. Yanlış bir Configuration Item'a (CI) odaklanmak, olayın gerçek kaynağının gözden kaçmasına da neden olabilir.
Envanter Kirliliği Troubleshooting Süresini Uzatır
Güncel olmayan, mükerrer veya eksik varlık kayıtları teknik ekiplerin troubleshooting sürecinde gereksiz doğrulama adımları gerçekleştirmesine neden olabilir.
Örneğin sistemde 1.000 sunucu kayıtlı görünürken bunların bir bölümü artık kullanılmıyorsa ekip hangi kayıtların güvenilir olduğunu ayrıca doğrulamak zorunda kalır. Bunun tam tersi de mümkündür: Gerçekte kullanılan ancak CMDB'de bulunmayan bir sunucu, analiz sürecinin tamamen dışında kalabilir.
Sonuçta ekipler problemi çözmek yerine önce şu sorunun cevabını aramaya başlar: “Bu sistem gerçekten nerede ve şu anda aktif mi?” Bu da doğrudan arıza çözüm süresine yansır.
Kök Neden Analizi İçin CMDB Verisi Neden Güncel Olmalı?
CMDB'nin temel amacı yalnızca IT varlıklarını listelemek değildir. Konfigürasyon öğeleri ve bunların ilişkileri hakkında güvenilir bir görünüm sağlamaktır. Bu görünürlük; incident yönetimi, değişiklik yönetimi, etki analizi ve kök neden analizi gibi süreçlerde kullanılabilir.
Ancak CMDB'de çok fazla veri bulunması, bu verinin otomatik olarak doğru olduğu anlamına gelmez.
Örneğin 5.000 CI kaydınız olabilir. Fakat gerçek ortamınızda 5.500 varlık bulunuyorsa 500 varlık görünmez durumdadır. Tersi durumda ise artık kullanılmayan sistemlerin hâlâ aktif görünmesi analizleri yanıltabilir.
Bu nedenle önemli olan yalnızca “kaç varlığımız var?” sorusu değil; “CMDB'deki bilgilerimiz gerçek IT ortamımızı ne kadar doğru yansıtıyor?” sorusudur. Bu konuya daha detaylı olarak CMDB Veri Doğruluğu: Sunucularınız Kayıtlarınızla Aynı mı? içeriğimizde değiniyoruz.
Arızayı Çözmeden Önce Ortamınızı Keşfedin
IT ekiplerinin cevaplaması gereken temel soru aslında oldukça basit: “Şu anda ağımda gerçekten ne var?”
Bu sorunun cevabı manuel Excel listelerine, farklı ekiplerin tuttuğu dosyalara veya uzun süre önce oluşturulmuş envanter kayıtlarına dayanıyorsa kök neden analizi sırasında güvenilir bir başlangıç noktası oluşturmak zorlaşır. Modern IT ortamlarında IT Asset Discovery, ağ üzerindeki fiziksel, sanal ve network varlıklarının otomatik olarak keşfedilmesine yardımcı olur.
Özellikle agentless discovery, uç noktalara ayrı bir agent yüklemeden varlıkların keşfedilmesini sağlayarak envanter görünürlüğünü artırabilir. SPIDYA Ajansız Envanter Keşfi çözümü; Windows sistemlerde WMI ve WinRM, Linux sistemlerde SSH, network cihazlarında SNMP ve VMware altyapılarında vSphere API gibi yöntemlerle farklı IT varlıklarının keşfedilmesini destekler.
Buradaki amaç yalnızca daha uzun bir cihaz listesi oluşturmak değildir. Amaç, IT ekiplerinin kararlarını gerçek ortama daha yakın ve güncel veriler üzerinden verebilmesidir.
Kök Neden Analizi Sürecini Güçlendirmek İçin 4 Kontrol
IT ekipleri mevcut envanterlerinin kök neden analizi süreçlerini destekleyip desteklemediğini anlamak için yalnızca “envanterimiz var mı?” sorusunu sormamalı. Asıl soru, bu envanterin arıza anında gerçekten işe yarayıp yaramadığı olmalı.
Bunu anlamak için şu dört kontrolü yapabilirsiniz:
Yeni eklenen veya kaldırılan varlıklar ne kadar hızlı sisteme yansıyor? Envanter kayıtları düzenli olarak doğrulanıyor mu? Örneğin bir sunucu birkaç ay önce devre dışı bırakılmış ancak hâlâ CMDB'de aktif görünüyorsa, bir incident sırasında ekip bu sunucuyu hâlâ sistemin parçası olarak değerlendirebilir. Bunun tam tersi de mümkün: Yeni devreye alınan bir sunucu envantere işlenmediyse, üzerinde çalışan bir uygulamada yaşanan problem analiz sırasında tamamen gözden kaçabilir. Gerçek ortam ile envanter arasındaki zaman farkı büyüdükçe, arıza sırasında yanlış bilgiyle hareket etme riski de artar.
Kayıtlı CI'lar ile keşfedilen varlıklar arasında ne kadar fark var? Eski, mükerrer veya artık kullanılmayan kayıtları tespit edebiliyor musunuz? Örneğin CMDB'nizde belirli bir uygulamanın “Server-A” üzerinde çalıştığı kayıtlı olabilir. Ancak uygulama aylar önce “Server-B”ye taşınmışsa ve bu değişiklik CMDB'ye yansımamışsa, ekip bir arıza sırasında yanlış sunucuyu incelemeye başlayabilir. Bu noktada problem yalnızca CMDB'nin güncel olmaması değildir. Aynı zamanda CMDB'ye duyulan güvenin azalmasıdır. Bir IT ekibi kritik bir olay sırasında “Bu bilgi gerçekten doğru mu?” diye tekrar tekrar kontrol etmek zorunda kalıyorsa, kök neden analizi için harcanması gereken zaman envanter doğrulamaya gider.
Bir sunucu, uygulama veya network cihazının hangi servisleri etkilediğini anlayabiliyor musunuz? Bir arızanın başka hangi sistemleri etkileyebileceğini görebiliyor musunuz? Örneğin bir veritabanı sunucusunda performans problemi yaşandığında yalnızca o sunucuyu incelemek yeterli olmayabilir. Bu sunucuya bağlı uygulamaların, servislerin veya network bileşenlerinin de değerlendirilmesi gerekebilir. Eğer varlıklar arasındaki ilişkiler görünür değilse ekipler bu bağlantıları manuel olarak araştırmak zorunda kalabilir. Bu da özellikle büyük ve karmaşık IT ortamlarında kök neden analizi sürecini uzatabilir. Çünkü sorun tek bir cihazda ortaya çıkmış olsa bile, kök neden o cihazın bağlı olduğu başka bir sistemde olabilir.
Envanter doğruluğunu düzenli olarak ölçebiliyor musunuz? Gerçek ortamda bulunan ancak CMDB'de yer almayan varlıkları belirleyebiliyor musunuz? Örneğin network üzerinde gerçekten 2.500 cihaz bulunurken CMDB'de 2.200 cihaz kayıtlıysa, 300 varlık operasyonel görünürlüğün dışında kalıyor olabilir. Ya da aynı cihaz farklı isimlerle birden fazla kez kayıtlıysa ekipler gerçek varlık sayısını ve durumunu doğru şekilde değerlendiremeyebilir. Bu durum yalnızca envanter raporlarını etkilemez. Arıza yönetimi, güvenlik kontrolleri, lisans takibi ve kök neden analizi gibi süreçlerde de yanlış kararların önünü açabilir.
Peki Bu Kontrollerin Sonucu Ne Söylüyor?
Bu dört sorudan herhangi birine net bir cevap veremiyorsanız, problem yalnızca “envanterimizin güncel olup olmaması” değildir.
Örneğin bir arıza sırasında;
- Ekibiniz önce hangi sunucunun gerçekten aktif olduğunu araştırıyorsa,
- CMDB'deki bilgileri sahadaki veya network üzerindeki gerçek durumla tekrar tekrar karşılaştırıyorsa,
- Bir cihazın hangi uygulama ve servislerle ilişkili olduğunu manuel olarak bulmaya çalışıyorsa,
- Sistemde görünmeyen varlıkların olup olmadığını kontrol etmek için farklı araçlara başvuruyorsa,
kök neden analizi için harcanması gereken zaman, problemin kendisini çözmek yerine ortamı anlamaya harcanıyor demektir. Bu nedenle güçlü bir IT operasyonunun yalnızca olayları kayıt altına alması yeterli değildir. Yönettiği IT ortamını doğru, güncel ve mümkün olduğunca otomatik şekilde tanıması gerekir.
Çünkü arıza anında ihtiyacınız olan ilk bilgi “ne bozuldu?” değil, bazen çok daha temel bir sorunun cevabıdır: “Gerçekte burada ne var?”
Sonuç: Kök Nedeni Bulmak İçin Önce Gerçeği Görün
Kök neden analizi sırasında kaybedilen zamanın her zaman sebebi karmaşık teknik problemler değildir. Bazen ekiplerin ihtiyaç duyduğu bilgi vardır; ancak güncel değildir. Bazen doğru kayıt vardır; ancak gerçek ortamda artık karşılığı yoktur. Bazen de sistemde hiç görünmeyen bir varlık problemin merkezindedir.
Bu nedenle hızlı ve güvenilir bir troubleshooting sürecinin temelinde yalnızca güçlü ITSM süreçleri değil, güncel ve doğru bir IT varlık envanteri de bulunur. Çünkü arızanın kök nedenini bulmadan önce şu sorunun cevabını bilmeniz gerekir: “Gerçekte neyi yönetiyoruz?”
