Veritabanı güvenilirliği, çalışır durumda olmak değildir

Uptime yanılsaması

İzlemenin çoğu tek bir soruyla başlar: çalışıyor mu? Bu, makul bir ilk sorudur. Aynı zamanda bir veritabanının neredeyse her zaman evet dediği sorudur; ta ki bir sabah biri, ödeme adımının iki hafta önce neden yavaşladığını, gece çalışan işin neden artık mesai saatlerine taştığını ya da bir denetçinin neden geçen yıl güvenlik güncellemesi almayı bırakmış bir sürümde çalışan bir sunucu bulduğunu sorana kadar.

Bunların hiçbiri bir kesinti değildi. Hepsi birer güvenilirlik hatasıydı. Veritabanı baştan sona çalışır durumdaydı.

Beş tür sinyal

1. Yavaşlayan sorgular

Yavaş değil: daha yavaş. Her zaman 300 ms süren bir sorgu haber değildir. Geçen hafta 38 ms süren ve şimdi 54 ms süren bir sorgu ise haberdir; hiçbir sabit eşik onu yakalayamayacak olsa bile. Faydalı karşılaştırma, her sorguyu günün aynı saatinde kendi geçmişiyle kıyaslamaktır.

2. Şekil değiştiren iş yükü

Okuma ve yazma dengesi kayar, geri almalar artar, bağlantılar boşta bekleyen işlemlerde birikir, önbellek isabet oranı düşer. Her değişiklik küçüktür ve masum bir açıklaması vardır. Bir araya geldiklerinde ise çoğu zaman uygulamanın veritabanını kullanma biçimini değiştiren bir sürümün ilk işaretidir.

3. Sessizleşen izleme

En tehlikeli grafik, sakin görünen boş grafiktir. Bir agent veri göndermeyi bırakırsa her grafik düzleşir ve her alarm susar; bu da tıpkı sağlıklı bir veritabanı gibi görünür. Sessizliğin kendisi bir alarm üretmelidir.

4. Sürüm ve güvenlik riskleri

Motor sürümleri yayınlanmış bir takvime göre kullanım ömrünün sonuna ulaşır ve güvenlik açıkları sürüm aralıklarına göre yayınlanır. Ayarlar zamanla kayar: kimsenin verdiğini hatırlamadığı bir superuser rolü, tek seferlik bir iş için açılmış bir genişletilmiş saklı yordam. Bunların hiçbiri performans grafiklerinde görünmez; hepsi bir denetimde ortaya çıkar.

5. Şema ve yetki kayması

Bir temizlik sırasında silinen bir index, migration aracının dışında eklenen bir sütun, geçici olması gereken bir raporlama rolüne verilmiş bir yetki. Neyin ne zaman değiştiğini bilmek, uzun bir araştırmayı kısa bir araştırmaya dönüştürür.

Bir beceri değil, ölçek sorunu

Üç DBA'den oluşan bir ekip on veritabanını elle izleyebilir. PostgreSQL, SQL Server, Oracle, MongoDB ve hepsinin önündeki Redis genelinde, her biri kendi konsolu ve kendine özgü hata biçimleriyle üç yüz veritabanını izleyemez. Bu ölçekte güvenilirlik, insanların her yere bakmasına değil, sistemin onlara kanıtıyla birlikte nereye bakmaları gerektiğini söylemesine bağlıdır.

Nöbette olmayanlar

Güvenilirliğin bir izleme aracını hiç açmayacak okuyucuları da vardır: bütçeyi nereye harcayacağına karar veren CTO, bir denetime hazırlanan güvenlik sorumlusu, denetçinin kendisi. Onların bir belgeye ihtiyacı vardır: hangi sunucuların kullanım ömrü sonunu geçtiği, riskin ne olduğu, planın ne olduğu ve ne kadar iş gerektirdiği.

Başlangıç için bir kontrol listesi

Her üretim veritabanı için bugün şu sorulara yanıt verebiliyor musunuz?

1. Sorgularından hangileri, günün aynı saatinde bir hafta öncesine göre daha yavaş?
2. İş yükü son sürümden bu yana şekil değiştirdi mi?
3. İzleme verisi gelmeyi bırakırsa bunu bir gün içinde fark eder miydiniz?
4. Sürümü hâlâ destekleniyor mu ve hangi bilinen güvenlik açıkları onu etkiliyor?
5. Bu ay şemasında ve yetkilerinde neler değişti?
6. Yukarıdakilerin tek sayfalık bir özetini, hiç oturum açmayacak birine verebilir miydiniz?

Uptime rakamı ne derse desin, her "hayır" güvenilirlikte bir açıktır. Logstag bu liste etrafında geliştirildi: ilk ikisi için Insights, üçüncüsü için alarmlar, dördüncüsü için Güvenlik Raporu, beşincisi için schema explorer ve sonuncusu için raporlar.