Canlıya alınan sistem değişen tarayıcılar, işletim koşulları, veri hacmi ve iş ihtiyaçlarıyla yaşamaya devam eder. Bu nedenle yazılım bakım anlaşması, yalnızca “arıza olursa aranacak kişi” bilgisinden daha açık bir sorumluluk modeli kurmalıdır.
Hata ile değişiklik talebini ayırın
Onaylanmış işlevin beklenen sonucu üretmemesi hata; yeni alan, farklı rapor veya değişen iş kuralı geliştirme talebidir. Sınıflandırma yöntemi, öncelik kararı ve onay akışı baştan yazılırsa destek görüşmeleri yoruma dayanmaz.
Hizmet seviyesini tek süreye indirgemeyin
- Yanıt süresi: Talebin alındığının ve önceliğinin teyidi.
- Müdahale süresi: Teknik incelemenin başlaması.
- Geçici çözüm: Kritik işlemi güvenle sürdüren yol.
- Kalıcı çözüm: Test edilmiş düzeltmenin yayınlanması.
Kritik seviyenin ne olduğu örneklerle tanımlanmalıdır. Bir kullanıcının rapor filtresi ile tüm şubelerin satış yapamaması aynı sıraya konmamalıdır.
Operasyon sorumluluklarını görünür kılın
Sunucu ve veritabanı izleme, yedek alma, geri dönüş testi, SSL veya alan adı takibi, bağımlılık güncellemeleri ve güvenlik kayıtlarının kimin sorumluluğunda olduğu belirtilmelidir. Yedek var demek yeterli değildir; saklama süresi ve dönüş testi de anlaşmaya girmelidir.
Değişiklik ve sürüm disiplini
Yeni taleplerin tahmin, onay, test ortamı, kullanıcı kabulü ve canlı yayın adımları tanımlanır. Acil düzeltmeler bile sonradan kayıt altına alınmalı ve regresyon kontrolünden geçmelidir. Sürdürülebilir yazılım hizmeti bu yaşam döngüsünü teslimin parçası sayar.
Hizmet raporu ne göstermeli?
Aylık bakım özeti yalnızca kapatılan talep sayısını vermemelidir. Öncelik bazında yanıt ve çözüm süreleri, tekrarlayan hata, planlı güncelleme, yedek dönüş sonucu, kapasite eğilimi ve açık riskler görünür olmalıdır. Çok sayıda küçük talep iyi hizmet anlamına gelmeyebilir; aynı kök nedenin tekrarını gösterebilir. Düzenli değerlendirme toplantısı bakım verisini ürün yol haritasına ve önleyici teknik çalışmalara dönüştürür.