"Prevention İstemiyoruz" Diyen DBA'ya: Kontrol Külfet mi, Alibi mi?

Bu yazı bir DBA'ya yazıldı: bu işi en iyi bilen ve bu tür ürünlere en haklı şüpheyle bakan kişiye. Şüpheniz meşru. "Yeni bir onay katmanı daha" cümlesini çok duydunuz. Çoğu zaman bu, işinizi yavaşlatan, gece 02:00'de acil bir işte engel olan ve sonunda kimsenin bakmadığı bir formla sonuçlandı. Bu yazıda şunu savunuyoruz: yönetişim katmanı doğru kurulursa DBA'nın düşmanı değil, sigortasıdır.

Önce İtirazı Dürüstçe Yazalım

• "Prevention istemiyoruz. Biz ne yaptığımızı biliriz."
• "Bu bir külfet. Her işi bir talebe çevirmek zaman kaybı."
• "Prod'da zaten kimsenin yetkisi yok, bizim kontrolümüz var."
• "Veritabanı izleme aracımız zaten uyarı üretiyor."

Bu itirazların hepsinde bir doğruluk payı var. Ve bir şeyi kaçırıyorlar.

Engel ile Kanıt Farklı Şeylerdir

"Prevention istemiyoruz" cümlesi bir engelleme ürününe verilmiş doğru bir cevap. DBA kontrolünde yapılan bir işlemde bir aracın işi yarıda kesmesi çoğu zaman kesilmeyen işten daha zararlıdır. Ama yönetişim katmanı engelleyici bir araç olmak zorunda değil. Önemli olan ikinci sorudur: bir şey ters gittiğinde ne olur?

Bir şey ters gittiğinde hep aynı soru sorulur: kim yaptı, kim izin verdi, hangi komutu çalıştırdı? İyi bir DBA'nın bu soruya cevabı vardır, çünkü hatırlar. Ama hatırlamak kanıt değildir. Ve tam bu noktada, kayıtsız bir sistemde en çok zarar gören kişi DBA'dır: en çok yetkisi olan kişi, en kolay suçlanabilen kişidir.

Alibi: Kanıtın DBA'yı Koruduğu An

Bir düşünce deneyi yapalım. Sabah 08:30'da bir müşteri şikâyeti geliyor: dün geceki bir işlemden sonra bazı kayıtlar bozulmuş.

• Kayıtsız dünyada: "Dün gece kim çalıştırdı?" DBA çalıştırdı. "Kim onayladı?" Sözlü olarak yöneticisi. "Hangi komut?" DBA hatırlıyor. Sonuç: bir tartışma ve DBA'nın sözü.
• Kayıtlı dünyada: talep 14:12'de açıldı, gerekçesi yazılı; risk bandı Orta, iki kişi onayladı; çalıştırılan metnin özeti onaylanan metinle aynı; geri alma planı hazırdı; 2.340 satır etkilendi. Bozulan kayıtların kaynağı bu iş değildi.

Bu bir düşünce deneyidir, gerçek bir kayıt değildir. Ama sonuç gerçek: kanıt, olay sonrası DBA'yı koruyan tek şeydir. Bir kod barındırma hizmetinin 2017'deki olayında bir mühendis yanlış sunucuda bir komut çalıştırdı. Şirketin olay sonrası raporu mühendisin adını yazmadı; yaklaşımı "kimin hatası" yerine "hangi kapı yoktu" sorusuna odaklanmaktı. Sağlıklı bir kültür bunu yapar. Ama bu kültür, kayıt olmadan kurulamaz.

"Külfet" İtirazı: En Haklı Olduğu Yer

Gecikme gerçek bir maliyettir. Bunu kabul etmeden bir yönetişim ürünü savunmak dürüst değil. Külfeti iki şey belirler:

1. Her iş aynı ağırlıkta mı kontrol ediliyor? Yavaşlatan şey kontrol değil, her değişikliğe aynı derinlikte kontrol uygulamaktır. Onay politikasıyla derinlik banda göre ayarlanabilir: düşük bantta tek onay tanımlanabilir, yüksek bantta daha çok kişinin onayı istenebilir. Bir sütun açıklamasını güncellemek ile üretim tablosunu silmek aynı süreçten geçmez.
2. Ölçülen şey ne? Önemli sayı onay adımı sayısı değil, talebin açılışından çalıştırılmasına kadar geçen süredir. Bu süre uzunsa bir politika yanlış kurulmuş demektir ve bu görünür bir rakamdır.

