Bir yazılımın yayına alınması operasyonun başlangıcıdır. Alan adı yenilemesi, hizmet kesintisi, dolan depolama alanı veya başarısız yedek işletmenin günlük işini etkileyebilir. Bakım anlaşması yalnızca “destek verilir” cümlesiyle bırakıldığında bu işlerin sahibi belirsiz kalır. Önce hangi bileşenin kim tarafından izlendiğini, hangi durumda kime haber verileceğini ve düzeltmenin nasıl yapılacağını açıklayın.
Çalışan sistemin bağımlılıklarını listeleyin
Alan adı, barındırma, veritabanı, dosya depolama, e-posta sağlayıcısı ve harici API’ler farklı hizmetler olabilir. Her biri için hesap sahibi, faturalama sorumlusu ve teknik irtibat belli olsun. Erişimleri tek kişinin kişisel hesabına bağımlı bırakmayın. Gerekli sırların güvenli yönetimini planlayın; şifreleri bakım belgesinin içine düz metin olarak yazmak yerine uygun erişim süreci tanımlayın.
Yedek almak ile geri dönebilmek aynı değildir
Hangi verinin yedeklendiği, nerede tutulduğu ve ne kadar geriye dönülebildiği açık olsun. Veritabanı yedeği dosya eklerini içermeyebilir. Sadece başarılı yedek bildirimi almak yeterli değildir; uygun test ortamında geri yükleme denemesi yapılmalıdır. Denemede kayıtların, dosyaların ve uygulama sürümünün birlikte çalıştığını doğrulayın. İşletmenin kabul edebileceği veri kaybı aralığı ve toparlanma süresi planı yönlendirmelidir.
Örnek olarak gün boyu sipariş alan bir işletmeyle haftada birkaç içerik güncelleyen kurumsal sitenin ihtiyacı aynı değildir. Herkese aynı yedek sıklığını önermek yerine iş etkisini değerlendirin. Ayrıca yanlışlıkla silinen tek bir kaydı geri getirmek ile bütün sistemi önceki güne döndürmek farklı işlemlerdir. Geri yüklemenin sonradan oluşan doğru verileri kaybettirmemesi için yöntem düşünülmelidir.
Uyarıların eyleme dönüşmesini sağlayın
Sitenin açılması tek sağlık göstergesi değildir. Form teslimi, arka plan işi ve harici entegrasyon hata verebilir. Kritik akışlar için uygun kontroller belirleyin. Uyarının kime gittiği, ne kadar sürede ele alınacağı ve hangi bilgiyle araştırılacağı belli olsun. Çok sayıda önemsiz bildirim gerçek sorunun kaçmasına neden olabilir. Günlüklerde hassas veri toplamadan teşhis için yeterli bağlam tutun.
Değişiklikleri kontrollü yayınlayın
Kütüphane veya platform güncellemesinin etkisi test ortamında değerlendirilmelidir. Önemli akışların kısa kontrol listesi, sürüm notu ve geri dönüş yolu olsun. Her güncellemeyi süresiz ertelemek de bütün paketleri denemeden değiştirmek de sorun yaratabilir. Önceliği güvenlik, destek durumu ve iş ihtiyacına göre belirleyin. Güncellenen sürümün hangi tarihte yayına çıktığını kaydetmek olay araştırmasını kolaylaştırır.
- Her hizmetin hesap ve bakım sorumlusu belli mi?
- Yedek kapsamı veritabanı ve dosyaları içeriyor mu?
- Geri yükleme denemesi yakın zamanda yapıldı mı?
- Kritik akış uyarıları gerçek bir kişiye ulaşıyor mu?
- Yayın ve geri dönüş adımları uygulanabilir biçimde yazılı mı?
Bakımı devredilebilir bir bilgi haline getirin
Yeni bir ekip geldiğinde sistemi yalnızca koddan anlamak zorunda kalmamalıdır. Mimari özet, kritik iş akışları, ortam listesi ve olay geçmişi kısa ama güncel olmalıdır. Belgenin sorumlusu ve kontrol tarihi bulunsun. Bakım raporunda yalnızca yapılan saatleri değil, tespit edilen riskleri ve tamamlanan geri yükleme kontrollerini gösterin. Böylece işletme bakımın hangi devamlılık ihtiyacını karşıladığını görebilir.
Günlüklerin güvenli hazırlanması için OWASP kayıt tutma rehberi kullanılabilir. Teslim kontrol listesine bakım devrini ekleyin; yazılım hizmetlerimizde yayın sonrası sorumlulukları baştan belirleyebiliriz.