Rollere göre

Her rolün kendi sorusu

Bir üretim değişikliğine CIO, CTO, güvenlik, veritabanı ekibi, altyapı, değişiklik yönetimi ve iç denetim farklı yerden bakar. Her rolün sorusu, bugün nasıl cevaplandığı ve ürünün neyi değiştirdiği aşağıda.

CIO · IT Director

Yönetim kuruluna "veritabanı tarafında kontrol var" derken neye dayanıyorsunuz?

Cevap büyük ihtimalle doğru. Sorun cevabın doğruluğu değil, neye dayandığı.

Bugün bu soru nasıl cevaplanıyor

Ekibinize soruyorsunuz. "Kontrol var" cevabını alıyorsunuz. Bu cevap dürüst ve büyük olasılıkla doğru.

Ama o cevap bir sistemin çıktısı değil, bir kişinin bilgisidir. Aynı soruyu altı ay sonra, o kişi ekipte değilken sorduğunuzda aynı güveni alamazsınız.

Yönetim kuruluna verdiğiniz taahhüt, sizin göremediğiniz bir yerde duruyor.

Bu cevabın maliyeti

Her denetim öncesi kaybedilen iki hafta. Bu süre hiçbir projeye yazılmaz, hiçbir raporda görünmez.
Kilit bir kişinin ayrılmasıyla kaybolan güven. Yeni kişi aynı cevabı veremez, çünkü cevap sistemde değildi.
Bir olay yaşandığında, kontrolün o gün çalıştığını gösterememek. Kontrol çalışmış olabilir; kanıtı yoktur.
Aynı riskin farklı kişilerce farklı değerlendirilmesi. İkisi de savunulabilir, ikisi de kayıtsız.

Ürünle ne değişir

Yönetişim yeni bir süreç icat etmez. Var olan iyi süreçleri kişilere bağımlı olmaktan çıkarır.

Bir değişikliğin hangi kurala göre onaylandığı, o günün kuralıyla birlikte kaydın içinde durur. Kural sonradan değişse bile eski kayıt kendi günündeki kuralla okunur.

Böylece yönetim kuruluna verdiğiniz cevap bir kişinin hafızasına değil, doğrulanabilir bir kayda dayanır.

Yönetim kuruluna "veritabanı tarafında kontrol var" derken neye dayandığınız belli olur.

CTO · DevOps Manager

Hızı yavaşlatmadan kontrolü nasıl eklersiniz?

Ekibiniz "governance" kelimesini duyduğunda yavaşlama anlıyorsa, bugüne kadar gördüğü yönetişim gerçekten yavaşlatmıştır.

Bugün bu soru nasıl cevaplanıyor

Kontrol eklemek pratikte onay adımı eklemek demek. Onay adımı eklemek beklemek demek. Beklemek de takımın hızını düşürmek demek.

Bu denklem doğru olduğu için iki sonuçtan biri oluyor: ya kontrol hiç eklenmiyor, ya da eklendikten sonra acil durumlarda atlanıyor. İkisi de anlaşılabilir.

Sonuçta iş üretime ulaşıyor ama bir kısmı hattın dışından ulaşıyor. Hattın dışı, ölçtüğünüz hiçbir metrikte görünmüyor.

Bu cevabın maliyeti

Hattınızın kapsama oranını bilmiyorsunuz. Üretime giden işin ne kadarı hattan geçiyor, ölçülmüyor.
Aynı riskteki iki değişiklik, farklı kişilerin elinde farklı muamele görüyor. Bu tutarsızlık kimseye hata olarak görünmüyor.
Düşük riskli değişiklikler yüksek riskli olanlarla aynı onay yükünü taşıyor. Sonuçta iki taraf da mutsuz.
Bir olaydan sonra "bu neden hattan geçmedi" sorusunun cevabı yeniden inşa ediliyor.

Ürünle ne değişir

Ayrım noktası şu: her değişikliğe aynı onay yükünü vermemek. Dağıtım hattıyla doğrudan bağlantı bugün üründe yok ve yol haritasının ilk sırasında; bugün kazanılan, hattın dışından giden işin ve elle yapılan işin aynı kural ve kayıt modeline girmesidir.

Riski düşük bir değişikliğin onay adımları politikayla azaltılabilir. Riski yüksek olan durur ve bunun sebebi kaydın içinde yazılıdır. Kararı veren kural, kişi değil.

Hattın dışından yapılan müdahale de aynı kapsama alınabilir. Bu bir yasak değildir; elle müdahale operasyonel bir gerçektir. Değişen şey, o müdahalenin acil durum veya elle işlem olarak beyan edilmesi ve gerekçesiyle birlikte aynı kayıt modeline girmesidir.

