Acil Veritabanı Değişikliği: Hızlı Ama Kontrollü

Saat gece yarısını geçmiş, üretimde bir tablo kilitlenmiş ve çağrı merkezine şikayet yağıyor. Düzeltme tek satırlık bir SQL. Normal onay akışı iki kişinin onayını istiyor, ikisi de uyuyor. Bu noktada iki seçenek varmış gibi görünür: süreci bekletmek ya da süreci atlamak. Çoğu kurumda ikincisi seçilir, ertesi gün de bir bilet geriye dönük açılır.

Asıl sorun o gece yapılan işlem değildir. Sorun, kurumun acil durum için önceden tanımlanmış bir yolunun olmamasıdır. Yol yoksa herkes kendi yolunu açar ve o yol kayıt bırakmaz.

Gece Yarısı Kararı

Geriye dönük açılan biletin bir maliyeti vardır ve bu maliyet olay sırasında değil, aylar sonra ortaya çıkar. Denetim sırasında o değişiklik için sorulan sorular şunlardır: değişiklik ne zaman yapıldı, bilet ne zaman açıldı, aradaki fark neden var, o sırada kim yetkiliydi, ve yapılan iş gerçekten acil miydi?

Bu soruların hiçbiri teknik değildir. Hepsi yönetişim sorularıdır ve cevapları olayın kendisinde değil, olaydan önce yapılan hazırlıkta saklıdır.

Acil Değişiklik Onay Atlamak Değildir

Acil değişiklik denince akla gelen ilk model "kontrolleri kapat" olur. Doğru model bu değildir. ITIL'in acil değişiklik tanımı da kontrolü kaldırmaz; değerlendirme ve yetkilendirmenin hızlandırılmış bir biçimde yapılmasını tarif eder. Bilgi güvenliği tarafında da benzer bir mantık vardır: acil erişim, kaydı tutulan ve sonradan gözden geçirilen bir yoldur.

Doğru zihinsel model ikisinin ortasındadır:

Aradaki farkı somutlaştırmak gerekirse:

Acil Yolun Tasarımı

Acil yolu tasarlarken cevaplanması gereken dört soru vardır. Dördü de olaydan önce cevaplanmalıdır; olay sırasında tartışılan bir kural kural değildir.

1. Acil yol ayrı bir politika mıdır?

Olmalıdır. Normal politikayı olay anında düzenlemek, kontrolü kontrolsüz biçimde değiştirmek demektir. Acil yol kendi politikası olarak önceden tanımlanır, hangi sunucu ve hangi talep tipi için geçerli olduğu yazılır ve olay anında yalnızca seçilir.

2. Kaç onay kalır?

Sıfır olmamalıdır. Acil yolun anlamı, dört onayı bire indirmektir; biri sıfıra indirmek değil. Kalan adım atlanamaz olarak işaretlenmelidir, yoksa uygulama koşulları uygun bulduğunda onu da geçer ve elinizde onaysız bir üretim değişikliği kalır.

Kalan tek adımı kimin kapatacağı da düşünülmelidir. Nöbetçi listesi olan kurumlarda bu adım nöbetçi rolüne bağlanır. Nöbet yoksa acil yol pratikte çalışmaz ve ekip yine süreci atlar.

3. Doğrulama ve risk değerlendirmesi kalır mı?

Kalmalıdır, çünkü maliyeti yoktur. Betiğin ayrıştırılması ve kural kontrolü saniyeler sürer; acil durumda kaybedilen zaman onay bekleme süresidir, doğrulama süresi değil. Gece yarısı yazılan bir düzeltmede filtresiz bir UPDATE ihtimali normal bir günden yüksektir. Kontrolün en çok gerektiği an tam olarak o andır.

4. Gerekçe ve olay kaydı zorunlu mudur?

Zorunlu olmalıdır. Acil durum ilan eden kişi neden acil olduğunu ve hangi olaya bağlı olduğunu yazmalıdır. Bu alan iki işe yarar: olaydan sonraki gözden geçirmeyi mümkün kılar, ve acil yolun kolaycılığa dönüşmesini engeller. Serbest metin bir alan bile caydırıcıdır.

