ITIL v4 Uyumlu Olay ve Değişiklik Yönetimi: Neden Canlı Sistemde Cuma Günü Güncelleme Yapılmaz?
Küçük şirketlerde sistem yöneticiliği genellikle "Kovboy Tarzı" yürütülür: Mühendisin aklına bir fikir gelir, mesai saatinde ana firewall'a girip kuralı değiştirir veya canlı SQL sunucusunu öğle arasında yeniden başlatır. Şanslıysa her şey çalışır; şanssızsa şirket saatlerce durur ve kimse neyin değiştiğini bilmediği için arızayı bulamaz. Kurumsal holding yapılarında ve olgun organizasyonlarda bu amatörlük kabul edilemez. Süreçleri disipline eden dünya standardı ITIL v4 Hizmet Yönetimi mimarisidir.
1. Olay (Incident) vs Problem Yönetimi Arasındaki Fark
- Olay Yönetimi (Incident Management): "Yangını söndürmektir." Amaç servisi mümkün olan en hızlı sürede eski çalışır haline getirmektir. Örneğin çöken bir servisi hızla yeniden başlatmak bir olay çözümüdür.
- Problem Yönetimi (Problem Management): "Yangının neden çıktığını bulmaktır." O servis neden durdu? Kök Neden Analizi (Root Cause Analysis - RCA) yapılarak aynı arızanın bir daha asla tekrarlanmaması sağlanır.
2. Değişiklik Yönetimi (Change Management) ve CAB Onayı
Canlı üretim ortamındaki hiçbir sunucuya, anahtara veya veri tabanına keyfi müdahale edilemez! Her değişiklik öncesinde bir Değişiklik Talep Formu (RFC - Request for Change) doldurulmalıdır:
RFC Şablonu:
1. Değişikliğin Tanımı: ESXi 7.0'dan 8.0'a yükseltme.
2. İş Gerekçesi: VMware güvenlik açıklarının kapatılması ve yeni donanım desteği.
3. Etki Alanı (Impact Analysis): Yükseltme sırasında 30 sanal makine vMotion ile diğer hostlara aktarılacak; kesinti beklenmiyor.
4. Risk Seviyesi: Orta.
5. Planlanan Zaman: Cumartesi 01:00 - 04:00 (Bakım Penceresi).
6. GERİ ALMA PLANI (Rollback Plan): Eğer host açılmazsa, eski USB boot medyası takılarak ESXi 7.0 konfigürasyon yedeğinden 15 dakikada geri dönülecek!
Bu form Değişiklik Danışma Kurulu (CAB - Change Advisory Board) tarafından incelenir ve onaylandıktan sonra takvime işlenir.
3. Neden Cuma Günü Canlıya Değişiklik Yapılmaz? (Read-Only Friday)
Sektörün yazılı olmayan en kutsal kuralı: "Cuma günü canlı sistemde majör değişiklik yapılmaz!"
- Cuma akşamı yapılan bir değişiklikte beklenmedik bir arıza çıkarsa tedarikçiler kapalıdır, destek ekipleri hafta sonu tatilindedir ve pazartesi sabahı krizle uyanırsınız.
- Bakımlar daima hafta içi mesai bitiminde veya pazar gecesi yapılmalıdır.
Karşılaşılan Kritik Hatalar ve Çözüm İpuçları
- Geri Alma (Rollback) Planı Olmayan Değişiklik: Bir değişikliğe başlarken "Nasılsa sorun çıkmaz" diye düşünüyorsanız büyük bir yanılgıdasınız. Geri alma planı (Plan B) yazılmamış hiçbir değişiklik onaylanamaz.
Mühendis Notu
ITIL süreçleri işi yavaşlatmak için değil; kurumun güvenliğini ve sistem yöneticisinin mesleki itibarını korumak için vardır. Kurumsal bir süreçle onaylanmış ve kayıt altına alınmış bir bakımda sorun çıksa dahi yöneticiniz sizi suçlayamaz; çünkü süreç profesyonelce işletilmiştir.