Bunun sınırını açıkça söyleyelim: platform, hiç beyan edilmemiş bir müdahaleyi kendiliğinden tespit etmez. Kazanç, gece yapılan işin hiçbir yere yazılmaması ile gerekçeli bir kayda dönüşmesi arasındaki farktır.

Hız kontrolle takas edilmez; onay yükü riske göre ayarlanır ve hattın dışına çıkan işin de aynı kayıt modelinde yeri olur.

CISO · Compliance Manager

Üretim verisine erişim, kimlik yönetimi kadar ciddiye alınıyor mu?

Kimlik tarafınız muhtemelen olgun. Boşluk yetkisiz erişimde değil, yetkili kişinin kuralsız işleminde.

Bugün bu soru nasıl cevaplanıyor

Kimlik yönetimi yerinde. Yetkiler tanımlı, erişim gözden geçiriliyor, ayrıcalıklı hesaplar izleniyor.

Sonra bir yönetici bir veri istiyor. Yetkili bir kişi, izinli bir sorgu çalıştırıyor, sonucu bir dosyaya alıp gönderiyor. Hiçbir kural ihlal edilmiyor.

Bu işlemde kimin hangi gerekçeyle hangi veriyi aldığı, hangi alanların açık gittiği ve dosyanın nereye ulaştığı hiçbir yerde birlikte durmuyor.

Bu cevabın maliyeti

Kişisel veriye erişimin izi sonradan inşa ediliyor. İnşa edilen iz, kanıt değildir.
Maskeleme kararı kişiye kalıyor. Aynı kolon bir teslimde maskeli, diğerinde açık gidebiliyor.
Veri kurum dışına çıktığında, hangi adrese gittiğinin onaylandığını gösterecek bir kayıt yok.
Bir olay incelemesinde kapsam belirlenemiyor: kimin neyi gördüğü bilinmiyorsa etki de bilinemiyor.

Ürünle ne değişir

Üretim verisi okuma işlemi, değişiklik kadar ciddi bir işlem olarak ele alınır: talep, gerekçe, onay ve teslim tek kayıtta durur.

Hangi alanın maskeleneceği kişinin kararı olmaktan çıkar, kuralın kararı olur. Bir alan açık gidecekse bunun onayı ayrıca kayda geçer.

Kanıt sonradan toplanmaz. Teslimin kendisi kaydı üretir ve bu kayıt, kaydı tutan sistemin dışından doğrulanabilir. Bunun için kurulumda imza anahtarının ve dış özet deposunun tanımlı olması gerekir; imzasız pakette doğrulama betiği sonuca UNSIGNED yazar.

Üretim verisine erişim kimlik yönetimi kadar ciddiye alınır ve kişisel veriye erişimin izi kendiliğinden oluşur.

Database Director · Database Manager · Senior DBA

Ekibinizin bilgisi kimde duruyor?

Bu sayfa ekibi eleştirmek için yazılmadı. Tam tersi: iyi çalışan bir ekibin bilgisinin neden kırılgan olduğu üzerine.

Bugün bu soru nasıl cevaplanıyor

Sürüm sırasını biri biliyor. Hangi tabloya mesai saatinde dokunulmayacağını biri biliyor. Hangi işin hangi sırayla çalışması gerektiğini biri biliyor.

Bu bilgi yanlış değil. Aksine, yılların tecrübesiyle oluşmuş ve çoğu zaman yazılı bir kuraldan daha isabetli.

Sorun şu: bu bilgi devredilemiyor. Bir belgeye yazıldığında inceliğini kaybediyor, yazılmadığında ise kişiyle birlikte gidiyor.

Bu cevabın maliyeti

En kıdemli kişi rahat izne çıkamaz. Çıktığında sürüm ertelenir veya risk alınır.
Gece 02:10'da yazılan geri alma betiği. O gece çalıştı; bir dahaki sefere çalışacağının garantisi yok.
Yeni katılan kişinin altı ay boyunca soru sorarak öğrenmesi. Bu süre kimsenin planında yoktur.
Denetimde "bu işi neden böyle yaptınız" sorusuna verilen cevabın kişisel tecrübeye dayanması.

Ürünle ne değişir

Yönetişim, ekibin tecrübesini yok saymaz. Onu sistemin kuralına çevirir. Sürüm sırası bir kişinin ekranında değil, tanımın içindedir.

Geri alma değişiklikle birlikte hazırlanır. Yapı değişikliklerinde ürün sunucudaki güncel tanımdan ters betiği üretir; veri değiştiren ifadelerde betiği ekip yazar ve ürün eksik geri almayı işaretler. Gece yazılan bir betik olmaktan çıkar, planın parçası olur.

Riskin nasıl değerlendirileceği kişiye göre değişmez. Aynı betik, aynı koşullarda, her seferinde aynı sonucu alır.

Ekibin bilgisi kişilerden sisteme taşınır, gece müdahalesi doğaçlama olmaktan çıkar ve tatildeyken aranma ihtimaliniz azalır.

