İçindekiler
Veritabanı yönetişimi konuşmalarının çoğu aynı cümleyle başlar: "Bizde süreç var." Cümle doğrudur. Bilet sistemi vardır, onay akışı tanımlıdır, dağıtım hattı çalışır, veritabanı erişim izleme aracı satın alınmıştır, risk tabloları hazırlanmıştır, prosedürler yazılmış ve imzalanmıştır. Sorun sürecin varlığında değil, kapsamının nerede bittiğindedir. Bu yazı, iyi kurulmuş bir yönetişim yığınının cevaplayamadığı soruları tek tek gösteriyor.
Doğru Cümle, Eksik Kapsam
Kurumsal BT yığını uygulama katmanı için olgunlaşmıştır. Kod deposu vardır, kod incelemesi zorunludur, dağıtım hattı testleri çalıştırır, sürüm etiketlenir. Uygulama tarafında "üretime ne gitti" sorusunun cevabı tek bir yerde durur ve kimse bunu tartışmaz.
Veritabanı katmanında aynı olgunluk yoktur ve bunun teknik olmayan bir sebebi vardır: veritabanına dokunan iş, uygulama dağıtımı gibi tek bir kanaldan akmaz. Şema değişikliği hattan geçer; veri düzeltmesi geçmez. Yetki değişikliği hattan geçmez. Gece yapılan acil müdahale geçmez. Denetim için veri çekme isteği zaten hiçbir hattın konusu değildir. Süreç, üretime giden yolların yalnızca birini kapsar.
Kapsam testi
Geçen ay üretim veritabanınızda çalışan tüm ifadeleri düşünün. Bunların yüzde kaçı dağıtım hattından geçti? Cevap çoğu kurumda yüzde elliyi bulmaz. Geri kalanı, süreç kapsamının dışında olduğu için değil, hiçbir sürecin o yolu tarif etmemiş olması yüzünden kayıtsızdır.
Yığındaki Her Aracın Sınırı
Aşağıdaki tablo hiçbir aracın eksik olduğunu söylemiyor. Her araç kendi işini yapıyor. Tablonun amacı, hangi sorunun hangi aracın görev tanımının dışında kaldığını görünür kılmak.
| Araç | Cevapladığı soru | Görev tanımının dışında kalan |
|---|---|---|
| Bilet ve hizmet yönetimi (Jira, ServiceNow) | Ne istendi, kim istedi, kim onayladı, ne zaman kapandı | Onaylanan metnin çalışan metin olup olmadığı. Bilet bir ekten ibarettir; ek onaylandıktan sonra da düzenlenebilir ve veritabanına ne gittiğini bilet göremez. |
| Dağıtım hattı (Azure DevOps, Jenkins, GitLab) | Hangi sürüm hangi ortama gitti, hangi adım başarılı oldu | Hattın dışından üretime ulaşan iş. Hat yalnızca kendi taşıdığını bilir; taşımadığı hakkında sessizdir ve sessizliği "hiçbir şey olmadı" gibi okunur. |
| Şema göç araçları (Liquibase, Flyway, Redgate) | Şemanın sürümlenmiş hali ve ortamlar arası tutarlılığı | Planlı şema dışındaki her şey: veri düzeltmesi, yetki değişikliği, bakım işleri ve veri okuma talepleri. Bu araçlar üretim verisine bakma isteğini yönetmek için tasarlanmadı. |
| Veritabanı erişim izleme (Guardium ve benzerleri) | Ne çalıştı, hangi oturumdan, hangi saniyede, hangi tabloya | İzin kararı. Bu ürünler onay bilgisini bilet sisteminden dışarıdan alıp raporda yan yana koyabilir; onayı kendileri üretmez ve olay gerçekleşmeden durdurmaz. |
| Log platformu ve SIEM | Olayların ilişkilendirilmesi, kural tabanlı uyarı, saklama | Bir olayın izinli olup olmadığı. İzin kararı SIEM'e hiç ulaşmaz; SIEM "bu çalıştı" der, "bunun çalışması onaylanmıştı" diyemez. |
| Risk tabloları ve yazılı prosedürler | Kurumun niyeti: hangi işin nasıl yapılması gerektiği | Uygulanıp uygulanmadığı. Belge bir kontrol değil, kontrol tarifidir. Denetçi tarifi değil, tarifin işlediğinin kanıtını ister. |
Tabloyu satır satır okuyunca ortaya çıkan şey şudur: yığın "ne oldu" ve "ne istendi" sorularını iyi cevaplar. Cevapsız kalan soru, ikisini birbirine bağlayan sorudur. Olan işin istenen iş olduğunu, istenen işin de o gün yürürlükteki kurala göre onaylandığını gösteren tek bir kayıt yoktur.
Yetkisiz Değişiklik Tespitindeki Tanecik Sorunu
Bu noktada sık gelen itiraz haklıdır: modern hizmet yönetimi platformları yetkisiz değişiklik tespiti yapabilir. Bir yapılandırma öğesinde planlanmamış bir değişiklik görüldüğünde otomatik olarak kayıt açılabilir. Bu özellik gerçektir ve çalışır.
Ancak iki sınırı vardır ve ikisi de veritabanı katmanında belirleyicidir.
Birincisi kapsam. Bu mekanizmalar keşif ve hizmet haritalama üzerine kuruludur; hazır haliyle yalnızca bir uygulama hizmetine bağlanmış yapılandırma öğelerini kontrol eder. Uygulama hizmetine bağlanmamış öğeler ve yeni keşfedilip eklenen öğeler bu kapsamın dışında kalır. Kurumların çoğu bu boşluğu kapatmak için ek geliştirme yapmak zorunda kalır.
İkincisi tanecik boyutu. Yapılandırma yönetim veritabanındaki öğe genellikle sunucudur veya veritabanı örneğidir. Bir tabloya kolon eklenmesi, bir saklı yordamın gövdesinin değişmesi, bir kullanıcıya fazladan yetki verilmesi hiçbir öğe niteliğini değiştirmez. Yani en kritik veritabanı değişiklikleri, tespit mekanizmasının bakabildiği seviyenin bir kat altında gerçekleşir. Sunucu kaydı sapmadığı için hiçbir uyarı üretilmez ve rapor temiz görünür.
Sessiz temiz rapor
"Yetkisiz değişiklik tespit edilmedi" satırı iki farklı anlama gelebilir: gerçekten olmadı ya da bakılan yerde görünmüyor. İkisini ayırt etmenin tek yolu, tespitin hangi tanecik boyutunda çalıştığını sormaktır. Sunucu seviyesinde çalışan bir tespit, tablo seviyesindeki değişiklik hakkında bilgi vermez.
Yedi Soru: On Beş Dakikalık Öz Değerlendirme
Aşağıdaki soruların hiçbiri ürün sorusu değildir. Her biri kendi kayıtlarınız üzerinde bugün denenebilir. Geçen ay üretimde çalışmış rastgele bir veritabanı değişikliği seçin ve sırayla ilerleyin. Ölçüt cevabın var olması değil, dakikalar içinde gösterilebilmesidir.
| Soru | Cevap gecikirse ne anlama gelir |
|---|---|
| 1. Çalışan metnin onaylanan metinle birebir aynı olduğunu nasıl gösteriyorsunuz? | Onay bir niyete verilmiş demektir, bir metne değil. Aradaki fark denetimde kapatılamaz. |
| 2. Bu değişikliğin risk değerlendirmesi hangi gerekçeyle o seviyede belirlendi? | Değerlendirme kişisel yargıya dayanıyor demektir. Aynı betiği başka biri farklı sınıflandırır ve bu tutarsızlık denetimde bulgu üretir. |
| 3. Onaylayan kişi ile çalıştıran kişinin farklı olduğunu ne engelliyor, ne kaydediyor? | Görevler ayrılığı bir beklenti olarak yaşıyor demektir. Beklenti, kontrol yerine geçmez. |
| 4. Geçen çeyrekte kaç değişiklik talebi reddedildi ve reddedilenler nerede kayıtlı? | Reddedilen talep hiç kaydedilmiyor olabilir. Yalnız onaylananların göründüğü bir kayıt, kontrolün çalıştığını değil, yalnızca sonucu gösterir. |
| 5. Geçen ay kaç acil değişiklik yapıldı ve kaçının sonradan değerlendirmesi tamamlandı? | Acil kanalı denetimsiz bir kısayola dönüşmüş olabilir. Sonradan değerlendirme yapılmayan her acil değişiklik birikmiş bir borçtur. |
| 6. On sekiz ay önce verilmiş bir onay kararını, o tarihte yürürlükte olan kural setiyle birlikte gösterebiliyor musunuz? | Geçmiş kararın doğruluğu bugünkü kurala göre değerlendirilecek demektir. Kural o zamandan beri değiştiyse karar haksız yere hatalı görünür. |
| 7. Geçen hafta üretim verisinden dışarı çıkan kayıtları kim, hangi gerekçeyle ve hangi maskeleme kararıyla aldı? | Veri okuma tarafı hiç yönetilmiyor demektir. Değişiklik yönetiminin en olgun olduğu kurumlarda bile en büyük boşluk buradadır. |
Yedi sorunun üçüne dakikalar içinde cevap veremiyorsanız, süreciniz çalışıyor ama kanıtı üretmiyor demektir. Bu iki durum denetimde aynı sonucu doğurur.
Farkında Olmadan Taşınan Riskler
Bu boşlukların ortak özelliği sessiz olmalarıdır. Hiçbiri kesintiye yol açmaz, hiçbiri panoda kırmızı görünmez ve hiçbiri fatura üretmez. Bedeli, sorun çıktığı gün ödenir.
Kanıtlanamayan kontrol riski. Kontrol gerçekten uygulanıyor olabilir. Denetçi kontrolün uygulandığını değil, uygulandığının gösterilebildiğini arar. Gösterilemeyen kontrol, uygulanmamış kontrolle aynı bulguyu üretir. Bu, kurumların en çok şaşırdığı noktadır.
Kişiye bağımlılık riski. Bir kurumda üretim veritabanına dokunan işin doğru yapıldığını bilen kişi sayısı genellikle bir elin parmaklarını geçmez. Bu kişiler kuralları bilir, hangi tablonun kritik olduğunu bilir, hangi betiğin gece çalıştırılmaması gerektiğini bilir. Hiçbiri yazılı değildir. O kişi ayrıldığında kaybolan şey bilgi değil, kontroldür.
Sessiz kapsam kayması. Süreç kurulduğunda beş sunucu vardı. Bugün on yedi sunucu var ve yenilerinin kaçının süreç kapsamında olduğu kimsenin gündeminde değil. Kapsam listesi bir kere hazırlanıp bir daha bakılmayan bir belge olduğunda, kapsam her ay biraz daha küçülür.
Kişisel veri riski. Değişiklik tarafı olgun olan kurumlarda bile okuma tarafı yönetilmez. Bir destek kaydı için üretimden çekilen müşteri listesi, bir elektronik tablo olarak birinin bilgisayarında kalır. Kişisel Verilerin Korunması Kanunu bakımından burada üç ayrı eksik vardır: veriyi kimin hangi amaçla işlediği kayıtlı değildir, veri en aza indirilmemiştir çünkü gereğinden fazla kolon çekilmiştir ve verinin nereye gittiği bilinmediği için saklama süresi işletilemez. Bunların hiçbiri bir olay üretmez; bir ihlal bildirimi gerektiğinde ortaya çıkar ve o gün geriye dönük düzeltilemez.
Süreçten kaçan iş riski. Onay yolu yavaşsa iş durmaz, yolunu değiştirir. Bir değişikliğin onay kurulunu beklemesi üç gün sürüyorsa, üçüncü günün sonunda o değişiklik büyük ihtimalle başka bir kanaldan yapılmış olur. Bu, disiplinsizlik değil, sürecin kendi tasarımının ürettiği bir sonuçtur.
Boşluğu Kapatmanın Ucuz Yolu
Bu boşlukların hiçbiri mevcut araçların değiştirilmesini gerektirmez. Bilet sistemi yerinde kalır, dağıtım hattı yerinde kalır, izleme aracı yerinde kalır. Eksik olan tek şey, veritabanına dokunan işin geçtiği ortak bir kayıttır. O kayıt dört alanı aynı satırda taşıdığında yedi sorunun tamamı cevaplanabilir hale gelir.
Metin. Çalıştırılacak SQL'in kendisi, onay anında ve çalıştırma anında özeti alınmış olarak. İki özet eşleşmiyorsa çalıştırma başlamaz.
Değerlendirme. Riskin hangi kurallardan çıktığı, yazılı ve tekrar üretilebilir biçimde. Aynı betik yarın tekrar gönderildiğinde aynı sonucu üretmelidir.
Karar. Kimin onayladığı, hangi yetkiyle onayladığı ve o anda hangi kural setinin yürürlükte olduğu, karar anında dondurulmuş halde.
Sonuç. Ne çalıştı, kaç satır etkilendi, hata alındıysa ne yapıldı ve geri alma betiği üretildi mi.
SQL Change Guard tam olarak bu kaydı üretmek için vardır. Mevcut araçlarınızın yerine geçmez; onların cevaplayamadığı soruyu cevaplayan katmanı ekler ve bilet numarasıyla bilet sisteminize, kayıt kimliğiyle log platformunuza bağlanır.
Nereden başlanır
Tüm ortamı kapsayan bir programla değil, tek bir üretim sunucusuyla. O sunucuya giden bütün yolları tek kayda bağlayın ve bir çeyrek sonra yedi soruyu yeniden sorun. Kapsamı, tartışmayla değil bu ölçümle genişletmek çok daha kolaydır.
Sık Sorulan Sorular
Mevcut süreçlerimiz denetimlerden geçiyor. Gerçekten bir boşluk var mı?
Denetimden geçmek, boşluk olmadığını değil, o boşluğun örnekleme düşmediğini gösterir. Denetçi genellikle sınırlı sayıda değişikliği inceler ve incelediği örnekler çoğunlukla dağıtım hattından geçmiş planlı işlerdir; onların kaydı zaten temizdir. Kapsam dışı kalan yollar örnekleme girmediği sürece görünmez. Bu yüzden gerçek ölçüm denetçinin sorularıyla değil, kendi kayıtlarınız üzerinde yaptığınız rastgele bir seçimle yapılır.
Bilet sistemimize alan ve onay adımı ekleyerek bunu çözemez miyiz?
Kısmen çözersiniz. Betik alanı eklenebilir, onaylayan rolü tanımlanabilir, reddedilen talepler kaydedilebilir. Çözülemeyen kısım şudur: bilet sistemi veritabanında ne çalıştığını göremez. Onaylanan metnin çalışan metin olduğunu doğrulamak için çalıştırma anında hesaplanan bir özet ve o özeti karara bağlayan bir kapı gerekir. Bu, bir bilet sisteminin görev alanı dışındadır ve orada geliştirmeye çalışmak, bakımı size kalan bir iç ürün üretir.
Veritabanı erişim izleme ürünümüz var. Bu yeterli değil mi?
İzleme ile yönetişim aynı katman değildir. İzleme aracı olayı gördükten sonra kaydeder ve bu tespit için değerlidir. Yönetişim katmanı olay gerçekleşmeden önce karar üretir: talep açılır, risk ölçülür, onay alınır, çalıştırma o onaya bağlı olarak açılır. İkisi birbirinin alternatifi değildir; izleme aracınız yönetişim kaydıyla çapraz doğrulama için en iyi eşleşmedir. Nitekim bu ürünler onay bilgisini bilet sisteminden alıp raporlarında yan yana koyabilir; o veriyi üretmezler, dışarıdan alırlar.
Bu katman süreci yavaşlatır mı?
Yavaşlatan şey kontrol değil, her değişikliğe aynı ağırlıkta kontrol uygulamaktır. Risk bandına göre kapı kuran bir model, düşük riskli değişiklikleri hızlandırır ve yalnızca yüksek riskli olanları tam süreçten geçirir. Ölçülmesi gereken 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 kısaldığında süreçten kaçan iş de azalır.
Yatırım yapılmış araçlarımız değersizleşir mi?
Hayır. Bu katman ikame değil tamamlayıcıdır ve kurulum modeli bunu zorunlu kılar: talepler bilet numarasıyla açılır, kayıtlar log platformuna aktarılabilir, planlı şema işi göç aracınızda kalmaya devam eder. Değişen tek şey, veritabanına dokunan işin artık kayıt bırakmadan geçebileceği bir yolun kalmamasıdır.
Yedi soruyu birlikte geçelim
Kendi senaryonuzu getirin; talep açılışından mühürlü kanıt dosyasına kadar akışı canlı gösterelim ve boşlukları birlikte işaretleyelim.
Demo Planlayın →