Kesintilerin Yarısından Fazlası Değişiklikten Geliyor

Betik incelendi, onaylandı, bakım penceresinde çalıştırıldı. On dakika sonra uygulama yanıt vermemeye başladı. Betikte bir hata yoktu; yaptığı iş doğruydu. Sorun, o işi yaparken tabloyu ne kadar süre kilitlediğiydi. Bu yazı, onay sürecinin çoğu zaman sormadığı soruyu ele alıyor: bu betik doğru işi yapıyor da, yaparken üretimi ayakta bırakıyor mu?

Bilinen Ama Kullanılmayan Sayı

Bilgi teknolojileri yönetiminde uzun süredir tekrarlanan bir bulgu var: kritik hizmetleri etkileyen plansız kesintilerin yarısından fazlası, doğrudan değişiklik, yapılandırma veya sürüm yönetimi kaynaklıdır. Büyük ölçekli sistem işleten kurumların kendi yayımladığı rakamlar daha da yüksektir; canlı sistemlerdeki kesintilerin yaklaşık yüzde yetmişinin bir değişiklikten kaynaklandığı bildirilmiştir.

Bu sayının ilginç tarafı, herkesin bilmesine rağmen kurum içinde nadiren ölçülmesidir. Kesinti sayısı ölçülür, çözüm süresi ölçülür, hizmet seviyesi ölçülür. "Bu kesintiye bir değişiklik mi sebep oldu" sorusu ise genellikle olay kaydının bir yerinde serbest metin olarak kalır ve hiçbir zaman toplanmaz.

Toplanmadığı için de kimse şunu bilmez: geçen yıl yaşadığımız kesintilerin kaçı veritabanı değişikliğinden kaynaklandı? Cevap bilinmediği sürece, onay sürecinin gerçekten koruyup korumadığı da bilinemez.

"Onaylandı" ile "Güvenli" Aynı Şey Değil

Değişiklik onayının çoğu, işin doğruluğuna odaklanır: doğru tabloya mı dokunuyor, doğru koşulu mu kullanıyor, iş kuralına uygun mu. Bunlar önemli sorulardır ve genellikle iyi sorulur.

Sorulmayan soru işin davranışıyla ilgilidir: bu ifade ne kadar sürecek, ne kadar kilitleyecek, ne kadar günlük alanı üretecek, çalışırken uygulamanın normal trafiği ne olacak. Bir betik hem yüzde yüz doğru hem de üretimi durduracak kadar tehlikeli olabilir ve bu ikisi arasında hiçbir çelişki yoktur.

Üretimi Durduran Altı Desen

Aşağıdaki desenlerin hepsi doğru yazılmış, hepsi onaylanmış ve hepsi üretimde kesinti üretmiş ifadelerdir.

Son satır özellikle önemlidir çünkü kurumların en çok yanıldığı yerdir. Çalıştırma başarılı olduğu ve hata dönmediği için değişiklik "sorunsuz" kabul edilir. Kesinti ertesi sabah, yoğun saatte gelir ve olay incelemesi bambaşka yerlerde arar.

Değerlendirmeye Eklenmesi Gereken Üç Soru

Risk değerlendirmesi genellikle "bu değişiklik ne kadar önemli" sorusuna cevap verir. Kesintiyi önlemek için üç soru daha gerekir ve üçü de betiğin içeriğinden okunabilir.

1. Bu ifade hangi nesneyi ne kadar kilitler? Kilit türü ve kapsamı ifadenin biçiminden çıkarılabilir. Kritik nesne listesindeki bir tabloya tablo seviyesinde kilit alacak bir ifade, içerik doğru olsa bile en yüksek banda girmelidir.

2. Kaç satır etkilenecek? Etkilenecek satır sayısı, kilit yükselmesi ve günlük büyümesi için belirleyici eşiktir. Bu sayı önceden kestirilebiliyorsa, aynı işi parçalara bölerek yapmak bir seçenek haline gelir.

3. Bu iş geri alınabilir mi ve geri alma betiği hazır mı? Kesinti anında sorulacak ilk soru budur ve o an hazırlanacak bir betik her zaman aceleyle yazılmış bir betiktir. Geri alma betiği, değişiklik onaylanmadan önce üretilmiş ve incelenmiş olmalıdır.

SQL Change Guard birinci ve üçüncü soruyu betiğin ayrıştırılmış halinden üretir: dokunulan nesneler, ifade türü, kritik nesne listesiyle eşleşme ve koşulsuz güncelleme gibi bulgular risk bandını belirler, geri alma betiği ise sunucudaki güncel tanımdan hazırlanır. İkinci soruda, yani etkilenen satır sayısında, kayıt çalıştırma sonrasında tutulur; bu sayı zaman içinde birikince hangi işlerin gerçekte ne kadar büyük olduğu görünür hale gelir. Değerlendirmenin insan yargısına değil yazılı kurallara dayanması, aynı betiğin her zaman aynı sonucu almasını sağlar.

En Kötü Senaryo: Yarım Kalmış Çalıştırma

Kesintiden daha kötü tek bir durum vardır: kesinti sırasında yarım kalmış bir çalıştırma. Betik on ifadeden oluşuyorsa ve altıncıda hata alındıysa, veritabanı artık ne eski halindedir ne de yeni halinde.

