Yazılım Bakım Anlaşması Neleri Kapsar?

İlk geliştirmede kabul edilmiş bir davranışın bozulması ile yeni bir iş kuralı talebi farklı çalışmalardır. Hangi sürümün ve hangi özelliklerin desteklendiğini kaydedin. Sonradan değiştirilen entegrasyon veya müşteri tarafından eklenen bileşenin kapsamı nasıl etkileyeceğini açıklayın.

Bir talebin alındığının bildirilmesi, soruna teknik olarak müdahale edilmesi ve sorunun çözülmesi farklı anlardır. Her biri için ölçümün ne zaman başladığını, hangi takvimde işlediğini ve müşteriden bilgi beklenirken nasıl ele alındığını tanımlayın.

Hizmet göstergesi ölçülen davranışı, hedef bu davranış için beklenen düzeyi, hizmet anlaşması ise tarafların kabul ettiği koşulları ifade eder. Google SRE bu kavramları ayrı ele alır. Projede kullanılacak ölçümü ve hedefi, kullanıcı için önemli iş akışı üzerinden seçin. Tek bir erişilebilirlik yüzdesi, doğru sipariş üretildiğini tek başına göstermez.

Tüm taleplerin acil olması önceliklendirmeyi işlemez hale getirir. Etkilenen kullanıcı sayısı, kritik işin durması, veri bütünlüğü ve kullanılabilir geçici çözüm birlikte değerlendirilmelidir. İlk sınıflandırmayı kimin yaptığı ve gerektiğinde kimin yükseltebildiği belirli olsun.

Bir gösterge panelinin açık olması olayın takip edildiğini kanıtlamaz. Hangi alarmın hangi ekibe gittiğini, mesai dışı takibi ve yanlış alarmın nasıl ele alınacağını yazın. Gecikme, hata, trafik ve kaynak doygunluğu gibi sinyaller başlangıç noktası olabilir; önemli olan uygulamanızdaki kullanıcı etkisini görebilmektir.

Olay kaydında etkilenen sürüm, zaman aralığı, iş akışı ve uygulanan geçici çözüm yer alsın. Hassas bilgileri gereksiz biçimde hata kayıtlarına taşımayın. Olay kapatıldığında hangi doğrulamanın yapıldığı ve tekrarını azaltacak işlerin neler olduğu raporlansın.

Yedek kapsamına veritabanı, dosyalar, gerekli ayarlar ve dış sistemlerdeki varlıkların hangilerinin girdiğini yazın. Yedeğin varlığını görmek ile geri yüklenebildiğini doğrulamak farklı kontrollerdir. Ayrı bir ortamda yapılan provanın tarihini ve sonucunu saklayın.

İş ekibiyle kabul edilebilir veri kaybı aralığını ve yeniden çalışır hale gelme hedefini konuşun. Bu hedeflerin altyapı ve süreçle karşılanabilirliğini test edin. Yalnızca kod sürümünü geri almak veri değişikliklerini her zaman geri çevirmez; yayın ve veri geçişi için ayrı dönüş planı gerekebilir.

API sağlayıcısı, barındırma veya ücretli bileşen değişikliği bakım ekibinin kontrolü dışında olabilir. Bu durumda bildirim, ilk inceleme, sağlayıcıyla iletişim ve geçici çözüm sorumluluklarını belirleyin. Üçüncü taraf giderlerinin ve lisans yenilemelerinin kime ait olduğunu da yazın.

Planlı güncellemelerde test ortamı, onay, yayın saati ve geri dönüş koşulu tanımlansın. Yeni özelliğin bakım kotasına dahil olup olmadığı, kullanılmayan çalışma süresinin durumu ve kapsam dışı talebin nasıl tekliflendirileceği baştan açıklansın.

Dönem sonunda yalnızca kapanan talep sayısını değil, tekrar eden olayları, yapılan güncellemeleri, yedek provası sonucunu ve açık riskleri görün. Geciken işlerin bağımlılıklarını ve bir sonraki dönemin önceliklerini birlikte değerlendirin.

Bakım sağlayıcısı değiştiğinde hangi hesapların, belgelerin ve kayıtların aktarılacağını tanımlayın. Yeni ekibin erişimi doğrulanırken eski yetkilerin hangi sırayla kaldırılacağı planlansın. Hizmetin bitişi uygulamanın işletilemez hale gelmesine yol açmamalıdır.

Teknik devir rehberi teslim paketini; yazılım devralma kontrol listesi mevcut durum incelemesini açıklar. Tüm süreci yazılım rehberleri merkezinden takip edebilir, sorularınızı proje briefine taşıyabilirsiniz.