CMDB ve konfigürasyon yönetimi: kurulum adımları ve sık hatalar

Konfigürasyon yönetimi ve CMDB nedir?

Konfigürasyon yönetimi, BT hizmetlerini oluşturan bileşenleri ve aralarındaki ilişkileri tanımlı, güncel ve güvenilir tutma pratiğidir. Bu bileşenlere konfigürasyon öğesi denir: sunucu, uygulama, veritabanı, ağ cihazı, sözleşme ya da bir hizmetin kendisi olabilir.

CMDB (Configuration Management Database) bu öğelerin, özelliklerinin ve ilişkilerinin tutulduğu kayıt yapısıdır. Doğru kurulduğunda bir olayda hangi hizmetin etkilendiğini, bir değişikliğin nelere dokunacağını hızla görmenizi sağlar. Yanlış kurulduğunda ise kimsenin güvenmediği, güncel olmayan bir envanter listesine dönüşür.

Kurulumdan önce: amaç ve kapsam

En sık yapılan hata, her şeyi kaydetmeye çalışmaktır. CMDB'nin değeri kayıt sayısından değil, hangi karara yardım ettiğinden gelir. Önce şu soruyu yanıtlayın: bu veri hangi süreçte kullanılacak?

Örneğin olay yönetimi ekibi bir arızada etkilenen hizmetleri görmek istiyorsa, kritik hizmetler ve onları taşıyan altyapı bileşenleri öncelikli kapsamdır. Değişiklik yönetimi etki analizi istiyorsa bağımlılıklar kritiktir.

Küçük bir kapsamla başlayıp işe yaradığını gösterdikten sonra genişletmek, büyük bir kayıt projesini bitirememekten çok daha sağlıklıdır.

Kapsam kararını yazılı bir sayfaya dökmek de işe yarar: hangi öğe türleri kapsamda, hangi süreçler bu veriyi kullanacak, veriden kim sorumlu ve başarı nasıl anlaşılacak. Bu sayfa, proje genişlemek istediğinde ya da öncelik tartışması çıktığında dönülecek ortak bir referans olur.

Konfigürasyon öğesi ve ilişki modelini tasarlamak

Model tasarımı, hangi öğe türlerinin tutulacağını ve her türün hangi özelliklere sahip olacağını belirler. Çok ayrıntılı bir model bakımı imkânsız hale getirir; çok yüzeysel olan ise karar desteği vermez. Her özellik için sorun: bu bilgiyi kim güncelleyecek ve kim kullanacak?

İlişkiler CMDB'yi bir envanterden ayıran şeydir. Bir uygulamanın hangi sunucuda çalıştığı, hangi veritabanına bağlandığı, hangi hizmeti desteklediği gibi bağımlılıklar etki analizini mümkün kılar. İlişki türlerini baştan sade tutun ve tutarlı adlandırın.

Her öğenin bir sahibi olmalıdır. Sahipsiz kayıt zamanla bozulur.

Örneğin "müşteri portalı" hizmeti için öğe türleri hizmet, uygulama, sunucu, veritabanı ve yük dengeleyici olabilir. Özellikler sahip, ortam (üretim ya da test), kritiklik düzeyi ve destek ekibi gibi birkaç alanla sınırlı kalır. İlişkiler "üzerinde çalışır", "bağlanır" ve "destekler" gibi birkaç türle ifade edilir. Bu sadelik, modelin bakımını mümkün kılar.

Veriyi doldurma, keşif ve mutabakat

Veri iki yoldan gelir: otomatik keşif araçları ağdaki ve altyapıdaki bileşenleri tarar, elle girişte ise kayıtlar kişiler tarafından işlenir. Otomatik keşif hızlı ve güncel sonuç verir ama iş anlamını (bu sunucu hangi hizmete ait?) kendiliğinden bilmez. Bu bilgi genellikle insan girişi ya da kural tabanlı eşleme ile tamamlanır.

Farklı kaynaklardan gelen kayıtların aynı gerçek varlığa karşılık gelip gelmediği mutabakat adımında çözülür. Aynı sunucunun iki farklı adla iki kez kaydedilmesi sık görülen bir bozulma nedenidir; öğeleri tanımlayan benzersiz bir anahtar belirlemek bunu önler.