Acil Durumu Kim İlan Edebilir?

Bu, acil değişiklik tasarımının en çok atlanan sorusudur. Acil durum ilan etmek bir işlem değil, bir yetkidir. Herkes acil diyebiliyorsa acil yol kısa yola dönüşür ve birkaç ay içinde normal yol terk edilir.

Pratik yaklaşım, ilan yetkisini bir rol seviyesine bağlamaktır. Talep sahibi acil bir ihtiyaç görebilir, ama acil durumu ilan etme yetkisi ekip liderinde veya nöbetçi yöneticide olur. Bu eşik kurumun büyüklüğüne göre ayarlanır; küçük ekiplerde daha düşük, büyük kurumlarda daha yüksek tutulur.

Olaydan Sonra Yapılması Gerekenler

Acil yolun kontrollü sayılması, olaydan sonra bir gözden geçirme yapılmasına bağlıdır. Bu gözden geçirme uzun olmak zorunda değildir; düzenli olması yeterlidir.

Dördüncü madde çoğu zaman en zorudur, çünkü acil bir gecede betikler hızlı düzenlenir. Çalıştırma anında betiğin içerik özetinin kaydedilmesi bu soruyu sonradan cevaplanabilir hale getirir; konuyu çalıştırılan SQL onaylanan SQL miydi yazısında ele aldık.

Acil Yolun Sağlığını Ölçmek

Acil yol iyi tasarlanmışsa ölçülebilir. Üç sayı yeterlidir ve üçü de kurumun kendi kayıtlarından çıkar.

• Acil değişikliklerin toplam içindeki payı. Bu oran yükseliyorsa sorun acil durumlarda değil, normal yolun yavaşlığındadır. Çözüm acil yolu kısıtlamak değil, normal yolu hızlandırmaktır.
• Aynı sistemde tekrarlayan acil değişiklikler. Bir sistem her ay acil müdahale görüyorsa orada bir yapısal sorun vardır ve acil yol onu gizliyordur.
• Gözden geçirilmemiş acil değişiklik sayısı. Bu sayının sıfırdan farklı olması, acil yolun kontrollü olma iddiasını zayıflatır.

Sık Sorulan Sorular

Acil değişiklik ile break glass erişimi aynı şey mi?

Aynı değildir. Break glass, normalde kimsede olmayan bir yetkinin geçici olarak açılmasıdır ve erişim yönetimiyle ilgilidir. Acil değişiklik ise yapılacak işin onay yolunun kısaltılmasıdır ve değişiklik yönetimiyle ilgilidir. Bir kurumda ikisi birlikte de bulunabilir: acil erişimle açılan bir oturumda yapılan iş yine bir acil değişiklik talebine bağlanmalıdır.

Acil değişiklikte onay tamamen kaldırılabilir mi?

Teknik olarak kaldırılabilir ama o zaman yaptığınız şey acil değişiklik değil, kayıtlı bir kontrolsüz müdahaledir. Denetim açısından tek onaylı bir acil değişiklik ile onaysız bir değişiklik arasındaki fark büyüktür. En az bir kilitli adımın kalması önerilir.

Acil yolun kötüye kullanılmasını nasıl engelleriz?

Üç kaldıraç işe yarar: ilan yetkisini bir rol eşiğine bağlamak, gerekçe ve olay bileti alanlarını zorunlu tutmak, ve acil değişikliklerin oranını düzenli olarak raporlamak. Yasak koymak yerine görünür kılmak daha iyi sonuç verir.

Acil değişiklik için geri alma planı hazırlamaya vakit var mı?

Geri alma planının üretimi elle yazmaktan hızlıdır, ama her değişiklik tam olarak geri alınamaz. Veri değiştiren işlemlerde geri dönüş çoğu zaman yedeğe ve zaman aralığına bağlıdır. Acil bir gecede en gerçekçi yaklaşım, geri alma planının kapsamını önceden bilmek ve neyin geri alınamayacağını kabul etmektir. Bu konuyu SQL rollback stratejisi yazısında ayrıntılandırdık.