İçindekiler
Değişiklik yönetimi olgun bir kurumda bile veritabanı işi şu zinciri izler: bilet açılır, değişiklik kurulu (CAB) onaylar, bir DBA betiği çalıştırır. Zincirin ortasında sessiz bir varsayım vardır: çalıştırılan iş, onaylanan işin ta kendisidir. Bu yazı o varsayımın nerede kırıldığını ve bilet sistemi bağlantısının bunu nasıl kapatması gerektiğini anlatıyor.
Bilet Neyi Onaylar, Neyi Onaylamaz
Bilet niyeti onaylar: bu iş yapılsın mı, ne zaman, kim sorumlu. Bilette çalışacak betiğin kendisi çoğu zaman yoktur; talebi açan kişinin tarifi vardır. Üstelik onay bir andır, çalıştırma başka bir andır. Aradaki günlerde kayıt geri çekilmiş, iptal edilmiş ya da kapatılmış olabilir. Betik değişmiş olabilir. Kimse yalan söylemiyor; iki sistem birbirini görmüyor.
Doğrulama İki Noktada Yapılmalı
Birinci nokta talebin kaydedildiği andır. Girilen numara bilet sistemine sorulur: kayıt var mı, doğru türde mi, kapanmış mı. Yanlış numara burada, henüz kimse zaman harcamadan yakalanır.
İkinci nokta çalıştırma anıdır ve daha önemlidir. Aynı bilet bir kez daha sorulur ve bu sorgu önbellekten cevaplanmaz, çünkü onay kuyruğa alındıktan sonra geri çekilmiş olabilir. Değişiklik kaydı çalıştırılabilir durumda değilse iş başlamaz. Burada bir ayrıntı önemlidir: durdurulan iş ölmez. Onaylı kalır ve kayıt uygun hale gelince yeniden çalıştırılır. Aksi halde bilet sistemindeki geçici bir durum, veritabanı tarafında kalıcı bir ret gibi davranırdı.
Her Talep Türünün Bileti Farklıdır
Tek bir kural her işe uymaz. Bir betik çalıştıran değişiklik, değişiklik kaydına bağlanır ve kurul onayı aranır. Üretimden veri çıkarmak bir değişiklik değil bir istektir; hizmet talebine bağlanır ve kurul onayı aranmaz. Acil değişikliğin onayı çoğu kurumda sonradan verilir; bu yüzden kurul onayı aranmaz ama kayıt yine de var ve kapanmamış olmalıdır, ve geçen her acil çalıştırma istisna olarak yazılır. Geri alma yeni bir iş değildir; kaynak değişikliğin parçasıdır ve kaynak kayıt kapanmış olsa bile kilitlenmemelidir, çünkü üretimdeki bozulmanın düzeltilmesini engellemek daha kötüdür.
Bilet Sistemi Ulaşılamazsa Karar Ne Olmalı
Bu soru genellikle hiç sorulmaz ve gece üçte sorulur. İki dürüst cevap vardır. Birincisi işi durdurmaktır: güvenli ama bilet sistemindeki bir kesinti üretimdeki bir düzeltmeyi bekletir. İkincisi işi sürdürmek ve doğrulamanın yapılamadığını kayda geçirmektir: hız korunur, ama bu karar sessiz kalmamalı, SOC'a alarm olarak gitmelidir. Hangisinin seçileceği kurumun risk iştahına bağlıdır; yanlış olan, bu seçimin hiç yapılmamış olmasıdır. Acil taleplerde ise bilet sistemi üretimdeki bir yangını geciktirmemelidir.
Bilete Ne Yazılmalı, Ne Yazılmamalı
Entegrasyon tek yönlü olursa bilet, işin ne olduğunu bilmeden kalır. Ürün olayları bilete not olarak yazmalıdır: talep açıldı, onaylandı, çalıştırıldı, başarısız oldu. Ama notun içeriği bilinçli olarak dardır. Betik metni, sonuç verisi ve parola bilet sistemine gitmemelidir; bilet sistemleri genellikle geniş bir kitlenin okuduğu yerlerdir ve orada kişisel veri ya da sır birikmesi yeni bir risktir. Not gönderilemezse kaybolmamalı, bir sonraki turda aynı yerden devam etmelidir.
Ürün Değerlendirirken Sorulacak Altı Soru
- Bilet yalnız kayıtta mı sorgulanıyor, yoksa çalıştırma anında da mı?
- Çalıştırma anındaki sorgu önbellekten mi cevaplanıyor?
- Kayıt kapanmış ya da onaysızsa iş durduğunda talep ölüyor mu, yoksa uygun hale gelince yeniden çalışıyor mu?
- Bilet sistemi ulaşılamazken karar kimin ve hangi ayarın elinde, ve bu karar kayda geçiyor mu?
- Acil talep ve geri alma için ayrı kurallar var mı?
- Bilete yazılan notta betik metni ya da sonuç verisi bulunma ihtimali var mı?
İlk üç soru entegrasyonun gerçekten bir kapı olup olmadığını gösterir. Son üç soru, o kapının kendi başına yeni bir risk üretip üretmediğini gösterir.
SQL Change Guard tarafında
ServiceNow (Table API) ve Jira (REST v2 ve v3) için bağlayıcı vardır; başka bir bilet sistemi için genel REST tanımı yapılabilir. Bilet talep kaydedilirken ve çalıştırma anında sorulur, çalıştırma anındaki sorgu önbellek kullanmaz. Durdurulan talep onaylı kalır. Bilet sistemi ulaşılamazsa kurum işlemi durdurmayı ya da sürdürüp kayda geçirmeyi seçer; varsayılan ikincisidir ve SIEM bağlıysa bu istisna eşikten bağımsız bir olay olarak SOC'a gider. Acil talep ve geri alma için ayrı kurallar uygulanır. Olaylar bilete not olarak yazılır ve notta betik metni, sonuç verisi ve parola bulunmaz. Ürün bilet açmaz ve bilet durumunu kendisi değiştirmez. Bağlayıcılar bir laboratuvar simülatörüyle uçtan uca sınandı; kurumunuzdaki gerçek örnekle ilk kurulumda birlikte doğrulanır. Entegrasyon varsayılan olarak kapalı gelir. Ayrıntılar için entegrasyonlar sayfasına bakın.
Sık Sorulan Sorular
ServiceNow ya da Jira bileti veritabanı betiğini onaylar mı?
Hayır. Bilet niyeti onaylar: bu iş yapılsın mı. Çalışacak betik bilette durmaz, onaydan sonra da değişmiş ya da kayıt kapatılmış olabilir. Bu yüzden ürün biletin durumunu hem talep kaydedilirken hem çalıştırma anında sorar ve betiğin özetini ayrıca mühürler.
Bilet sistemine ulaşılamazsa veritabanı işi durur mu?
Kurumun seçimine bağlıdır. İki politika vardır: işlemi durdurmak, ya da işlemi sürdürüp doğrulamanın yapılamadığını kayda geçirmek ve SOC'a alarm göndermek. Varsayılan ikincisidir. Bilet sistemine ulaşılamadığında acil talep her durumda devam eder ve bu atlama kayda geçer.
Bilet sistemine ürün ne yazar?
Talep açıldı, onaylandı, reddedildi, zamanlandı, çalıştırıldı ya da başarısız oldu gibi olaylar için kısa ve sabit bir not. Notta betik metni, sonuç verisi ve parola bulunmaz.