Konfigürasyon Yönetimi Prosedürü Nasıl Takip Edilir?
Konfigürasyon yönetimi prosedürü nasıl takip edilir? Asset discovery, izleme ve AIOps ile kapalı döngü mimarisi nasıl kurgulanır? Prosedür dokümanda yazıyor, ama ağda, sunucuda ve bulutta gerçekten uygulanıyor mu? Bu yazıda her prosedür adımını hangi katmanın izlediğini, bu katmanların nasıl bağlandığını ve sürecin sağlığını hangi KPI'larla ölçeceğinizi ele alıyoruz.
Konfigürasyon yönetimi prosedürü, tek bir araçla değil dört katmanın döngüsüyle takip edilir: Asset Discovery "ne var?" sorusunu ve CMDB'yi, NCM baseline, drift ve rollback'i, İzleme değişikliğin canlı etkisini, AIOps ise korelasyonu, riski ve otomatik aksiyonu yönetir. Hepsi ITSM'deki değişiklik kaydına API ile bağlanır; süreç, envanter doğruluğu, drift oranı, yetkisiz değişiklik oranı ve MTTR gibi KPI'larla ölçülür.
Neden Konfigürasyon Yönetimi Prosedürü Tek Başına Yetmez?
Çoğu kurumda konfigürasyon yönetimi prosedürü vardır: değişiklik talebi açılır, CAB onaylar, planlı pencerede uygulanır. Sorun, prosedürün kâğıtta kalmasıdır. Üç tipik kopukluk görülür:
-
Envanter Eskir
CMDB'ye elle girilen kayıtlar haftalar içinde gerçeklikten ayrılır. Mükerrer, hayalet ve kayıtsız varlıklar etki analizini ve kök neden analizini yanıltır.
-
Kayıt Dışı
Değişiklik GörünmezAcil müdahalede CLI'dan yapılan bir değişiklik RFC'ye hiç dönüşmeyebilir. Baseline ile çalışan konfigürasyon sessizce ayrışır (configuration drift). -
Değişiklik/Olay
Bağı KurulmazKesinti yaşandığında "son 2 saatte ne değişti?" sorusu birden fazla araçta, elle aranır. Ortalama çözüm süresinin büyük kısmı tanıya harcanır.
Prosedürü takip edilebilir kılmak, her adıma otomatik bir kanıt kaynağı bağlamak demektir. Bu kaynakların her biri farklı bir araç sınıfında yaşar.
Prosedürün Yedi Adımı Ve Sahipleri
Klasik süreç (ITIL, ISO/IEC 20000, ISO 27001 A.8.9) şu adımlardan oluşur. Tablo, her adımın hangi katman tarafından otomatik olarak takip edildiğini gösterir.
| Prosedür Adımı | Asset Discovery | NCM | İzleme | AIOps |
|---|---|---|---|---|
| CI Tanımlama | Cihazı bulur, sınıflandırır, CMDB'ye yazar | Konfigürasyon dosyasını CI'a bağlar | – | – |
| Baseline | Donanım/yazılım sürüm baseline'ı | Onaylı konfigürasyonu kaydeder | Performans baseline'ı çıkarır | Normal davranışı öğrenir |
| Değişiklik Kontrolü | Bağımlılık ve etki alanını gösterir | Değişikliği uygular, öncesini yedekler | Etkiyi canlı doğrular | Riski skorlar, olayla ilişkilendirir |
| Durum Kaydı | CMDB'yi günceller | Versiyon geçmişini tutar | Olayları loglar | Değişiklik–olay ilişkisini kurar |
| Denetim | Kayıtsız cihazı yakalar | Drift ve uyumsuzluğu bulur | Sapmayı alarmlar | Anomaliyi öne çıkarır |
| Yedekleme | – | Periyodik ve olay tabanlı yedek | Yedek işi başarısını izler | – |
| Kurtarma | – | Rollback uygular | İyileşmeyi doğrular | Otomatik iyileştirmeyi tetikler |
Referans Mimari
Aşağıdaki diyagram, dört katmanın ITSM ve CMDB ile nasıl bağlandığını gösterir. Ok yönleri veri ve komut akışını belirtir.
Mimarideki üç tasarım kararı kritiktir:
-
Tek Kaynak
CMDB tek doğruluk kaynağıdır, ancak elle beslenmez. Yazma yetkisi öncelikle keşif ve uzlaştırma sürecindedir.
-
Yetkilendirme
Hiçbir uygulama ITSM'deki onaylı kaydın dışında başlamaz. NCM'in değişiklik işi RFC numarasına bağlanır; RFC'siz değişiklik "yetkisiz" olarak etiketlenir.
-
Geri Besleme
Geri besleme döngüsü zorunludur. AIOps'un çıktısı yalnızca ekrana düşen bir panel değil; ITSM'e olay ve risk bilgisi, NCM'e düzeltme komutu olarak geri döner.
Her Katmanın Görevi
1. Asset Discovery: CI Tanımlama Ve Envanter Doğruluğu
-
Çok Kaynaklı
KeşifSNMP, WMI, SSH, ARP/LLDP/CDP, bulut sağlayıcı API'leri ve Kubernetes API'si ile fiziksel, sanal ve bulut varlıkları tek akışta bulunur. -
Zenginleştirme
Model, seri numarası, firmware/OS sürümü, yüklü yazılım, arayüz ve port bilgisi toplanır.
-
Topoloji Ve
BağımlılıkHangi CI'nin hangi servise ve hangi komşuya bağlı olduğu çıkarılır. Değişiklik etki analizi bu haritaya dayanır. -
Uzlaştırma
(Reconciliation)Mükerrer kayıtlar birleştirilir, uzun süredir görülmeyen CI'lar "emekliye ayrılma adayı" olarak işaretlenir, ağda görünüp CMDB'de olmayan cihaz shadow IT sinyali olarak raporlanır.
Ajansız Envanter Keşfi (Agentless Asset Discovery)
2. NCM: Baseline, Drift, Uyumluluk Ve Rollback
Ağ Yönetiminde Yeni Dönem: SolarWinds Network Configuration Manager (NCM)
3. İzleme: Değişikliğin Canlı Etkisi
Öncesi/Sonrası Karşılaştırma
Gecikme, paket kaybı, CPU/bellek, arayüz hata oranı ve servis erişilebilirliği değişiklik penceresinde izlenir.
Değişiklik Olayını Yakalama
Syslog (örneğin cihazın "configured from console" kaydı), SNMP trap ve API olayları, RFC dışı değişikliğin ilk habercisidir.
Zaman Çizelgesi Bindirmesi
Grafiklerin üzerine değişiklik işaretleri konur. Bir metrik sapması ile değişiklik aynı eksende görülür.
Servis Haritası
İş servisi ile onu taşıyan CI'ların ilişkisi izlenerek bir cihazdaki sapmanın hangi servise yansıdığı görünür.
İzleme Sistemleri ve CI Verileri Birlikte Yönetim ve Stratejik İlişki
4. AIOps: Korelasyon, Risk Ve Otomasyon
Not: AIOps katmanının değeri, beslendiği verinin kalitesiyle sınırlıdır. Envanter kirliyse korelasyon yanlış CI'lar arasında kurulur; değişiklik kayıtları eksikse "bu olay hangi değişiklikten?" sorusu cevapsız kalır. Bu yüzden yatırım sırası genellikle keşif, NCM, izleme, AIOps şeklindedir.
ODYA Automated NOC Çözümleri
Uçtan Uca Örnek: Bir Switch Değişikliği
Bir dağıtım katmanı switch'inde VLAN ve trunk ayarı değiştiriliyor. Döngü şöyle işler:
-
Adım 1
RFC açılır. Asset discovery'nin bağımlılık haritası, switch'e bağlı servisleri ve altındaki erişim switch'lerini etki alanı olarak listeler. AIOps, benzer geçmiş değişikliklerden orta düzey risk skoru ekler.
-
Adım 2
CAB onaylar, pencere tanımlanır. İzleme, pencere süresince ilgili CI'lar için planlı bakım moduna geçer; pencere dışı değişiklik anormal sayılır.
-
Adım 3
NCM uygular. Uygulamadan önce mevcut konfigürasyonu yedekler, şablonu RFC numarasıyla işler, farkı (diff) kayda ekler.
-
Adım 4
İzleme doğrular. Trunk portlarında hata oranı, komşu cihazlarda LLDP durumu ve servis erişilebilirliği canlı karşılaştırılır.
-
Adım 5
Sapma görülürse AIOps devreye girer. Bir uygulama servisindeki gecikme artışı, kesinti, alarm yağmuru ve az önceki değişiklik tek olayda birleştirilir; aday sebep olarak bu RFC gösterilir.
-
Adım 6
Rollback tetiklenir. Olgunluk seviyesine göre ya ekibe öneri olarak sunulur ya da onay kuralları dahilinde NCM, önceki sürüme otomatik döner. İzleme iyileşmeyi doğrular.
-
Adım 7
Kayıtlar kapanır. CMDB ilişkileri, ITSM kaydı, konfigürasyon versiyonu ve olay geçmişi güncellenir. Yeni baseline, başarı kriteri sağlanınca onaylanır.
Aynı switch'te RFC'siz yapılan bir CLI değişikliğinde zincir farklı başlar: syslog olayı NCM'in anlık karşılaştırmasını tetikler, baseline'dan sapma "yetkisiz değişiklik" olarak ITSM'de otomatik kayıt açar ve güvenlik/operasyon ekibine bildirim gider.
KPI Seti
Süreci ölçmeden iyileştirmek mümkün değildir. Aşağıdaki set beş gruba ayrılır. "Referans Hedef" sütunu başlangıç noktası olarak verilmiştir; kendi kritik varlık sınıflarınıza, sektörünüze ve olgunluk seviyenize göre kalibre edin.
| KPI | Hesaplama | Veri Kaynağı | Referans Hedef |
|---|---|---|---|
| A. Envanter ve CMDB Kalitesi | |||
| Envanter doğruluğu | Keşifle doğrulanan CI sayısı / CMDB'deki toplam CI × 100 | Asset discovery, CMDB | ≥ %95 (kritik varlıklarda ≥ %98) |
| Keşif kapsama oranı | Taranan subnet, bulut hesabı, cluster / bilinen toplam kapsam × 100 | Asset discovery | ≥ %95 |
| Veri tazeliği | CI başına son başarılı keşiften geçen süre (ortanca ve P95) | Asset discovery | Kritik CI için ≤ 24 saat |
| Kayıtsız (shadow) cihaz sayısı ve tespit süresi | Ağda görünüp CMDB'de olmayan CI adedi; ilk görülme–kayıt/kapatma arası süre | Asset discovery, NAC/ağ verisi | Trend aşağı; tespit < 24 saat |
| Mükerrer / hayalet kayıt oranı | Mükerrer ya da uzun süredir görülmeyen CI / toplam CI × 100 | CMDB | ≤ %2 |
| B. Konfigürasyon ve Uyumluluk | |||
| Baseline kapsama oranı | Onaylı baseline'ı olan CI / konfigürasyon yönetilebilir CI × 100 | NCM | ≥ %95 |
| Yedekleme başarı oranı | Başarılı yedek işi / planlanan yedek işi × 100 | NCM | ≥ %99 |
| Drift oranı | Baseline'dan sapan CI / baseline'lı CI × 100 | NCM | Trend aşağı; kritik sınıfta ≈ %0 onaysız drift |
| Drift tespit süresi | Değişikliğin yapıldığı an – sistemin tespit ettiği an | NCM, syslog/trap | Olay tabanlı < 15 dk; periyodik ≤ 24 saat |
| Drift düzeltme süresi | Tespit – baseline'a dönüş ya da yeni baseline onayı | NCM, ITSM | Kritik için ≤ 4 saat |
| Uyumluluk skoru | Geçen kontrol sayısı / toplam kontrol × 100 (çerçeve ve cihaz sınıfı bazında) | NCM | ≥ %90, yüksek riskli ihlal sayısı 0 |
| C. Değişiklik Yönetimi | |||
| Yetkisiz değişiklik oranı | RFC'siz tespit edilen değişiklik / toplam tespit edilen değişiklik × 100 | NCM, ITSM | ≤ %2 ve düşen trend |
| Değişiklik başarı oranı | Geri dönüş ve olay üretmeden kapanan değişiklik / toplam değişiklik × 100 | ITSM, NCM | ≥ %95 |
| Değişiklik kaynaklı olay oranı | Bir değişiklikle ilişkilendirilen olay / toplam olay × 100 | ITSM, AIOps | Trend aşağı |
| Ortalama rollback süresi | Rollback kararı – önceki sürümün doğrulanmış çalışması | NCM, izleme | ≤ 15 dk (otomatik rollback varsa dakikalar) |
| D. Operasyonel Sonuç | |||
| MTTD (Tespit Etme Süresi) | Sorunun başlangıcı – tespit edildiği an (ortalama) | İzleme, AIOps | Kritik servislerde < 5 dk |
| MTTR (Çözüm Süresi) | Olay açılışı – servis geri dönüşü (ortalama ve P90) | ITSM | Önceliğe göre SLA; değişiklik kaynaklı olaylarda ayrı izlenir |
| Değişiklik kaynaklı olaylarda tanı süresi | Olay açılışı – "sebep değişiklik" olarak belirlenme anı | AIOps, ITSM | Otomasyon sonrası belirgin düşüş (kendi baz çizginize göre) |
| E. AIOps ve Otomasyon Etkisi | |||
| Alarm gürültü azaltma oranı | 1 − (korelasyon sonrası olay sayısı / ham alarm sayısı) | AIOps | Kurulum sonrası ilk çeyrekte ölçülüp iyileştirilir |
| Otomatik çözülen olay oranı | İnsan müdahalesiz kapanan olay / toplam olay × 100 | AIOps, ITSM | Kademeli artış; düşük risk sınıfından başlanır |
| Korelasyon isabet oranı | Ekibin doğruladığı "sebep değişiklik" önerisi / toplam öneri × 100 | AIOps, ITSM geri bildirimi | ≥ %80 olunca öneri modundan otomasyona geçilir |
KPI'lar Nasıl Okunmalı?
-
Öncü Ve Sonuç
GöstergeleriEnvanter doğruluğu, baseline kapsama ve keşif kapsama öncü göstergelerdir. MTTR ve değişiklik kaynaklı olay oranı sonuç göstergeleridir. Öncüler iyileşmeden sonuçların iyileşmesini beklemek gerçekçi değildir. -
Kritikliğe Göre
Dilimleme%96'lık ortalama bir envanter doğruluğu, kritik varlıklardaki %80'lik doğruluğu gizleyebilir. -
Süreç Sinyali
Yetkisiz değişiklik oranını suçlayıcı değil, süreç sinyali olarak okuyun. Yüksek oran çoğunlukla acil değişiklik kanalının ya da şablon eksikliğinin işaretidir.
-
Veriye Dayalı
OtomasyonKorelasyon isabet oranı yeterince yükselmeden otomatik rollback açmayın.
Kademeli Olgunluk Yol Haritası
| Aşama | Odak | Çıktı |
|---|---|---|
| 1. Görünürlük | Otomatik keşif, CMDB uzlaştırma, yedekleme | Güvenilir envanter, her cihazın saklanan konfigürasyonu |
| 2. Kontrol | Baseline, drift tespiti, uyumluluk kuralları, RFC–NCM bağlantısı | Yetkisiz değişikliğin görünür olması |
| 3. Korelasyon | İzleme–değişiklik ilişkilendirme, olay gruplama, servis haritası | Kısalan tanı süresi, azalan alarm gürültüsü |
| 4. Öneri | Risk skoru, değişiklik–olay eşleme önerisi, runbook önerileri | CAB'a veri destekli girdi |
| 5. Otomasyon | Düşük riskli drift'te otomatik düzeltme, onaylı rollback | Artan otomatik çözüm oranı, insan onayı gereken olayların azalması |
Sık Yapılan Hatalar
Sıkça Sorulan Sorular
S: Konfigürasyon Yönetimi İle Değişiklik Yönetimi Arasındaki Fark Nedir?
Konfigürasyon yönetimi, varlıkların hangi durumda olması gerektiğini (baseline) ve gerçekte hangi durumda olduğunu kayıt altına alır. Değişiklik yönetimi ise bu durumu değiştirmek için talep, risk analizi, onay ve uygulama akışını yönetir. İkisi birlikte çalışır: değişiklik yönetimi baseline'ı kontrollü biçimde günceller, konfigürasyon yönetimi bunun kanıtını tutar.
S: Configuration Drift Nedir Ve Nasıl Tespit Edilir?
Configuration drift, bir cihazın çalışan konfigürasyonunun onaylı baseline'dan, onaysız ya da kayıt dışı bir değişiklikle sapmasıdır. NCM araçları çalışan konfigürasyonu periyodik ve olay tabanlı (syslog, trap, API) olarak çekip baseline ile karşılaştırarak drift'i tespit eder.
S: AIOps Konfigürasyon Yönetiminde Ne İşe Yarar?
AIOps; konfigürasyon değişikliği olaylarını izleme alarmlarıyla ilişkilendirir, bir olayın hangi değişiklikle bağlantılı olduğunu önerir, anormal sapmaları işaretler ve yeni bir değişiklik için geçmiş verilere dayalı risk skoru üretir. Olgunluk arttıkça drift düzeltme ve rollback gibi adımları otomatik tetikleyebilir.
S: CMDB'yi Güncel Tutmanın En Güvenilir Yolu Nedir?
CMDB'ye manuel giriş yerine otomatik keşif ve uzlaştırma (reconciliation) kullanmaktır. Asset discovery çözümü ağı, sunucuları, bulut hesaplarını ve konteyner ortamlarını periyodik tarar; mükerrer, eskimiş ve kayıtsız CI'ları tespit ederek CMDB ile eşler.
S: Bu Süreçte Hangi KPI'lar İzlenmelidir?
Envanter doğruluğu, keşif kapsama oranı, baseline kapsama oranı, drift oranı ve düzeltme süresi, yetkisiz değişiklik oranı, değişiklik başarı oranı, değişiklik kaynaklı olay oranı, MTTD, MTTR, alarm gürültü azaltma oranı ve otomatik çözülen olay oranı temel KPI'lardır.
Kendi Ortamınızda Bu Döngüyü Haritalamak İster Misiniz?
ODYA Teknoloji ekibi; SolarWinds NCM ile konfigürasyon ve uyumluluk yönetimini, SPIDYA Asset Discovery ile otomatik envanter ve CMDB uzlaştırmasını, ODYA Automated NOC ile korelasyon ve ITSM entegrasyonunu birlikte ele alan çalışma oturumları yapıyor. Mevcut araç envanterinizi ve prosedürünüzü birlikte inceleyip hangi adımın bugün hangi katman tarafından kanıtlandığını çıkarabiliriz.
Bize Ulaşın →