Bu durum özellikle veri tanımlama ifadelerinde zordur, çünkü bazı veritabanı sistemlerinde bu ifadeler kendiliğinden kalıcı hale gelir ve bir işlem içine alınıp topluca geri alınamaz. Yani "hepsi ya da hiçbiri" garantisi her zaman verilemez.

Bu gerçeği kabul eden bir tasarım üç şey yapar. Betiğin nereye kadar çalıştığını ifade bazında kaydeder, böylece durum bilinir. Geri alma betiğini önceden üretir ve idempotent yazar, böylece kısmen uygulanmış bir durumda da güvenle çalıştırılabilir. Ve hata anında ne yapılacağını sunucu bazında önceden tanımlar: otomatik geri alınsın mı, yoksa durup insan kararı mı beklensin.

Bu üçü olmadan yarım kalmış bir çalıştırma, kesintinin süresini uzatan asıl etkendir. Ekip önce ne olduğunu anlamaya çalışır, sonra ne yapacağını tartışır; bu sırada hizmet kapalıdır.

Ölçülmesi Gereken İki Gösterge

Değişiklik kaynaklı kesinti oranı. Bir dönemdeki kesintilerin kaçının kök nedeni bir değişiklikti? Bu sayıyı üretmek için olay kaydında serbest metin değil, değişiklik kaydına bağlanan bir alan gerekir. Sayı ölçülmeye başlandığı anda tartışma niteliksel olmaktan çıkar.

Başarısız değişiklik oranı. Onaylanıp çalıştırılan değişikliklerin kaçı hedeflenen sonucu vermedi veya geri alındı? Bu göstergede kurumlar arasındaki fark çok büyüktür; en olgun ekiplerde oran yüzde birkaç seviyesinde kalırken, süreçleri olgunlaşmamış ekiplerde bunun birkaç katına çıkabilmektedir. Aradaki farkı yaratan şey ekibin dikkati değil, değerlendirmenin içeriğe bakıp bakmamasıdır.

İki gösterge birlikte okunduğunda, onay sürecinin gerçekten koruyup korumadığı görünür hale gelir. Onay sayısı yüksek ama bu iki oran da yüksekse, süreç kayıt üretiyor demektir; koruma değil.

Sık Sorulan Sorular

Bakım penceresinde çalıştırıyoruz. Bu yeterli değil mi?

Bakım penceresi süreyi sınırlar, davranışı değiştirmez. İki durumda yetersiz kalır. Birincisi, ifadenin ne kadar süreceği önceden bilinmiyorsa pencere taşabilir ve iş yarım kalır; bu, hiç başlamamaktan kötüdür. İkincisi, bazı etkiler pencere içinde ortaya çıkmaz: sorgu planı değişikliği yüzünden gelen yavaşlama ertesi günün yoğun saatinde görülür. Pencere, süresi kestirilebilen ve geri alınabilir işler için etkilidir.

Test ortamında sorunsuz çalıştı. Neden üretimde farklı davransın?

Üç sebeple. Veri hacmi farklıdır ve kilit davranışı belirli eşiklerde tamamen değişir; test ortamında o eşik hiç aşılmaz. Eşzamanlılık farklıdır; test ortamında kimse aynı tabloya yazmazken üretimde yüzlerce oturum yazar ve kilit çakışması ancak orada oluşur. Son olarak istatistikler ve dolayısıyla sorgu planları farklıdır. Test ortamı doğruluğu doğrular, davranışı doğrulamaz.

Kilit süresini betiğe bakarak nasıl tahmin edebiliriz?

Kesin süre tahmin edilemez, ancak risk sınıfı ifadenin biçiminden çıkarılabilir ve karar için gereken de budur. Hangi ifadelerin tablo seviyesinde kilit aldığı, hangilerinin tüm satırları yeniden yazdırabildiği, hangilerinin mevcut satırları doğrulamak zorunda kaldığı bilinen bir kümedir. Bu bilgi bir kural setine dönüştürüldüğünde, betiği çalıştırmadan önce "bu ifade üretimi kilitleyebilir" uyarısı üretilebilir. Karar için gereken şey sürenin kendisi değil, riskin varlığıdır.

Her değişikliği bu kadar incelemek süreci yavaşlatmaz mı?

İncelemeyi insanın yapması yavaşlatır; kuralın yapması yavaşlatmaz. Kilit riski taşıyan desenler sınırlı sayıdadır ve otomatik olarak tespit edilebilir. Betiklerin büyük çoğunluğu bu desenlerin hiçbirini içermez ve doğrudan geçer. Yavaşlayan yalnızca gerçekten riskli olan azınlıktır; zaten yavaşlaması gereken de odur.

Kesintiden sonra hangi değişikliğin sebep olduğunu nasıl buluruz?

Bunun için tek bir şey gerekir: bir zaman aralığı verildiğinde o aralıkta veritabanında ne değiştiğini gösteren bir kayıt. Bu kayıt yoksa ekip birden fazla sistemin zaman damgalarını elle hizalamaya çalışır ve bu iş saatler alır; hizmet bu sırada kapalıdır. Nesne bazında geçmiş tutulduğunda soru saniyeler içinde cevaplanır: bu tablonun tanımı son yirmi dört saatte değişti mi, kim değiştirdi, hangi talep kapsamında.