Değişiklik Yönetimi ile Sürüm Yönetimi: ITIL'de Onay Vermek ile Kullanıma Açmak Arasındaki Fark
Değişiklik yönetimi bir değişikliğin yapılıp yapılmayacağına ve ne zaman yapılacağına riskini tartarak karar verir; sürüm yönetimi ise yeni ya da değişmiş hizmetin ve özelliklerin kullanıma nasıl açılacağını planlar. Biri izin ve zamanlama, diğeri paketleme ve kullanıma sunma işidir.
Bir bakışta
- Değişiklik yönetiminin sorusu 'yapmalı mıyız, ne zaman?' sorusudur. Risk değerlendirilir, değişiklik yetkilendirilir ve değişiklik takvimi yönetilir.
- Sürüm yönetiminin sorusu 'kullanıcıya nasıl ve ne zaman açacağız?' sorusudur. Yeni ve değişmiş hizmetler kurum politikalarına ve hizmet anlaşmalarına uygun biçimde kullanıma sunulur.
- Bir sürüm çoğu zaman birden fazla değişikliği bir arada taşır. Değişiklikler tek tek yetkilendirilir, sürüm onları birlikte planlar ve kullanıma açar.
- Dağıtım ile sürüm aynı şey değildir. ITIL 4 bileşenleri canlı ortama taşımayı ayrı bir uygulama olan dağıtım yönetimine bırakır.
- Bu değişiklik yönetimi, örgütsel değişim yönetimi değildir. ADKAR ya da Kotter gibi modeller insanların değişime uyumunu ele alır; burada konu BT hizmetlerindeki değişikliktir.
Ortak zemin: aynı değişikliğin iki farklı sorusu
ITIL 4'te değişiklik yönetimi (change enablement) ve sürüm yönetimi (release management) ayrı uygulamalardır, ama aynı iş akışının içinde yan yana çalışırlar. İkisinin de konusu, bir BT hizmetinde yapılacak yenilik ya da düzeltmedir: yeni bir uygulama özelliği, bir sunucu yapılandırması, bir yama, bir ağ değişikliği.
PeopleCert'in uygulama tanımlarına göre değişiklik yönetimi, risklerin doğru değerlendirilmesini sağlayarak, değişiklikleri yetkilendirerek ve değişiklik takvimini yöneterek başarılı hizmet ve ürün değişikliklerinin sayısını en üst düzeye çıkarmayı amaçlar. Sürüm yönetimi ise yeni ve değişmiş hizmetlerin, kurumun politikalarına ve hizmet tüketicileriyle yapılan anlaşmalara uygun biçimde kullanıma sunulmasıyla ilgilenir.
Kısacası değişiklik yönetimi 'bu değişikliği yapmalı mıyız, riski kabul edilebilir mi, ne zaman yapılmalı?' sorularını yanıtlar. Sürüm yönetimi ise 'onaylanmış değişiklikler hangi pakette, hangi sırayla ve hangi kullanıcılara açılacak?' sorusunu yanıtlar. Eski ITIL metinlerinde ve gündelik dilde değişiklik yönetimi için change management ifadesi de kullanılır.
Ölçüt ölçüt farklar
- Ölçüt: Temel soru. Değişiklik yönetimi: bu değişiklik yapılmalı mı, ne zaman? / Sürüm yönetimi: değişiklikler kullanıcıya nasıl ve ne zaman açılacak?
- Ölçüt: Odak. Değişiklik yönetimi: risk değerlendirmesi ve yetkilendirme. / Sürüm yönetimi: paketleme, planlama, zamanlama ve kullanıma sunma.
- Ölçüt: Birim. Değişiklik yönetimi: tek bir değişiklik kaydı. / Sürüm yönetimi: bir ya da birden fazla değişikliği içeren sürüm.
- Ölçüt: Temel çıktı. Değişiklik yönetimi: yetkilendirilmiş ya da reddedilmiş değişiklik, güncel değişiklik takvimi. / Sürüm yönetimi: sürüm planı, sürüm notları, kullanıma açılan hizmet ve özellikler.
- Ölçüt: Karar veren. Değişiklik yönetimi: değişikliğin türüne ve riskine göre belirlenmiş değişiklik yetkilisi. / Sürüm yönetimi: sürüm yöneticisi ve ürün ya da hizmet sahipleri.
- Ölçüt: Başarı ölçüsü. Değişiklik yönetimi: başarılı değişiklik oranı, değişiklik kaynaklı olaylar, onay süreleri. / Sürüm yönetimi: sürümlerin zamanında ve beklenen sonucu vererek kullanıma açılması, geri alma ihtiyacı.
İkisinin arasında bir üçüncü uygulama daha vardır: dağıtım yönetimi. Bileşenlerin teknik olarak canlı ortama taşınması dağıtımdır; o bileşenlerin sağladığı özelliğin kullanıcılara açılması ise sürümdür. Bu ayrım, özellik bayraklarıyla çalışan ekiplerde belirginleşir: kod canlıya dağıtılmıştır, ama özellik henüz kullanıma açılmamıştır.
Karar, taşıma ve kullanıma açma üç ayrı iştir
- Değişiklik yönetimiRisk değerlendirilir, değişiklik yetkilendirilir, takvime yerleştirilir.
- Dağıtım yönetimiBileşenler test ve canlı ortamlara teknik olarak taşınır.
- Sürüm yönetimiYeni ve değişmiş özellikler planlanan zamanda kullanıcılara açılır.
Bir değişikliğin yolculuğu
Bir bankanın mobil uygulamasına yeni bir para transferi ekranı eklendiğini düşünün. Ekranın kendisi, arka plandaki servis güncellemesi ve bir veritabanı şema değişikliği ayrı değişikliklerdir.
- Değişiklik kaydı açılır. Her değişiklik için ne yapılacağı, neden yapılacağı, etkilenecek hizmetler ve geri alma planı yazılır.
- Risk değerlendirilir ve yetkilendirilir. Veritabanı değişikliği yüksek riskli olduğu için daha kapsamlı bir değerlendirmeden geçer; ekran değişikliği daha hızlı onaylanır.
- Sürüm planlanır. Sürüm yöneticisi üç değişikliği tek bir sürümde toplar, hazırlık ölçütlerini ve kalite kapılarını belirler, sürüm notlarını hazırlatır.
- Dağıtım yapılır. Bileşenler onaylanmış zaman aralığında canlı ortama taşınır.
- Özellik kullanıma açılır. Yeni ekran önce küçük bir kullanıcı grubuna, sorun görülmezse tüm kullanıcılara açılır.
- Değişiklikler kapatılır. Sonuç doğrulanır, değişiklik kayıtları başarılı ya da başarısız olarak kapatılır ve takvim güncellenir.
Bu akışta değişiklik yönetimi başta ve sonda, sürüm yönetimi ise ortada belirleyicidir. İkisi de birbirine bilgi verir: sürüm planı değişiklik takvimine yansır, değişiklik takvimi de sürümün hangi pencerede çıkabileceğini belirler.
Değişiklik onaylanır, sürüm planlanır, özellik kullanıma açılır
- Değişiklik kaydıNe, neden, etkilenen hizmetler, geri alma planı.
- Risk ve yetkilendirmeDeğişiklik yetkilisi riske göre karar verir.
- Sürüm planıDeğişiklikler pakete girer, kalite kapıları belirlenir.
- DağıtımBileşenler onaylı pencerede canlıya taşınır.
- Kullanıma açmaÖzellik önce sınırlı gruba, sonra herkese açılır.
- Doğrulama ve kapanışSonuç doğrulanır, kayıtlar ve takvim güncellenir.
Değişiklik türleri ve sürüm ritmi
ITIL 4 değişiklikleri riskine ve sıklığına göre farklı yollardan geçirir. Standart değişiklikler, riski düşük ve iyi anlaşılmış, önceden yetkilendirilmiş değişikliklerdir; her seferinde ayrı onay gerektirmez. Normal değişiklikler türüne göre belirlenmiş değişiklik yetkilisinin değerlendirmesinden geçer. Acil değişiklikler ise bir olayı çözmek ya da bir güvenlik açığını kapatmak için hızla uygulanması gereken değişikliklerdir ve olabildiğince hızlı yetkilendirilir.
Sürüm yönetimi bu türlerin hepsiyle çalışır, ama ritmi farklıdır. Kimi kurumlar belirli aralıklarla büyük sürümler çıkarır; kimileri ise sürekli teslimatla çok sık ve küçük sürümler yayımlar. Sürümler küçüldükçe her sürümdeki değişiklik sayısı azalır, risk değerlendirmesi kolaylaşır ve standart değişiklik olarak önceden yetkilendirilen değişikliklerin payı artar.
Bu nedenle olgun ekiplerde iki uygulama birbirini yavaşlatmaz: değişiklik yönetimi otomasyon ve önceden yetkilendirme ile güvenli yolu hızlandırır, sürüm yönetimi de küçük ve sık sürümlerle her değişikliğin riskini düşürür.
Sık yapılan hatalar
- Her değişikliği aynı onay kuruluna götürmek. Düşük riskli, tekrarlanan değişikliklerin standart değişiklik olarak tanımlanmaması onay kuyruklarını uzatır ve ekipleri süreci atlamaya iter.
- Sürüm onayını değişiklik onayı sanmak. Sürümün çıkmasına karar vermek, içindeki her değişikliğin riskinin değerlendirildiği anlamına gelmez.
- Dağıtımı ve sürümü aynı an saymak. Kod canlıya taşındığında özellik kullanıcıya açılmış olmayabilir; ikisinin ayrı izlenmesi, sorun anında doğru adımın seçilmesini sağlar.
- Geri alma planını sürüm düzeyinde düşünmemek. Tek tek değişikliklerin geri alma planı olsa da birlikte çıkan değişikliklerin sırası ve bağımlılıkları sürüm planında ele alınmalıdır.
- BT değişiklik yönetimini örgütsel değişim yönetimiyle karıştırmak. Yeni bir sistemin çalışanlarca benimsenmesi ayrı bir konudur ve farklı yöntemlerle yönetilir.
Mindset programlarında nerede çalışılır?
Bu ayrım, BT hizmet yönetimi ekipleri, değişiklik kurulu üyeleri, sürüm yöneticileri ve DevOps ekipleri için gündelik bir koordinasyon sorusudur. Değişiklik Yönetimi (Change Enablement) ve Değişiklik Kurulu İşleyişi eğitimi sınıflandırma, risk değerlendirmesi, standart değişiklikler ve kurul işleyişini ele alır. Release Engineering ve Sürüm Yönetimi Pratikleri eğitimi kalite kapılarını, ekipler arası koordinasyonu ve yayın yürütmeyi işler. ITIL® 4 Foundation Eğitimi ise iki uygulamayı hizmet değer zinciri içinde konumlandırır.
İlgili Mindset programı
Değişiklik Yönetimi (Change Enablement) ve Değişiklik Kurulu İşleyişi
Sık sorulan sorular
Değişiklik danışma kurulu (CAB) ITIL 4'te hâlâ var mı?
ITIL 4 değişiklik yetkilisi kavramını öne çıkarır: bir değişikliği kimin onaylayacağı, değişikliğin türüne ve riskine göre belirlenir. Bu yetkili bir kişi, bir ekip ya da bir kurul olabilir. Pek çok kurum yüksek riskli değişiklikler için kurul toplantılarını sürdürür, düşük riskli değişiklikleri ise önceden yetkilendirir ya da ekip düzeyinde onaylatır.
Sürüm yönetimi ile sürüm kontrolü (version control) aynı şey mi?
Değildir. Sürüm kontrolü, kaynak kodun ve yapılandırma dosyalarının değişiklik geçmişini Git gibi araçlarla tutmaktır. Sürüm yönetimi ise hangi değişikliklerin hangi pakette, ne zaman ve kimlere açılacağını planlayan hizmet yönetimi uygulamasıdır. Sürüm yönetimi, sürüm kontrolündeki etiket ve dal stratejisinden yararlanır ama ondan çok daha geniş bir koordinasyonu kapsar.
Sürüm notlarını kim hazırlar, değişiklik kaydından farkı ne?
Değişiklik kaydı içeriye dönüktür: neyin değiştiğini, riskini, onayını ve geri alma planını BT ekipleri ve değişiklik yetkilisi için belgeler. Sürüm notları ise dışarıya dönüktür: kullanıcıya ve destek ekiplerine hangi yeniliklerin geldiğini, nelerin düzeltildiğini ve bilinen sorunları anlatır. Sürüm yönetimi sürecinde hazırlanır; içeriği ürün sahipleri ve destek ekipleriyle birlikte netleştirilir.
DevOps ortamında değişiklik yönetimine gerek kalır mı?
Gerek kalır, ama biçim değişir. Otomatik testler, dağıtım hattındaki kalite kapıları ve izleme verisi risk değerlendirmesinin bir parçası haline gelir; tekrarlanan değişiklikler standart değişiklik olarak önceden yetkilendirilir. Böylece değişiklik yönetimi bir bekleme noktası olmaktan çıkar ve hızlı akışı güvenli kılan kurallar bütününe dönüşür.
Küçük bir BT ekibi bu iki uygulamayı nasıl ayırmalı?
Ayrı ekipler kurmak gerekmez, ayrı sorular sormak yeterlidir. Her değişiklik için kısa bir kayıt, risk notu ve geri alma planı tutulur; kimin onaylayacağı önceden bellidir. Sürüm tarafında ise hangi değişikliklerin birlikte çıkacağı, kullanıcıya nasıl duyurulacağı ve sorun çıkarsa nasıl geri dönüleceği planlanır. Aynı kişi iki şapkayı da takabilir.
İlgili rehberler
İlgili eğitimler
Kategori: BT Yönetişimi ve Stratejisi