Infrastructure Manager

Hangi sunucuda ne değişti, tek yerden okunuyor mu?

Ortam sayısı arttıkça sorun kapasite değil, görünürlük oluyor.

Bugün bu soru nasıl cevaplanıyor

Her sunucunun kendi kaydı var. Bazılarında izleme aracı, bazılarında sistem logu, bazılarında sadece yedek geçmişi.

"Bu değişiklik hangi sunucuya gitti" sorusunu cevaplamak için birden fazla yere bakmak gerekiyor. Cevap genellikle bulunuyor, ama zaman alıyor.

Ortamlar zamanla birbirinden ayrışıyor. Test ile üretimin farkı, kimsenin planlamadığı küçük müdahalelerle büyüyor.

Bu cevabın maliyeti

Ortam sapması. Testte çalışan bir değişikliğin üretimde çalışmama sebebi çoğu zaman budur.
Bir talebin birden fazla sunucuya gitmesi durumunda hangisinde başarılı olduğunun ayrı ayrı takip edilmesi.
Bir sunucunun yönetişim kapsamı dışında kalması. Genelde en eski ve en kritik olan sunucudur.
Yetki ve rol değişikliklerinin değişiklik sayılmaması. Kayıtta görünmez, denetimde sorulur.

Ürünle ne değişir

Sunucu, yönetişimin bir parametresi olur. Sorgu sonucu talebi birden fazla sunucuya gidebilir ve her sunucunun sonucu ayrı kayıtlıdır; değişiklik talebi tek sunucuya gider, çünkü sunucular arasında ortak transaction yoktur.

Kapsam listesi sekiz yolu içerir ve bu listede yetki değişikliği ile bakım işleri de vardır. Bunlar çoğu kurumda kapsam dışıdır.

Nesne geçmişi, bir nesneye ürün üzerinden dokunan bütün talepleri gösterir. "Sunucudaki güncel tanım" karşılaştırması ise nesnenin hedefteki o anki halini okur; ürünün dışından yapılmış bir değişiklik bu güncel tanımda okunabilir, ancak ürün bunu kendiliğinden tespit etmez.

Ürün üzerinden hangi sunucuda neyin değiştiği tek yerden okunur. Ürün yalnız kendisine tanımlı sunucuları bilir; kapsamın tamamlığı, kurumun sunucu envanteriyle ürünün sunucu listesinin karşılaştırılmasıyla gösterilir.

Yetkinin durduğu iki ekran

Rol yetkileri ekranı: talep, onay, çalıştırma, görünürlük ve ayar yönetimi yetkilerinin rol bazında açılıp kapatılması
Roller ve yetkiler Talep açma, onaylama, çalıştırma ve ayar yönetimi rol bazında açılır kapanır. Kontrol arayüzde değil sunucuda uygulanır.
Kullanıcılar ekranı: rol ataması, yerel veya kurumsal dizin ile kimlik doğrulama ve CSV ile toplu kullanıcı aktarımı
Kullanıcılar ve toplu aktarım Yerel hesap veya kurumsal dizin. Kurulumda ekibin tamamı CSV ile aktarılır, tek tek eklemeyle aynı kontrollerden geçer.

Change Manager

Bilette yazan ile veritabanında olan aynı mı?

Değişiklik süreciniz muhtemelen olgun. Boşluk süreçte değil, sürecin çıktısı ile gerçeğin arasında.

Bugün bu soru nasıl cevaplanıyor

Bilet açılıyor, onay alınıyor, uygulama penceresi belirleniyor, bilet kapanıyor. Süreç düzgün işliyor.

Bilet kapandığında değişikliğin uygulandığı varsayılıyor. Bu varsayımın kaynağı, uygulayan kişinin beyanı.

Bilette yazan ile veritabanında gerçekleşen arasında bir eşleştirme yok. İkisi ayrı sistemlerde ve birbirini tanımıyor.

Bu cevabın maliyeti

Kapanmış bilet, yarım kalmış değişiklik. Üç hafta sonra fark ediliyor ve kimse ilk hatayı bulamıyor.
Bileti olmayan değişiklik. Acil durumda yapılıyor, sonradan bilet açılıyor, ama içerik gerçeği tam yansıtmıyor.
Denetimde bilet ile kayıt arasındaki farkın açıklanamaması. İkisi de doğru görünüyor, ikisi birbirini tutmuyor.
Aynı nesneye dokunan iki açık talebin birbirinden habersiz ilerlemesi.

Ürünle ne değişir

Bilet numarası talebin bir alanı olmaktan çıkar, kaydın bağlayıcı unsuru olur. Bilet zorunluysa biletsiz talep açılmaz; biçimi tanımlıysa yanlış biçim kabul edilmez.

