Kurumsal yapılarda değişim onayı çoğu zaman “kim imzaladı?” sorusuna sıkışır. Oysa üretim sistemleri açısından asıl belirleyici soru, değişikliğin hangi risk varsayımıyla kabul edildiğidir. Teknik lider için onay sürecinin değeri, daha fazla kutucuk işaretlemekten değil; riskin sınırını, geri alma koşulunu ve görünürlük beklentisini önceden tanımlamaktan gelir. Ben buna risk kontratı demeyi daha doğru buluyorum.
Risk kontratı neyi değiştirir?
Klasik change approval toplantılarında konuşma çoğu zaman bu düzeyde kalır:
- Değişiklik ne zaman çıkacak?
- Kim nöbette olacak?
- Problem olursa kimi arayacağız?
Bunlar gerekli ama yetersiz sorulardır. Risk kontratı ise aynı değişikliği şu eksende ele alır:
- Beklenen etki nedir?
- Kabul edilen başarısızlık yüzeyi nedir?
- Durdurma veya geri alma eşiği nedir?
- Hangi sinyal karar için zorunludur?
Bu çerçeve sayesinde onay, kişisel sezgi değil ortak mühendislik dili hâline gelir.
Teknik lider neden bu modelin sahibi olmalı?
Çünkü riskin dili ekipler arasında kendiliğinden eşit dağılmaz. Ürün ekibi iş değerine, operasyon ekibi sistem etkisine, güvenlik ekibi kontrol zayıflığına bakar. Teknik liderin görevi bu perspektifleri tek cümlede toplayabilen net bir karar alanı kurmaktır.
Ben pratikte şu başlıkları kontratın merkezine koyuyorum:
- Rollout tipi
- Etki alanı
- Gözlem sinyalleri
- Geri alma süresi
- Karar sahibi
Bu beşli yazılmadığında kurumlar görünürde onaylı ama gerçekte belirsiz değişiklikler üretir.
CAB yerine ne gelir?
Bu noktada sık yapılan hata, “kurul istemiyoruz” diyerek kontrolsüz serbestlik ilan etmektir. Oysa olgun model kurulun yerini boşlukla değil, yapılandırılmış risk diliyle değiştirir.
Örneğin düşük riskli değişikliklerde:
- standart rollout politikası önceden tanımlanır,
- sağlık sinyalleri otomatik ölçülür,
- rollback eşiği nettir,
- ek onay gerekmez.
Yüksek riskli değişikliklerde ise insan değerlendirmesi sürer; fakat tartışmanın konusu hâlâ kontratın kendisidir, kişinin ünvanı değil.
Operasyon kültürüne etkisi nedir?
Risk kontratı ekipleri daha yavaş değil, daha dürüst yapar. Çünkü şöyle bir ortam yaratır:
- Bilinmeyen alanlar açıkça yazılabilir.
- “Henüz yeterli sinyalimiz yok” demek zayıflık sayılmaz.
- Geri alma kararı kişisel başarısızlık yerine sözleşme gereği kabul edilir.
Bu kültür özellikle kıdemli mühendislerin davranışıyla yayılır. Bir lider kontratı ciddiye aldığında ekipler de “onay almak” ile “riski anlamak” arasındaki farkı öğrenir.
Hangi değişikliklerde özellikle faydalıdır?
Ben bu modeli en çok şu durumlarda yüksek değerli buluyorum:
- altyapı bileşeni sürüm geçişleri,
- ağ politikası veya egress değişiklikleri,
- ERP entegrasyon akışı güncellemeleri,
- kimlik ve erişim sınırı etkileyen rollout’lar,
- gözlemlenebilirlik pipeline değişiklikleri.
Çünkü bu tip değişikliklerde sorun çoğu zaman yalnızca hata üretmek değil, hatanın geç fark edilmesidir.
Sonuç
Teknik liderler için risk kontratı ile değişim onayı, gereksiz bürokrasiyi romantize eden bir karşı çıkış değil; daha olgun bir mühendislik işletimi modelidir. Onayın değeri imza sayısından değil, riskin ne kadar açık tarif edildiğinden gelir. Bu ayrım kurulduğunda kurumlar sadece daha güvenli değişiklik yapmaz; değişiklik hakkında daha dürüst konuşmaya başlar.