Ayar Değişikliğinde Dört Göz İlkesi Nasıl Kurulur?

Değişiklik yönetimi süreçlerinin çoğu talepleri kontrol eder ama ayarları unutur. Oysa bir kontrolü kapatan ayar, o kontrolün koruduğu tüm talepleri aynı anda etkiler. Tek bir onay kutusu, aylarca süren bir sürecin çıktısını geçersiz kılabilir. Bu yazı ayar değişikliklerini dört göz ilkesine bağlamanın pratik tasarımını anlatır.

Neden Ayar Değişikliği Kritiktir?

Üç nedenden. Birincisi etki alanı: bir talep tek bir işlemi etkiler, bir ayar tüm işlemleri etkiler. İkincisi görünürlük: talep bir onay akışından geçer ve birden fazla kişi görür, ayar değişikliği ise genellikle tek bir ekranda tek bir tıklamadır. Üçüncüsü geri dönüş: yanlış bir talep geri alınabilir, gevşetilmiş bir kontrolün o süre içinde neyi kaçırdığı geri getirilemez.

Tasarımın Kalbi: Canlı Kayda Dokunmamak

Onay bekleyen bir ayar değişikliğini saklamanın iki yolu vardır. Birincisi ayar satırına bir "beklemede" bayrağı koymak ve yeni değeri aynı satırda tutmak. Bu yol kolay görünür ama ayarı okuyan her yeri değiştirmenizi gerektirir; bir yeri unutursanız yarı uygulanmış bir kontrol ortaya çıkar. Bu, çözmeye çalıştığınız sorundan daha tehlikelidir.

İkincisi ve doğrusu, bekleyen değişikliği tamamen ayrı bir kayıtta tutmaktır. Gerçek ayar tablosuna onay verilene kadar dokunulmaz. Sistemin geri kalanı hiçbir şey bilmez ve eski değeri okumaya devam eder. "Eski değer onaya kadar geçerli" kuralı böylece ek bir çaba gerektirmeden sağlanır.

Onay verildiğinde ne olur? En temiz yöntem, kullanıcının yaptığı kaydetme işlemini aynı yoldan tekrar oynatmaktır. Böylece o işlemin normalde geçtiği tüm kontroller ikinci kez çalışır: yetki, doğrulama, lisans sınırı ve eşzamanlılık kontrolü. Onay anında lisans limitinin yeniden kontrol edilmesi önemlidir, çünkü bağlayıcı an talep anı değil onay anıdır.

Kapsam Nasıl Seçilir?

Tüm ayarları onaya bağlamak ilk bakışta en güvenli seçenek gibi görünür, pratikte ise en kırılgan olanıdır: e-posta sunucusu adresini değiştirmek için onay beklemek ekibi kısa sürede yorar ve özellik kapatılır. Üç kademeli bir kapsam çoğu kurumda dengeyi kurar:

• Kapalı: özellik devre dışı. Başlangıç için makul bir varsayılan.
• Yalnızca kontrol ayarları: maskeleme rejimi, onay politikası, görevler ayrılığı, otomatik çalıştırma, geri alma zorunluluğu gibi ayarlar onaya düşer. İşletme ayarları akışı yavaşlatmaz.
• Tüm ayarlar: yüksek düzenlemeye tabi kurumlar için.

Hangi ayarın "kontrol ayarı" sayılacağı listesi açıkça yazılmalıdır. Bu liste zamanla büyür; her yeni kontrol eklendiğinde listeye eklenip eklenmeyeceği sorulmalıdır.

Onay Yetkisi Kimde Olmalı?

Buradaki yaygın hata, yeni bir "onaylayan" rolü tanımlamaktır. Yeni rol yeni bir yetki matrisi, yeni bir atama süreci ve yeni bir bakım yükü demektir. Daha sade bir çözüm vardır: onay yetkisi, ilgili ayar ekranının kendi yetkisi olsun. Sunucu ayarlarını değiştirebilen bir kullanıcı, başka birinin sunucu ayarı değişikliğini onaylayabilir.

Bu yaklaşımın mantığı sağlamdır: o ekranı değiştirme yetkisi olan kişi, o ekranın içeriğini değerlendirebilecek kişidir. Ayrıca yetki zaten rol tanımında mevcuttur, ek bir şey kurmaya gerek kalmaz.

Tek mutlak kural şudur: kimse kendi talebini onaylayamaz. Bu kural parametreye bağlanmamalıdır. Kapatılabilir bir dört göz ilkesi, dört göz ilkesi değildir.

Beş Tuzak

1. Özelliğin kendisini korumasız bırakmak. Dört göz kuralını yöneten parametre de bir kontroldür. Açmak anında uygulanabilir ama kapatmak onay gerektirmelidir; aksi halde kural tek tıkla devre dışı bırakılır.

2. Yeni kayıt eklemeyi kilitlemek. Bekleyen bir ekleme talebi, başka bir yeni kayıt talebini engellememelidir. Kilit anahtarı doğru seçilmezse iki kullanıcı birbirini bloke eder.

3. Kullanıcıya "kaydedildi" demek. Değişiklik onaya düştüğünde arayüz bunu açıkça söylemelidir. Başarı mesajı gören kullanıcı ayarın uygulandığını sanır ve bu yanılgı en kötü anda ortaya çıkar.

4. Eski ve yeni değeri yan yana göstermemek. Onaylayan kişi neyin değiştiğini görmelidir. Yalnızca yeni değeri gösteren bir ekran, onayı bir formaliteye dönüştürür.

5. Hassas değeri ekranda açmak. Bekleyen değişiklik bir parola veya anahtar içeriyorsa, onay ekranında bu değer maskelenmelidir. Onaylayanın görmesi gereken değişikliğin varlığıdır, değerin kendisi değil.

Sık Sorulan Sorular

Her ayar değişikliği onaya mı düşmeli?

Hayır, bu süreci boğar ve kimse okumadan onaylamaya başlar. Kapsam kontrolü gevşeten ayarlarla sınırlanmalıdır: onay kuralları, maskeleme rejimi, geri alma zorunluluğu gibi. Görünüm tercihleri ve etiket metinleri aynı kapıdan geçmek zorunda değildir.

Onay bekleyen değişiklik neden canlı kayda yazılmıyor?

Çünkü yazılırsa ayar onaylanmadan yürürlüğe girer. Bekleyen değişikliği ayrı tutmanın ikinci faydası, onay anında değişikliğin aynı komutla yeniden oynatılabilmesidir: uygulama yolu tek kalır, ikinci bir yazma kodu yazılmaz ve iki yol arasında davranış farkı doğmaz.

Kendi talep ettiği ayar değişikliğini onaylayabilir mi?

Hayır. Bu kural dört göz kuralının kendisidir ve gevşetilebilir bir ayar olmamalıdır. Aksi halde kontrolü kapatmak isteyen kişi önce dört göz kuralını kapatır, sonra istediğini yapar. Bu yüzden kendi talebini onaylama yasağı her durumda geçerlidir.