Gece 02:00: Acil Yol

"Gece bir yangın çıktığında onay toplayacak mıyız?" sorusu haklı. Acil yol bu yüzden vardır. Acil bir talep gerekçe ister (olay numarası kurum ayarıyla zorunlu tutulabilir); onay adımlarını kısaltır ama atlamaz. Ertesi gün gözden geçirme bekler; gözden geçirilmeyen acil talepler raporda ayrıca görünür. Sonuç: gece işi yapılır, ama sabah "neden, kim, gerekli miydi" sorusu bir kez cevaplanır ve kapanır. Bu DBA için ikinci bir avantajdır: acil müdahalenin gerekliliği yazılı hale gelir. "Bunu neden gece yaptın?" sorusunun cevabı bir kayıttır.

"Zaten Bir İzleme Aracımız Var"

Veritabanı etkinlik izleme araçları iyi işler yapar: trafiği görürler, kural üretirler, alarm verirler. Bu bir yönetişim değil, bir gözlem katmanıdır. Gözlem araçları çalıştırılan komutu görür, niyeti bilmez; "bu işlem onaylı mıydı" sorusunu cevaplayamazlar. İki katman birbirinin yerine geçmez; birlikte çalıştıklarında en güçlüdürler: gözlem her şeyi görür, yönetişim hangisinin izinli olduğunu bilir.

Ne Değişir, Ne Değişmez?

• Değişmeyenler: metni yine sizin yazdığınız SQL, karar yine sizin (hangi yöntem, hangi sırayla), yürütme yine sizin kontrolünüzde: zamanlayabilir, sandbox'ta deneyebilirsiniz.
• Değişenler: işin gerekçesi ve onayı bir talepte durur. Geri alma planı çalıştırmadan önce hazırdır (kurum "geri alma zorunlu" kuralını açtığında zorunlu olur); bu "keşke yedeği kontrol etseydim" anlarını azaltır. Bir sorun çıkarsa kanıt hazırdır.
• Görev ayrılığı: kurum görev ayrılığı kurallarını açtığında kendi talebinizi kendiniz çalıştıramazsınız. Bu bir güvensizlik değil; ekibin en yetkili kişisinin bile aynı kurala tabi olduğunu göstermesi bakımından sizi korur. Kurallar kapalıysa Kurulum Kontrolü ekranı uyarır ve denetim dosyası bunu istisna olarak gösterir.

Dürüst Sınırlar

• Ürün gecikme ekler. Bir talebin açılması, onayı ve çalıştırılması doğrudan çalıştırmaktan uzundur. Risk bandına bağlı onay derinliği ve acil yol bunu azaltır, sıfırlamaz.
• Ürün bir engelleyici değildir. Veritabanına başka bir yoldan bağlanmayı engellemez. Bunu izlemek DAM ve SIEM'in işidir.
• Ekibin benimsemesi gerekir. En iyi kurulmuş süreç, DBA'lar "bu bizi yavaşlatıyor" diye atladığında değersizdir. Bu yüzden politika DBA'larla birlikte kurulmalıdır, DBA'lara karşı değil.

Üçüncü soru en önemlisi: bu araç er ya da geç kurumunuza gelecek. Onu sizin kurallarınızla mı, yoksa sizin bilginiz olmadan mı kuracaksınız?

Sık Sorulan Sorular

Yönetişim aracı DBA'yı yavaşlatır mı?

Evet, bir talebin açılması ve onayı doğrudan çalıştırmaktan uzundur. Onay politikasıyla derinlik banda göre ayarlanabilir, acil yol süreyi kısaltır; ama gecikme sıfırlanmaz. Önemli ölçüt talebin açılışından çalıştırmaya geçen süredir ve bu görünür bir rakamdır.

Gece 02:00'de acil bir iş için onay toplamak gerekir mi?

Acil talep gerekçe ister (olay numarası kurum ayarıyla zorunlu tutulabilir), onay adımlarını kısaltır ama atlamaz; ertesi gün gözden geçirme bekler ve gözden geçirilmeyenler raporda görünür. Böylece gece iş yapılır ve sabah "neden, kim, gerekli miydi" sorusu bir kez cevaplanıp kapanır.

Veritabanı izleme aracımız varsa yönetişim gerekir mi?

İkisi birbirinin yerine geçmez. İzleme aracı çalıştırılan komutu görür ama onaylı olup olmadığını bilmez. Yönetişim katmanı izinli olanı bilir. Birlikte çalıştıklarında en güçlüdürler.