Betiğin hangi nesnelere ne yaptığı ayrıştırma sonucundan nesne listesi olarak okunur ve talebe, dolayısıyla bilet numarasına bağlanır. Bilet ile ürün üzerinden çalışan iş arasındaki bağ böylece kayıtta durur.

Aynı nesneye dokunan açık talepler "Active Conflicts" raporunda listelenir. Çakışma üretime ulaşmadan görünür.

Bilet ile ürün üzerinden çalışan iş arasındaki bağ kayıtta durur ve sonradan kurulmaz.

İç Denetçi

Kanıtı istiyor musunuz, yoksa indiriyor musunuz?

Kanıtı denetlenen taraf topluyorsa, aldığınız şey kanıt değil seçkidir.

Bugün bu soru nasıl cevaplanıyor

Denetim planı çıkıyor, örneklem belirleniyor, ilgili ekipten kanıt isteniyor. Ekip topluyor, siz bekliyorsunuz.

Gelen dosyalar ekran görüntüsü, e-posta çıktısı ve elle hazırlanmış tablolardan oluşuyor. Hepsi doğru olabilir. Hiçbiri bağımsız değil.

Örneklem küçük tutuluyor, çünkü her kalem için kanıt toplamak ekibin haftasını alıyor. Küçük örneklem, dar güvence demek.

Bu cevabın maliyeti

Bağımsızlık zedeleniyor. Kanıtı denetlenen taraf seçiyor, siz seçilmiş olanı inceliyorsunuz.
Kural değişmişse eski kayıt yanlış okunuyor. Bugünün kuralıyla dünün işlemi değerlendirilemez.
Atlanan onay adımının gerekçesi yoksa, istisnanın meşru olup olmadığı belirlenemiyor.
Bulgu yazmak zorunda kalıyorsunuz, çünkü kontrolün çalıştığını gösteren bir kayıt yok. Kontrol çalışmış olabilir.

Ürünle ne değişir

Kanıt sonradan toplanmaz. İşlemin kendisi kanıtı üretir. Bu, denetlenen tarafın iş yükünü de azaltır; iki taraf da kazanır.

Her kayıt, o gün yürürlükte olan kural setini taşır. Kural sonradan değişse bile eski işlem kendi günündeki kuralla okunur.

Atlanan her adım gerekçesiyle kayıtlıdır. İstisna görünmez olmaktan çıkar, incelenebilir hale gelir.

Denetim dosyası, kaydı tutan sistemden bağımsız olarak doğrulanabilir. Doğrulamayı siz yaparsınız, size yapılmaz. Bunun için kurulumda imza anahtarının ve dış özet deposunun tanımlı olması gerekir; imzasız pakette doğrulama betiği sonuca UNSIGNED yazar.

Denetçi hesabıyla talep dosyalarını ve dönem paketini kendiniz indirirsiniz; örneklemi siz seçersiniz. Bağımsız doğrulama için kurumdan açık anahtar parmak izini, dış depodaki özet dosyalarını ve geri yüklenmiş bir kopyayı istersiniz.

Doğrulamayı nasıl yaparsınız

Yukarıdaki cümlenin karşılığı olmadan bir anlamı yok, o yüzden açıkça yazıyoruz. Size teslim edilen her paket bir zip dosyasıdır ve içinde şunlar bulunur: verinin kendisi, paketteki her dosyanın SHA-256 özetini listeleyen bir künye, bir doğrulama betiği ve imza anahtarı tanımlı kurulumda o künyenin RSA imzası ile imzayı doğrulayan açık anahtar.

Paket doğrulaması sizin makinenizde çalışır. Ürüne bağlanmaz, ağa çıkmaz. Windows ile gelen PowerShell ya da openssl yeterlidir.

Kayıtların kendisi ise SQL Server 2022'nin append-only ledger tablosunda durur. Defter özeti varsayılan olarak saatte bir alınır; imza anahtarı ve dış depo klasörü tanımlı kurulumda imzalanıp kurumun kendi değiştirilemez deposuna yazılır. Bu iki ayar yapılmamışsa dışarıda karşılaştırılacak özet yoktur ve doğrulama bağımsız olmaz. Kurumun kendi ortamında bir yedekten geri yüklenen kopyada SQL Server'ın kendi yordamını bu özetlere karşı siz çalıştırırsınız ya da çalıştırılmasını izlersiniz; yedek kurumdan çıkmaz. Aynı kopyada her kaydı hangi veritabanı hesabının yazdığını da görürsünüz. Dönem paketi ise dönemin bütün taleplerini iki ayrı kaynaktan uzlaştırır, böylece "hepsini gördüm mü" sorusunun da cevabı olur.

Kendi kurumunuzu konuşalım

Rolünüzün sorusunu kendi ortamınızda cevaplayan sınırlı kapsamlı bir pilot.