Onay Kurulu Darboğaza Dönünce: İşin Süreçten Kaçtığı An

Değişiklik onay kurulu, kontrolü artırmak için kurulur. Belli bir noktadan sonra ise ters yönde çalışmaya başlar: onay süresi uzadıkça iş durmaz, yolunu değiştirir. Bu yazı, kurulun ne zaman darboğaza dönüştüğünü, işin hangi kanallardan kaçtığını ve kontrolü kaybetmeden nasıl hızlanılacağını anlatıyor.

Darboğazın Belirtileri

Darboğaz kendini nadiren doğrudan gösterir. Aşağıdaki belirtilerin üçü birden varsa kurul artık kontrol üretmiyor, gecikme üretiyor demektir.

Toplantı gündemi taşıyor. Haftalık toplantıda otuz kalem varsa ve toplantı bir saat sürüyorsa her kaleme iki dakika düşüyor demektir. İki dakikada bir veritabanı betiğinin etkisi değerlendirilemez. Onay verilir, ama değerlendirilmiş olmaz.

Acil oranı yükseliyor. Toplam değişikliklerin dörtte birinden fazlası acil olarak sınıflandırılıyorsa acil kanal, bekleme süresinden kaçmanın yolu haline gelmiştir. Gerçek acil sayısı bu kadar yüksek olmaz; yükselen şey acele değil, sabırsızlıktır.

Talepler toplantıdan hemen önce toplu geliyor. Ekipler, bir sonraki kurula yetişmek için işi bekletir ve son anda gönderir. Bu, kurulun ritmini işin ritminin önüne geçirir; iş, teknik gereklilikle değil takvimle zamanlanmaya başlar.

Red kararı neredeyse hiç çıkmıyor. Bir kurulun aylardır hiçbir talebi reddetmemiş olması, taleplerin kusursuz olduğunu değil, kurulun eleme yapacak zamanı olmadığını gösterir. Onay oranı yüzde yüze yaklaştıkça kurul bir kontrol olmaktan çıkıp bir kayıt adımına dönüşür.

İşin Süreçten Kaçtığı An

Onay kurulu darboğaza dönüştüğünde insanlar yolunu bulur. Değişiklikler incelenmeden gönderilir, belgeleme atlanır ve ortamda gerçekte neyin değiştiğine dair görünürlük kaybedilir. Bu, kötü niyetin değil, tasarımın sonucudur; iş bitmek zorundadır ve önündeki en kısa yolu seçer.

Veritabanı tarafında kaçış kanalları özellikle boldur, çünkü üretim veritabanına ulaşmanın onaylı yol dışında birçok yolu vardır.

Bu tablonun en rahatsız edici tarafı şudur: kaçış kanallarının hiçbiri kural ihlali olarak görülmez. Her satırdaki gerekçe, o anda makul bir gerekçedir. Kurum kural ihlali yaşamaz; kapsam dışılık yaşar ve bu, panoda kırmızı görünmez.

Onay Yorgunluğu: Kurul Dolduğunda Ne Olur

Kaçış kanalları sürecin dışındaki riski oluşturur. İçeride ise farklı bir bozulma yaşanır: onaylayan kişi, önüne gelen kalemi gerçekten inceleyemeyecek kadar çok kalem görür.

Bunun somut sonucu, onayın içerikten kopmasıdır. Onaylayan, betiğe değil gönderen kişiye güvenir. "Ahmet gönderdiyse doğrudur" cümlesi bir kontrol değildir; kişiye bağımlılığın en saf halidir. Ahmet ayrıldığında kaybolan şey bir çalışan değil, sürecin gerçek kontrol mekanizmasıdır.

Onay yorgunluğunun çaresi daha fazla disiplin çağrısı değildir. Çare, onaylayanın önüne gelen kalem sayısını azaltmak ve gelen her kalemin yanında değerlendirmenin özetini sunmaktır. Onaylayan kişi betiğin tamamını okumak zorunda kalmadan neyin riskli olduğunu görebiliyorsa, otuz kalem yerine üç kaleme odaklanabilir.

Risk Tabanlı Yetki Dağıtımı

ITIL 4, değişiklik yönetimi terimini değişiklik etkinleştirme olarak değiştirirken tam olarak bu sorunu hedefledi. Çerçevenin söylediği açıktır: onay yetkisi riske göre dağıtılmalı, her değişiklik merkezi bir kurula yönlendirilmemelidir. Standart ve küçük normal değişiklikleri kurula göndermek bir hata deseni olarak nitelenir; gerekçesi değişiklik kalitesini artırmadan darboğaz üretmesidir.

Aynı çerçeve, değişiklik yetkilisinin bir kişi, bir ekip veya otomatik bir mekanizma olabileceğini söyler. Bu ayrıntı çoğu kurumda gözden kaçar. Yetkilendirmenin bir toplantı olması zorunlu değildir; tanımlı, tekrarlanabilir ve kayıt bırakan bir mekanizma da yetkilendirme sayılır.

Veritabanı Tarafında Nasıl Kurulur

Risk tabanlı yetki dağıtımının veritabanı katmanındaki karşılığı dört parçadan oluşur ve dördü birlikte çalışmak zorundadır.

