Dinamik bir BT altyapısında IT değişiklik yönetimi, sadece talep oluşturup onay almaktan çok daha fazlasını ifade eder. Bir sunucunun RAM'i yükseltildiğinde, network konfigürasyonları güncellendiğinde veya bir disk yenilendiğinde sistem sorunsuz çalışmaya devam edebilir; fakat bu adımlar kayda geçmediğinde altyapıda görünmez bir risk birikir.
BT ortamları statik değildir; donanımlar taşınır, yazılımlar güncellenir ve IP adresleri zamanla değişir. Buradaki temel sorun değişikliklerin gerçekleşmesi değil, süreçlerin izlenebilir olmamasıdır. Birkaç ay sonra yaşanacak muhtemel bir kriz anında IT ekibinin altyapının "gerçekte" ne durumda olduğunu bilmesi hayati önem taşır.
Bütüncül bir değişiklik yönetiminin ana amacı; kayıtlı altyapı (CMDB) ile canlı ortam arasındaki farkı en baştan tespit etmek ve her müdahalenin sistem üzerindeki etkisini görünür kılmaktır.
IT Değişiklik Yönetimi Neden Sadece Değişiklik Kaydı Tutmak Değildir?
Klasik change management yaklaşımında bir değişiklik; talep edilir, değerlendirilir, risk analizi yapılır, onaylanır, uygulanır ve sonrasında kapatılır. Ancak gerçek BT ortamında her değişiklik bu ideal akıştan geçmez.
Örneğin bir sistem yöneticisi performans problemini çözmek için sunucu üzerinde manuel bir ayar değiştirebilir. Bir teknisyen arızalı bir bileşeni değiştirebilir. Acil bir incident sırasında geçici bir konfigürasyon uygulanabilir.
Bu işlemler o anda sistemi çalışır durumda tutabilir. Ancak değişiklik daha sonra merkezi kayıtlara yansıtılmazsa zaman içinde şu tablo ortaya çıkar:
Kayıtlı altyapı ≠ Gerçek altyapı
Dolayısıyla IT değişiklik yönetimi, yalnızca “hangi değişiklik onaylandı?” sorusuna değil, “altyapımızda gerçekte ne değişti?” sorusuna da cevap verebilmelidir.
ServiceNow'un güncel Change Management yaklaşımında da değişikliklerin Configuration Item'larla (CI) ve etkilenen servislerle ilişkilendirilmesi, değişikliğin kapsamının ve etkisinin anlaşılması açısından önemli bir yapı olarak ele alınıyor.
Görünmeyen Bir Değişiklik Nasıl Büyük Bir Kesintiye Dönüşür?
Bir sunucuda kritik bir donanım bileşeninin değiştirildiğini düşünün. Değişiklik sırasında herhangi bir problem yaşanmadı. Sistem çalışmaya devam etti. Ancak değiştirilen bileşen veya yeni konfigürasyon merkezi kayıtlara işlenmedi.
Altı ay sonra aynı sunucuda performans problemi ortaya çıktı. IT ekibi sorunu araştırmaya başladığında yalnızca teknik problemi çözmekle uğraşmayacak. Önce mevcut ortamın gerçekten nasıl olduğunu anlamaya çalışacak:
- Sunucunun mevcut donanım konfigürasyonu nedir?
- Son değişiklik ne zaman yapıldı?
- Değişiklik hangi bileşende gerçekleşti?
- CMDB'deki bilgi güncel mi?
- Bu değişiklik başka hangi servisleri etkiledi?
- Daha önce benzer bir değişiklik yapılmış mı?
Böylece troubleshooting sürecine ikinci bir problem eklenir: “Arızanın nedeni ne?” sorusundan önce “Sistem gerçekten nasıl?” sorusunun cevaplanması gerekir.
Bu durum incident management süreçlerinde çözüm süresini uzatabilir ve özellikle kritik servislerde MTTR'ın yükselmesine neden olabilir.
IT Değişiklik Yönetimi ile Configuration Drift Arasındaki Bağlantı
Burada karşımıza önemli bir kavram çıkıyor: configuration drift. Configuration drift, bir sistemin veya altyapı bileşeninin zaman içinde beklenen ya da kayıtlı konfigürasyonundan uzaklaşması anlamına gelir.
Örneğin başlangıçta:
- Sunucu A → 64 GB RAM
- İşletim sistemi → belirli bir sürüm
- Network konfigürasyonu → belirli yapı
- Yazılım versiyonu → X
Aylar sonra:
- Sunucu A → 128 GB RAM
- İşletim sistemi → yeni sürüm
- Network konfigürasyonu → değişmiş
- Yazılım versiyonu → Y
Ancak merkezi kayıtlarda hâlâ ilk durum bulunuyorsa altyapınızda bir configuration drift oluşmuştur.
AWS de configuration drift'in tespit edilmesini, altyapı ve konfigürasyonların beklenen durumla tutarlı kalması açısından bir güvenilirlik pratiği olarak ele alıyor. Özellikle değişikliklerin izlenmemesi, olay sırasında yanlış bir hazır olma algısına yol açabilecek risklerden biri olarak belirtiliyor.
Bu nedenle IT değişiklik yönetimi, configuration drift'in yalnızca oluşmasını engellemek değil, oluşan farklılıkların mümkün olduğunca erken fark edilmesini sağlamak açısından da önemlidir.
Altyapınızdaki Değişiklikleri Neden Sonradan Fark Ediyorsunuz?
Birçok kurumda problem değişiklik yönetimi sürecinin hiç olmaması değildir. Asıl problem, planlanan değişiklikler ile gerçek ortamda gerçekleşen değişiklikler arasında boşluk oluşmasıdır.
Gerçekte olan: Disk değiştirildi ve ek olarak farklı bir donanım bileşenine müdahale edildi.
Eğer bu ikinci değişiklik kayıt altına alınmazsa sistem zaman içinde gerçek durumdan uzaklaşır.
Benzer şekilde:
- Bir sunucu başka bir lokasyona taşınabilir.
- Bir network cihazının IP adresi değişebilir.
- Bir sanal makine farklı bir host üzerine taşınabilir.
- Bir yazılım versiyonu planlanandan farklı şekilde güncellenebilir.
- Kullanımdan kaldırılan bir cihaz sistemde hâlâ aktif görünebilir.
Bu nedenle değişiklik takibi yalnızca change request'lerin durumunu izlemekten ibaret olmamalıdır.
IT Değişiklik Yönetimi İçin Sorulması Gereken 4 Kritik Soru
1. Altyapımızda Ne Değiştiğini Biliyor muyuz?
Bir Configuration Item'ın donanımı, işletim sistemi, IP bilgisi veya konfigürasyonu değiştiğinde bu değişikliği tespit edebiliyor musunuz?
Örneğin bir sunucunun RAM'i 64 GB'dan 128 GB'a çıkarıldıysa, bu değişiklik merkezi kayıtlara yansımadıysa ileride yapılacak troubleshooting yanlış bilgiler üzerinden başlayabilir.
2. Planlanan Değişiklik ile Gerçek Değişiklik Aynı mı?
Bir change request'in başarıyla kapatılması, altyapının mutlaka beklenen durumda olduğu anlamına gelmez. Uygulama sırasında farklı bir işlem yapılmış olabilir. Acil müdahale gerekmiş olabilir. Bir teknisyen planlanan kapsamın dışında bir bileşene müdahale etmiş olabilir.
Bu nedenle change management ile keşif ve doğrulama mekanizmalarının birbirini tamamlaması gerekir.
3. Değişiklik Hangi CI ve Servisleri Etkiliyor?
Bir sunucuda yapılan değişiklik yalnızca o sunucuyu ilgilendirmeyebilir.
Sunucu → Uygulama → Veritabanı → Network → İş Servisi
şeklindeki bağımlılıkların görünür olması, değişiklik etkisinin daha doğru değerlendirilmesini sağlar. Bu noktada CMDB'nin rolü yalnızca kayıt tutmak değil, Configuration Item ilişkilerini ve servis bağımlılıklarını görünür hale getirmektir.
👉 CMDB ve ağ envanteri uyumsuzluğu üzerine hazırladığımız içerik de kayıtlı yapı ile gerçek ağ ortamı arasındaki farkın neden yalnızca bir veri problemi olmadığını detaylandırıyor.
4. Değişikliğin Geçmişini Görebiliyor muyuz?
Bir problem ortaya çıktığında yalnızca mevcut konfigürasyonu görmek yeterli değildir. IT ekibinin şu soruya da cevap verebilmesi gerekir: “Bu sistemde problem başlamadan önce ne değişti?”
Değişiklik geçmişi görünür olduğunda incident management ve problem management süreçleri daha güçlü bir veriyle çalışabilir. Böylece ekipler yalnızca mevcut semptomlara değil, değişiklik geçmişine de bakarak kök nedeni araştırabilir.
Özellikle tekrar eden sorunlarda, problemin yalnızca semptomunu çözmek yerine kalıcı nedenini araştırmak gerekir.
Bu konuda 👉 IT’de Bitmeyen Yangınlardan Sıkılmadınız mı? Problem Yönetimi ile ITSM’de Radikal Dönüşüm içeriğimizde problem yönetiminin bu süreçteki rolünü detaylandırıyoruz.
IT Değişiklik Yönetimi Neden Discovery ile Birlikte Düşünülmeli?
Burada önemli bir ayrım var. IT değişiklik yönetimi, değişikliklerin planlanması, değerlendirilmesi ve kontrol edilmesini sağlar. Ancak gerçek altyapının ne durumda olduğunu görebilmek için önce ortamı keşfetmek gerekir.
İşte IT asset discovery bu noktada devreye girer.
Otomatik discovery mekanizmaları; fiziksel cihazlar, sanal makineler, network bileşenleri ve diğer BT varlıkları hakkında güncel veriler toplayarak mevcut ortamın görünür hale gelmesine yardımcı olabilir. Bu veriler merkezi kayıtlarla karşılaştırıldığında, beklenen durum ile gerçek durum arasındaki farkların tespit edilmesi kolaylaşır.
SPIDYA'nın 👉 Network Discovery Nedir? içeriğinde de otomatik discovery'nin ağdaki varlıkları tespit ederek CMDB ile ilişkilendirme yaklaşımı ele alınıyor.
Buradaki amaç yalnızca: “Kaç cihazımız var?” sorusunu cevaplamak değildir.
Asıl soru: “Altyapımızda kayıtlarımızdan farklı olarak ne değişti?” olmalıdır.
Sonuç: Bilmediğiniz Değişiklik, Yönetemediğiniz Risktir
BT altyapınız değişir. Yeni cihazlar eklenir, mevcut sistemler güncellenir, donanımlar değiştirilir ve konfigürasyonlar zaman içinde farklılaşır. Risk, değişikliğin gerçekleşmesinde değil; değişikliğin görünür olmamasında ortaya çıkar. Çünkü IT ekipleri bir incident yaşandığında kararlarını doğru ve güncel bilgiye göre vermek zorundadır.
Bu nedenle IT değişiklik yönetimi yalnızca değişiklik talebi oluşturmak ve onaylamakla sınırlı kalmamalıdır. Değişen altyapının gerçek durumunu sürekli olarak görünür tutacak keşif, doğrulama ve konfigürasyon yönetimi mekanizmalarıyla desteklenmelidir.
Çünkü bazen bir sonraki büyük kesintinin habercisi büyük bir arıza değildir. Kimsenin fark etmediği küçük bir değişikliktir.
