Değişiklik Yönetimi Prosedürü Örneği: BT ve Veritabanı İçin Şablon

"Değişiklik yönetimi prosedürü örneği" aramasında karşınıza çıkan belgelerin çoğu kalite yönetim sistemleri için yazılmıştır: bir üretim hattındaki malzeme ya da makine değişikliği. Bilgi teknolojileri, özellikle de veritabanı değişiklikleri için bu şablonlar eksik kalır. Bu yazı, BT ekiplerinin doğrudan uyarlayabileceği bir prosedür iskeletini ve veritabanına özgü maddeleri bölüm bölüm verir.

Genel Prosedür Veritabanında Neden Yetmez?

Uygulama koduyla gelen değişiklik bir derleme ve dağıtım hattından geçer; veritabanı değişikliği ise çoğu zaman bir betiktir ve bir kişinin elinden çalışır. Üç fark prosedüre yazılmazsa denetimde açık kalır:

• Onaylanan şey metindir: Bilet "müşteri tablosuna kolon ekle" der; çalışan ise belirli bir SQL metnidir. Onayın hangi metne verildiği kayıtta durmalıdır.
• Geri almak kendiliğinden olmaz: Silinen satır ya da düşürülen kolon bir önceki sürümü yükleyerek geri gelmez. Geri alma betiği değişiklikle birlikte hazırlanmalıdır.
• Okuma da bir işlemdir: Üretimden veri çekmek yapıyı değiştirmez ama kişisel veriyi dışarı çıkarır. Bu talepler prosedürde ayrı bir türdür.

Prosedür Şablonu: On Bölüm

1. Amaç: Üretim sistemlerinde yapılacak değişikliklerin kontrollü, izlenebilir ve geri alınabilir biçimde yapılması.
2. Kapsam: Uygulama, altyapı ve veritabanı değişiklikleri; üretimden veri talepleri; yetki değişiklikleri. Kapsam dışı kalanlar açıkça yazılır.
3. Tanımlar: Standart, normal ve acil değişiklik; değişiklik penceresi; geri alma; kişisel veri.
4. Roller: Talep eden, değişiklik yöneticisi, teknik onaylayan, iş onaylayan, uygulayan (DBA), değişiklik danışma kurulu.
5. Görevler ayrılığı: Talep eden kendi talebini onaylamaz; mümkünse onaylayan ile çalıştıran farklı kişidir. İstisna varsa kim ve hangi koşulda yapabileceği yazılır.
6. Risk sınıflandırması: Değişikliğin hangi ölçütlerle düşük, orta ya da yüksek riskli sayılacağı ve her seviyenin gerektirdiği onay sayısı.
7. Süreç adımları: Talepten kapanışa kadar her adım, sorumlusu ve çıktısı (aşağıda).
8. Acil değişiklik: Kimin acil ilan edebileceği, sonradan hangi sürede gözden geçirileceği ve eksik kalan onayın nasıl tamamlanacağı.
9. Kayıtlar: Her değişiklik için saklanacak kanıtlar ve saklama süresi.
10. Gözden geçirme: Prosedürün ne sıklıkla güncelleneceği; reddedilen ve başarısız değişikliklerin dönemsel analizi.

Değişiklik Türleri

Süreç Adımları

1. Talep: Talep eden gerekçeyi, hedef sunucu ve veritabanını, betiği ve geri alma betiğini girer.
2. Ön kontrol: Betik yazım kurallarına ve yasaklı kalıplara karşı denetlenir (örneğin WHERE'siz UPDATE, üretimde DROP).
3. Risk sınıflandırması: Etkilenen nesneler ve kurallar risk seviyesini belirler; seviye gereken onay adımlarını belirler.
4. Test: Değişiklik üretim dışı bir ortamda denenir ve sonucu kayda eklenir.
5. Onay: Onaylayan betiğin kendisini görür; onay o metne verilir. Metin onaydan sonra değişirse onay geçersiz sayılır.
6. Planlama: Değişiklik penceresi ve bağımlı değişiklikler belirlenir.
7. Uygulama: Uygulayan, onaylanan metni çalıştırır; başlangıç ve bitiş zamanı, sonuç ve hatalar kayda geçer.
8. Doğrulama: Talep eden beklenen sonucun oluştuğunu teyit eder; gerekirse geri alma çalıştırılır.
9. Kapanış: Kayıt kapatılır; acil değişiklikse gözden geçirme tarihi atanır.

Saklanacak Kayıtlar

Denetçinin bir değişiklik için sorduğu sorular bellidir: kim istedi, kim onayladı, onaylanan neydi, çalışan o muydu, kim çalıştırdı, sonuç ne oldu? Prosedürün kayıtlar bölümü bu soruların her birine karşılık gelen kanıtı adlandırmalıdır: talep ve gerekçe, betik metni ve özeti, onay adımları ve onaylayanlar, test sonucu, çalıştırma zamanı ve sonucu, geri alma kararı. Reddedilen talepler de saklanır; kontrolün çalıştığını en iyi onlar gösterir.

Prosedürün Kâğıtta Kalmaması

Yazılı prosedür denetimde ilk istenen belgedir, ama tek başına yeterli değildir. Denetçi örneklem seçer ve prosedürün o kayıtlarda uygulandığını görmek ister. Kayıtlar e-posta, bilet sistemi, dosya klasörü ve veritabanı logu arasında dağınıksa her örneklem kalemi için bu parçaları birleştirmek gerekir; bunun neden zor olduğu çalıştırılan SQL, onaylanan SQL miydi? yazısında anlatılıyor.

SQL Change Guard bu prosedürün veritabanı kısmını adım adım uygulamak için tasarlandı: talep, ön kontrol, risk seviyesine göre onay, onaylanan metinle çalıştırılacak metnin karşılaştırılması, kontrollü çalıştırma ve her talep için bir denetim dosyası. Prosedürünüzü değiştirmez; onu kayıt üreten bir akışa dönüştürür.

Sık Sorulan Sorular

Değişiklik yönetimi prosedürü kaç sayfa olmalı?

Uzunluk değil kapsam önemlidir. Yukarıdaki on bölümü karşılayan bir prosedür çoğu kurumda birkaç sayfayı geçmez; ayrıntılar (risk ölçütleri, onay matrisi) ek olarak tutulabilir.

Acil değişiklikte onay atlanabilir mi?

Atlanmaz, kısaltılır. Prosedür acil yolu kimin açabileceğini, hangi onayın önce alınacağını ve kalanın ne kadar süre içinde tamamlanacağını yazmalıdır. Ayrıntılı uygulama acil veritabanı değişikliği yazısında var.

ITIL ve ISO 27001 bu prosedürü zorunlu kılar mı?

ITIL bir iyi uygulama çerçevesidir, zorunluluk getirmez. ISO 27001 ise değişiklik yönetimini Ek A kontrolleri arasında sayar; sertifika hedefleyen kurum bunu belgelenmiş ve uygulanan bir süreçle göstermelidir.

Veritabanı değişikliği için ayrı prosedür mü gerekir?

Gerekmez; genel BT değişiklik prosedürüne veritabanına özgü maddeler eklemek yeterlidir: onaylanan metnin saklanması, geri alma betiği ve üretimden veri talebinin ayrı tür olarak tanımlanması.