Kesinti, ekibinizi beklemez.

Hizmet hedeflerini kullanıcı bakış açısıyla ölçmek

Bir uygulama erişilebilir olsa da siparişleri işleyemiyor olabilir. Bu nedenle ilgili kullanıcı akışları için ölçüm noktaları seçer, erişilebilirliği, başarılı işlemeyi ve yanıt süresini birbirinden ayırırız. Bir hizmet hedefi bir ölçüm dönemi, bir veri kaynağı ve eksik ölçümlerle nasıl başa çıkılacağına dair kurallar gerektirir. Ancak bundan sonra, üzerinde anlaşılan durumun sağlanıp sağlanmadığı şeffaf biçimde değerlendirilebilir.

Hedeften geriye kalan sapma payı, stabilizasyon ile ileri geliştirme arasında denge kurmak için bir hata bütçesi olarak kullanılabilir. Bu bütçenin aşılmasının hangi sonuçları doğuracağı birlikte belirlenir. Bu, ne sözleşmeye dayalı hizmet anlaşmalarının ne de tek bir ciddi olayın değerlendirilmesinin yerini tutar. Gösterge panelleri ve alarmlar kararları desteklemelidir: Kim tepki verecek, hangi teşhis izlenecek ve iş birimindeki sorumlular ne zaman bilgilendirilmelidir?

Yedekleme, kurtarma ve bağımlılıkları test etmek

Başarıyla tamamlanmış bir yedekleme işlemi, kurtarılabilirliği henüz kanıtlamaz. En fazla kabul edilebilir veri kaybının ne olduğunu ve bir kesintinin ne kadar sürebileceğini netleştiririz. Buradan yedekleme aralıklarına, saklama süresine ve yeniden başlatmaya ilişkin gereksinimler ortaya çıkar. Uygulamaya veritabanının yanı sıra çoğu zaman dosyalar, yapılandırma, anahtarlar ve dış hizmetler de dahildir; bir parça eksik olduğunda, teknik olarak okunabilir bir yedek yine de kullanılamaz olabilir.

Kurtarma tatbikatları, üzerinde anlaşılan süreci uygun bir ortamda test eder. Bu sırada süre, gereken erişimler, elle yapılan adımlar ve iş açısından veri kontrolleri belgelenir. Tek bir kiracı veya yanlışlıkla silinmiş bir kayıt, tam bir kesintiden farklı kurtarma yolları gerektirebilir. Sonuçlar somut iyileştirmelere yansıtılır. Test edilmemiş bir hedef değeri garanti edilmiş bir yetenek gibi göstermek yerine, tespit edilen eksiklikler açıkça belirtilir.

Güvenlik güncellemeleri, kök neden analizi ve planlanabilir çıkış

Güvenlik açığı bulunan bir kütüphaneye ilişkin bir bildirim, uygulama bağlamında değerlendirilir: Hangi sürüm kullanılıyor, etkilenen işlev erişilebilir mi ve hangi koruma önlemleri mevcut? Aciliyet ile değişikliğin teknik riski birlikte ele alınır. Hemen uygulanamayan güncellemeler için belgelenmiş ara önlemler ve yeniden değerlendirme için bir tarih gereklidir. Yeni sürümler uygun testlerden ve üzerinde anlaşılmış bir yaygınlaştırmadan geçer.

Tekrarlayan veya ciddi arızaların ardından nedeni, tespiti ve tepkiyi araştırırız. Bundan sadece kapatılmış bir bilet değil, sorumluları belli önceliklendirilmiş önlemler ortaya çıkar. Dokümantasyon, runbook'lar ve erişim özetleri sürekli olarak güncel tutulur. Ekibinize veya başka bir hizmet sağlayıcıya sonradan yapılacak devir de hazırlanır: kod deposu, derleme talimatı, açık riskler ve düzenli bir erişim aktarımıyla. Bilgi şeffaf kaldığı sürece bir hizmet uzun vadede sürdürülebilir olur.