Başlangıç için pratik bir yöntem: kapsamdaki ilk öğe türünü seçin (örneğin üretimdeki sunucular), keşif sonucunu mevcut envanterle karşılaştırın, farkları sahiplerle tek tek çözün ve bu tür temizlenmeden sonrakine geçmeyin. Her türün temizlenmesi ayrı bir kazanım olarak kayda geçer ve ekibe güven verir.

Hizmet haritalama ve veri kalitesi

Hizmet haritalama, iş hizmetlerini onları destekleyen teknik bileşenlere bağlar. Böylece bir sunucu arızasının hangi iş hizmetini ve dolayısıyla hangi kullanıcı grubunu etkilediği görülebilir. Bu görünürlük, öncelik belirlerken en değerli çıktılardan biridir.

Veri kalitesi tek seferlik bir temizlik değil, sürekli bir ölçümdür. Doğruluk, eksiksizlik, güncellik ve tutarlılık gibi boyutlar için ölçütler tanımlanır; sapmalar düzenli raporlanır ve sahiplere iletilir. Ölçülmeyen kalite zamanla düşer.

Veri kalitesi ölçütlerine örnekler: sahibi boş olan öğeler, uzun süredir güncellenmemiş kayıtlar, keşifte görünüp CMDB'de bulunmayan cihazlar ve tersi, yani kayıtta olup ağda görünmeyenler. Bu listeler düzenli gözden geçirilir ve ilgili sahiplere iş olarak atanır; yalnızca rapor üretmek kaliteyi yükseltmez.

Süreçlerle entegrasyon ve sık hatalar

CMDB tek başına bir amaç değildir. Olay, değişiklik, problem ve varlık yönetimi gibi süreçlerle bağlandığında değer üretir. Örneğin bir değişiklik talebi açılırken etkilenen öğelerin CMDB'den seçilmesi, süreçle veri arasındaki bağı kurar ve kayıtların güncel kalmasını da teşvik eder.

• Her şeyi kapsamaya çalışmak ve hiçbir şeyi bitirememek.
• Sahip ve güncelleme sorumlusu atamamak.
• Veriyi bir kez yükleyip bırakmak.
• Süreçlerle bağlamadan yalnızca envanter tutmak.
• Kalite ölçmemek, sonuçta kullanıcının güvenini kaybetmek.
• Aracı seçmeyi tasarımın önüne koymak: önce model ve süreç, sonra araç.

Örnek bir kullanım senaryosu: bir veritabanı sunucusunda arıza çıktığında olay ekibi CMDB'den bu sunucuya bağlı uygulamaları ve onların desteklediği iş hizmetlerini görür, etkilenen kullanıcı grubuna göre öncelik belirler ve ilgili hizmet sahiplerini bilgilendirir. Aynı kayıtlar sonradan problem yönetiminde tekrar eden arızaların hangi bileşen ve değişiklikle ilişkili olduğunu aramak için de kullanılır.

Değişiklik yönetimiyle bağ özellikle önemlidir: her kayıtlı değişikliğin hangi öğeleri etkilediği CMDB üzerinden görülür ve değişiklik sonrası kaydın güncellendiği doğrulanır. Böylece CMDB, süreçlerin yan ürünü olarak güncel kalır, ayrı bir temizlik projesine ihtiyaç azalır.

Mindset programlarında nerede çalışırsınız?

Konfigürasyon Yönetimi ve CMDB Tasarımı eğitiminin modül başlıkları bu akışı izler: Konfigürasyon Yönetiminin Amacı ve Kapsamı, Konfigürasyon Öğesi Modelinin Tasarımı, İlişki Modeli ve Bağımlılık Tasarımı, Keşif, Veri Doldurma ve Mutabakat, Hizmet Haritalama ve İş Hizmetlerinin Modellenmesi, Veri Kalitesi Yönetimi ve Ölçüm, Süreçlerle Entegrasyon, İşletim Modeli ve Sürekli İyileştirme.