Riskin betikten çıkarılması. Bandı insan seçmez, betiğin içeriği belirler. Koşulsuz bir güncelleme, kritik nesne listesindeki bir tabloya dokunma, geri alınamaz bir işlem: bunların hepsi yazılı kurallardır ve aynı betik her zaman aynı bandı alır. Kişiye bağımlılık burada biter.

Banda göre onay derinliği. Düşük bant tek onayla veya önceden yetkilendirmeyle geçer. Orta bant ilgili ekip liderinin onayını gerektirir. Yüksek bant çok kişili onay ve gerekçe ister. Kurulun gündemine yalnızca en üst bant gelir ve gündem otuz kalemden üçe iner.

Onayın kapıya bağlanması. Onay bir alan değil bir koşuldur. Onay tamamlanmadan çalıştırma açılmaz ve onaylayan kendi talebini çalıştıramaz. Bu olmadan hızlanma, kontrolü gerçekten azaltır; bu olduğunda hızlanma yalnızca gereksiz beklemeyi ortadan kaldırır.

Acil kanalın ölçülmesi. Acil yol kapatılmaz, çünkü kapatılırsa iş büsbütün kayıt dışına çıkar. Bunun yerine acil kanaldan geçen her değişiklik bir sonradan değerlendirme kaydı üretir ve bu kayıt kapanana kadar açık listede durur. Liste uzuyorsa kaçış kanalı kendini ele verir.

Ölçülecek Dört Sayı

Kurulun sağlıklı olup olmadığı dört sayıyla anlaşılır. Dördünü de bugün, mevcut kayıtlarınızdan çıkarabilirsiniz.

Bu dört sayıdan ikisi bozuksa sorun ekipte değil, sürecin tasarımındadır. Daha sıkı uygulama çağrısı bu tabloyu düzeltmez; yetkiyi riske göre dağıtmak düzeltir.

SQL Change Guard bu modeli veritabanına dokunan iş için kurar: riski betiğin içeriğinden ölçer, banda göre onay derinliğini belirler, onayı çalıştırma kapısına bağlar ve acil kanaldan geçen işin sonradan değerlendirme borcunu açık listede tutar. Kurulunuz ortadan kalkmaz; yalnızca gerçekten değerlendirmesi gereken işleri görür.

Sık Sorulan Sorular

Onay kurulunu tamamen kaldırmalı mıyız?

Hayır. Kurul, gerçekten değerlendirme gerektiren yüksek riskli değişiklikler için doğru yerdedir ve orada değeri yüksektir. Kaldırılması gereken şey kurul değil, kurulun gündemindeki düşük riskli kalemlerdir. Gündem otuz kalemden üçe indiğinde kurul ilk kez asıl işini yapmaya başlar: o üç kalemi gerçekten tartışmak.

Düşük riskli işleri kuruldan çıkarırsak denetimde sorun yaşar mıyız?

Tersine. ITIL 4 yetkinin riske göre dağıtılmasını açıkça önerir ve değişiklik yetkilisinin otomatik bir mekanizma olabileceğini söyler. Denetçinin aradığı şey her değişikliğin bir kurula gitmiş olması değil, her değişikliğin tanımlı bir yetkiye göre değerlendirilmiş, kaydedilmiş ve izlenebilir olmasıdır. Önceden yetkilendirme, kaydın ortadan kalkması anlamına gelmez; kaydın kim tarafından onaylandığının önceden belli olması anlamına gelir.

Risk bandını kim belirliyor? Gönderen kişi düşük seçerse ne olur?

Bandı gönderen kişi seçmemelidir; bu, tüm modeli çürüten tek hatadır. Band, betiğin içeriğinden yazılı kurallara göre üretilmelidir: hangi nesneye dokunuyor, kritik nesne listesinde mi, koşulsuz güncelleme var mı, geri alınabilir mi. Kullanıcı bandı düşüremez, yalnızca gerekçeli bir istisna talep edebilir ve o istisna ayrıca kaydedilir. Değerlendirmenin makineye verilmesinin asıl faydası hız değil, yeniden üretilebilirliktir.

Acil kanalı kısıtlarsak gerçek acil durumda ne yapacağız?

Acil kanal kısıtlanmamalı, ölçülmelidir. Kapatılan bir acil yolu işi durdurmaz, yalnızca kayıt dışına iter ve bu en kötü sonuçtur. Doğru kurgu şudur: acil yol her zaman açıktır, geçen her değişiklik gerekçesiyle kaydedilir ve olaydan sonra bir değerlendirme kaydı üretir. O kayıt kapanana kadar açık listede durur. Böylece gerçek acil durum engellenmez, kolaylık amaçlı kullanım ise görünür hale gelir.

Onay yorgunluğunu nasıl azaltırız?

İki şeyle: onaylayanın önüne gelen kalem sayısını azaltmak ve gelen her kalemin yanına değerlendirme özetini koymak. Onaylayan, betiğin hangi nesneye dokunduğunu, hangi kuralların tetiklendiğini ve geri alma betiğinin üretilip üretilmediğini tek bakışta görebiliyorsa karar gerçek bir karar olur. Betiğin tamamını okumak zorunda bırakılan bir onaylayan, üçüncü kalemden sonra okumayı bırakır.