Kazanimlar:
- Yapay zeka ile change request, risk değerlendirme ve rollback planı taslaklayıp değişikliği güvenli ve öngörülebilir kılabilme
- Etki alanını kendi bağımlılık bilgisiyle genişletme, geri alınabilirliği sınıflandırma ve canary ile kademeli dağıtım planlama becerisi kazanabilme
- Değişikliği onaylayan, zamanlayan ve sorumluluğunu taşıyanın insan olduğunu kavrayıp başarı kriteri ve geri dönüş yolu olmadan uygulama yapmama disiplini edinebilme
Değişiklik Yönetimi: YZ ile Risk Değerlendirme, Rollback ve Bakım Penceresi
Üretim sistemlerinde felaketlerin büyük çoğunluğu bir saldırıdan değil, bir değişiklikten çıkar: bir yama, bir yapılandırma güncellemesi, bir sürüm dağıtımı, bir "küçük" düzeltme. Bu yüzden olgun her kurumda değişiklik yönetimi vardır: bir üretim değişikliğinin planlanması, riskinin değerlendirilmesi, onaylanması, uygulanması ve gerektiğinde geri alınmasını disipline eden süreç. Amaç değişimi engellemek değil, onu güvenli ve öngörülebilir kılmaktır. İşte YZ, bir değişiklik talebini (change request) taslaklamakta, risklerini ve etkilenen sistemleri listelemekte, bir geri dönüş (rollback) planı iskeleti kurmakta ve bir dağıtım kontrol listesi hazırlamakta güçlü bir asistandır. Ama temel kural değişmez: YZ değişikliği ve riski belgeleme taslağı üretir; değişikliği onaylayan, zamanlayan ve sorumluluğunu üstlenen insandır.
Bu ünitede change request (değişiklik talebi), risk değerlendirme, rollback planı, bakım penceresi (maintenance window), canary/kademeli dağıtım ve CAB (Change Advisory Board — değişiklik danışma kurulu) kavramlarını; YZ ile güvenli değişiklik planlamayı öğreneceksiniz.
İyi bir değişiklik talebinin anatomisi
Kontrolsüz bir değişiklik "şunu güncelledim" cümlesidir; kontrollü bir değişiklik ise bir plandır. İyi bir change request şu soruları yanıtlar: Ne değişiyor? (kapsam), Neden? (gerekçe), Hangi sistemler etkilenir? (etki alanı ve bağımlılıklar), Risk düzeyi ne? (düşük/orta/yüksek), Ne zaman? (bakım penceresi), Nasıl uygulanır? (adımlar), Nasıl doğrulanır? (başarı kriteri), Kötü giderse nasıl geri alınır? (rollback), Kim onaylar? (yetki). YZ bu iskeleti hızla doldurur — ama etki alanını ve riski gerçekten bilen, kurumu tanıyan sizsiniz; YZ'nin listesini kendi bağımlılık bilginizle tamamlarsınız.
İpucu: Bir değişikliğin en çok atlanan iki parçası "geri dönüş planı" ve "başarı doğrulama kriteri"dir. Değişikliği uygulamadan önce "kötü giderse tam olarak hangi komutla nereye dönerim" ve "başarılı olduğunu nasıl kanıtlarım" sorularına yazılı cevabınız yoksa, o değişiklik henüz hazır değildir.
Rollback: her değişikliğin çıkış kapısı
Değişiklik yönetiminin kalbi geri dönüş planıdır. Her değişikliğin bir rollback (geri alma) yolu olmalıdır: yamayı geri al, önceki yapılandırmayı geri yükle, sürümü bir önceki sürüme döndür, snapshot'tan geri dön. Kritik ayrım şudur: bazı değişiklikler kolay geri alınır (bir yapılandırma satırı), bazıları geri alınamaz veya çok zordur (bir veritabanı şema göçü, bir veri silme). Geri alınamaz değişiklikler en yüksek risk sınıfıdır ve en fazla dikkat, en fazla yedek, en dar bakım penceresi ister. YZ'ye "bu değişiklik geri alınabilir mi, geri alınamazsa hangi ek güvenlik önlemlerini almalıyım" diye sorun.
Bakım penceresi ve kademeli dağıtım
Bakım penceresi, değişikliğin en az kullanıcıyı etkileyeceği, önceden ilan edilmiş zaman aralığıdır — tipik olarak trafiğin düşük olduğu gece veya hafta sonu. Ama zamanı iyi seçmek yetmez; değişikliği kademeli yaymak riski daha da azaltır. Canary dağıtım, değişikliği önce küçük bir kısma (bir sunucu, kullanıcıların %5'i) uygulayıp izlemek, sorun yoksa yaymaktır. Böylece bir hata tüm filoyu değil, küçük bir kısmı etkiler ve erken yakalanır. YZ'den bir kademeli dağıtım planı ve her aşamada izlenecek metrikleri isteyebilirsiniz.
Adım adım: YZ destekli değişiklik
- Talebi taslakla. Değişikliği YZ ile yukarıdaki başlıklarda belgeleyin.
- Etkiyi genişlet. YZ'nin etkilenen sistem listesini kendi bağımlılık haritanızla tamamlayın; "bu servise bağlı başka ne var?"
- Riski sınıflandır. Düşük/orta/yüksek ve geri alınabilir mi? Yüksek ve geri alınamaz olan en katı süreci gerektirir.
- Rollback yaz ve test et. Geri dönüş adımlarını yazın ve mümkünse test ortamında geri dönüşü deneyin — geri alınamayan bir "rollback planı" plandan sayılmaz.
- Pencere ve kademe planla. Bakım penceresini ve canary aşamalarını, her aşamada izlenecek metrikleri belirleyin.
- Onay ve iletişim. Yetkili onayını (gerekiyorsa CAB) alın, etkilenenleri bilgilendirin, uygulayın, izleyin, doğrulayın.
Üç mini vaka
Vaka 1 — Rollback planı geceyi kurtardı. Bir ekip, bir web sunucusu yamasını uyguladı; yama beklenmedik şekilde bir bağımlılığı bozdu ve site 500 hatası vermeye başladı. Ama change request'te YZ ile hazırlanmış net bir rollback adımı vardı: "yamayı kaldır, önceki paketi geri yükle, servisi reload et." Ekip 6 dakikada geri döndü. Rollback planı olmasaydı, kök nedeni gece yarısı ararken kesinti saatlerce sürerdi.
Vaka 2 — Canary bir hatayı %5'te yakaladı. Bir yeni sürüm dağıtılacaktı. Ekip YZ'den kademeli dağıtım planı istedi: önce 1 sunucu, izle, sonra %25, sonra tümü. Canary sunucuda yanıt sürelerinin iki katına çıktığı görüldü; dağıtım durduruldu. Hata sadece bir sunucuda kaldı, kullanıcıların %95'i hiç etkilenmedi. Tek seferde yayılsaydı tüm servis çökecekti.
Vaka 3 — Geri alınamaz değişikliğin ek önlemi. Bir veritabanı şema göçü planlanıyordu — geri alınması çok zor bir değişiklik. Mühendis YZ'ye riski sordu; YZ değişikliğin geri alınamaz sınıfta olduğunu ve tam yedek, ayrı test koşusu ve dar pencere önerdiğini belirtti. Ekip göçten hemen önce tam yedek aldı, önce bir kopyada denedi. Göç sırasında bir sorun çıktı ama yedek sayesinde 20 dakikada tutarlı duruma dönüldü.
Dört kopyalanabilir şablon
1) Değişiklik talebi taslağı:
Rolün: değişiklik yönetimi uzmanı. Şu değişiklik için birchange request taslağı hazırla: [değişiklik]. Başlıklar:Ne/Neden, Etkilenen Sistemler ve Bağımlılıklar, Risk Düzeyi(düşük/orta/yüksek + gerekçe), Geri Alınabilir mi, UygulamaAdımları, Başarı Doğrulama Kriteri, Rollback Adımları, BakımPenceresi Önerisi, Gerekli Onay. Emin olmadığın bağımlılığı"doğrula" diye işaretle.
2) Risk ve etki değerlendirme:
Şu değişikliği risk açısından değerlendir: [değişiklik].(1) Doğrudan ve dolaylı etkilenebilecek sistemleri listele,(2) en kötü senaryo nedir, (3) geri alınabilir mi, değilsehangi ek önlemleri almalıyım, (4) risk düzeyini gerekçesiylesöyle. Bunun bir ön değerlendirme olduğunu, kararın bendeolduğunu belirt.
3) Rollback planı üretme:
Şu değişiklik için [değişiklik] adım adım bir geri dönüşplanı yaz. Her adım kopyalanabilir ve doğrulanabilir olsun.Değişikliğin geri alınamaz kısımları varsa açıkça belirt veonlar için hangi yedeği almam gerektiğini yaz. Rollback'inbaşarısını nasıl doğrularım, onu da ekle.
4) Kademeli dağıtım (canary) planı:
Şu dağıtım için [dağıtım] kademeli bir plan öner: hangiaşamalar (ör. 1 sunucu -> %25 -> tümü), her aşamada ne kadarbeklemeli ve HANGİ metrikleri izlemeliyim (yanıt süresi,hata oranı vb.)? Hangi eşik aşılırsa dağıtımı durdurup gerialmalıyım? Karar noktalarını net yaz.
Zayıf prompt / Güçlü prompt
Zayıf prompt:
Bu yamayı uygulayayım mı?
Bağlam, etki, yedeklilik, pencere yok. YZ ne sisteminizi tanır ne riskinizi bilir; vereceği "evet/hayır" sorumsuz bir tahmindir.
Güçlü prompt:
Rolün: değişiklik yönetimi uzmanı. Üretimdeki bir websunucusu filosuna (8 sunucu, yük dengeleyici arkasında)güvenlik yaması uygulayacağım. Bana: (1) bu değişiklik içinbir change request taslağı, (2) etkilenebilecek bağımlılıklar(ben teyit edeceğim), (3) rollback adımları, (4) 1 sunucu ->%25 -> tümü şeklinde canary planı ve her aşamada izleyeceğimmetrikleri ver. Risk düzeyini gerekçelendir. Onay ve kararbende.
Değişiklik özelliği
Düşük risk
Yüksek risk
Geri alınabilirlik
Kolay rollback
Geri alınamaz / zor
Etki alanı
Tek servis, izole
Çok servis, bağımlılık zinciri
Dağıtım
Doğrudan olabilir
Zorunlu canary + dar pencere
Onay
Ekip içi
CAB / üst onay
Yedek
Standart
Ek tam yedek + test koşusu
Sık yapılan hatalar
- Rollback planı olmadan uygulamak. Geri dönüş yolu yazılı değilse, değişiklik bir kumardır.
- Etki alanını dar tutmak. Bir servise bağlı gizli bağımlılıkları atlamak, beklenmedik yan kesintilere yol açar.
- Geri alınamaz değişikliği sıradan sanmak. Şema göçü ve veri silme gibi değişiklikler en katı süreci ve tam yedeği ister.
- Tek seferde tüm filoya yaymak. Canary olmadan bir hata tüm kullanıcıları aynı anda vurur.
- Başarı kriterini tanımlamamak. "Başarılı" ne demek yazılı değilse, bozuk bir değişikliği "tamamlandı" sanabilirsiniz.
Dikkat: YZ'nin ürettiği etkilenen sistem listesi bir başlangıçtır, tam liste değildir. Kurumunuzun bağımlılıklarını YZ bilmez; "bu servis çökerse başka ne çöker" sorusunun tam cevabı sizin kurumsal bilginizdedir. YZ'nin listesini eksik varsayıp genişletin.
Özetle
Üretim felaketlerinin çoğu saldırıdan değil değişiklikten çıkar; değişiklik yönetimi değişimi engellemez, onu güvenli ve öngörülebilir kılar. YZ; change request, risk değerlendirme, rollback planı ve kademeli dağıtım kontrol listelerini hızla taslaklar. Ama etki alanını gerçek bağımlılık bilginizle genişletin, geri alınabilirliği sınıflandırın, rollback'i yazıp mümkünse test edin, bakım penceresi ve canary ile riski dağıtın, başarı kriterini tanımlayın. Değişikliği onaylayan, zamanlayan ve sorumluluğunu taşıyan insandır; YZ planı hızlandıran ortaktır.
Uygulama görevi
Yakında yapmayı planladığınız (veya yakın zamanda yaptığınız) bir üretim değişikliğini seçin. Yukarıdaki "Değişiklik talebi taslağı" şablonuyla YZ'den tam bir change request hazırlatın. YZ'nin ürettiği "etkilenen sistemler" listesini kendi bağımlılık bilginizle en az iki madde genişletin. "Rollback planı üretme" şablonuyla geri dönüş adımlarını yazdırın ve değişikliğin geri alınamaz bir kısmı olup olmadığını belirleyin. Son olarak bir canary planı çıkarın. Tüm planı 6 maddede özetleyip hangi onayların gerektiğini not edin.
Kontrol listesi
- [ ] Değişiklik için ne/neden, etki, risk, adım, doğrulama ve rollback içeren bir talep hazırladım mı?
- [ ] YZ'nin etkilenen sistem listesini kendi bağımlılık bilgimle genişlettim mi?
- [ ] Değişikliğin geri alınabilir mi geri alınamaz mı olduğunu sınıflandırdım mı?
- [ ] Rollback adımlarını yazdım ve mümkünse test ortamında denedim mi?
- [ ] Bakım penceresi ve kademeli (canary) dağıtım planı ile her aşamanın izleme metriğini belirledim mi?
- [ ] Başarı doğrulama kriterini tanımlayıp gerekli onayları aldım mı?