Sunucuda Değişiklik Yönetimi

Sunucu kesintilerinin önemli bir kısmı donanım arızasından değil, yapılan bir değişiklikten kaynaklanır. Değişiklik yönetimi, bu riski azaltan basit bir disiplindir.

Değişiklik yaşam döngüsü

1. Talep

Değişiklik ihtiyacı ortaya çıkar: bir güncelleme, yeni bir bileşen, bir yapılandırma düzeltmesi.

• ☐ Ne değişecek?
• ☐ Neden gerekli?
• ☐ Kim talep etti?
• ☐ Ne zamana kadar?

2. Değerlendirme

• ☐ Hangi sistemleri etkiler?
• ☐ Kesinti gerektirir mi, ne kadar?
• ☐ Riskler neler?
• ☐ Geri dönüş mümkün mü?
• ☐ Test edilebilir mi?
• ☐ Bağımlı sistemler var mı?

3. Sınıflandırma

Her değişikliği aynı süreçle ele almak ya çok yavaş ya çok riskli olur.

4. Planlama

• ☐ Uygulama zamanı belirlendi (düşük yoğunluk)
• ☐ Süre tahmini yapıldı
• ☐ Kim uygulayacak, belli
• ☐ Etkilenen birimler bilgilendirildi
• ☐ Geri dönüş planı yazıldı
• ☐ Geri dönüş kararını kim verecek, belli
• ☐ Doğrulama adımları listelendi

5. Hazırlık

• ☐ Tam yedek alındı
• ☐ Anlık görüntü alındı (sanal/bulut ortamda)
• ☐ Mevcut yapılandırma kaydedildi
• ☐ Test ortamında denendi
• ☐ Kritik iş akışları test edildi

İkinci madde geri dönüş süresini dakikalara indirir ve neredeyse hiçbir maliyeti yoktur.

6. Uygulama

• ☐ Planlanan zamanda yapıldı
• ☐ Adımlar takip edildi
• ☐ Beklenmedik durumlar kaydedildi
• ☐ Süre kaydedildi

7. Doğrulama

• ☐ Servisler çalışıyor
• ☐ Uygulamalar açılıyor
• ☐ Kritik iş akışları test edildi
• ☐ Entegrasyonlar çalışıyor
• ☐ Zamanlanmış görevler çalışıyor
• ☐ İzleme normal değerler gösteriyor
• ☐ Performans karşılaştırıldı
• ☐ Kullanıcı testi yapıldı

8. Kayıt

• ☐ Ne değişti
• ☐ Ne zaman
• ☐ Kim yaptı
• ☐ Neden
• ☐ Sonuç
• ☐ Yaşanan sorunlar
• ☐ Belgeler güncellendi

Bu kayıt, bir sorun çıktığında "ne değişti?" sorusunu dakikalar içinde cevaplar ve tanı süresini büyük ölçüde kısaltır.

Geri dönüş planı

Her değişiklik için önceden yazılmalıdır:

• Hangi durumda geri dönülür? (eşik tanımı)
• Kararı kim verir?
• Nasıl dönülür? (adımlar)
• Ne kadar sürer?
• Geri dönüşten sonra ne yapılır?

Kural: Geri dönüş yolu olmayan bir değişiklik, planlanmış bir risktir; bu bilinerek yapılmalıdır.

Değişiklik dondurma dönemleri

Belirli dönemlerde değişiklik yapılmaz:

• Kampanya ve yoğun satış dönemleri
• Dönem sonu kapanışları
• Bordro dönemi
• Denetim dönemleri
• Kritik personelin izinde olduğu zamanlar
• Uzun tatiller öncesi

Son madde deneyimle sabittir: Tatil öncesi yapılan bir değişiklik, sorun çıktığında müdahale edecek kimse olmadığı için en pahalı kesintileri doğurur.

Kim onaylar?

Küçük değişiklik yanılgısı

En pahalı kesintiler genelde "küçük" görülen değişikliklerden doğar:

• "Sadece bir ayar değiştirdim"
• "Küçük bir güncellemeydi"
• "Bir eklenti kurdum"
• "Sadece bir dosya sildim"

Kural: Değişikliğin büyüklüğü, yaratabileceği etkiyle ölçülür — yapılan işin süresiyle değil.

Asgari süreç

Tam bir değişiklik yönetimi süreci ağır gelebilir. Asgari uygulama:

1. ☐ Değişiklik öncesi anlık görüntü/yedek al
2. ☐ Düşük yoğunluklu bir zamanda yap
3. ☐ Sonrasında kritik akışları test et
4. ☐ Ne yaptığını kaydet

Bu dört madde, değişiklik kaynaklı kesintilerin büyük çoğunluğunu önler ve toplamda birkaç dakika sürer.