Özel Yazılımda Bakım Anlaşması Neleri Kapsamalı? Rehber

Özel yazılım projesi yayına alındığında iş bitmiş sayılmaz. Gerçek kullanım başladığında hata kayıtları, kullanıcı geri bildirimleri, güvenlik güncellemeleri, altyapı değişiklikleri, entegrasyon sorunları, performans ihtiyaçları ve küçük iyileştirme talepleri ortaya çıkar. Bu yüzden bakım anlaşması, yazılımın canlı ortamda sağlıklı kalması için net bir çalışma çerçevesi sunmalıdır.

Bakım anlaşması olmayan projelerde en sık sorun beklenti belirsizliğidir. Müşteri küçük bir değişikliği bakım kapsamında görebilir; yazılım ekibi bunu yeni geliştirme olarak değerlendirebilir. Bir hata acil sanılır ama iş etkisi düşük olabilir. Bir güvenlik güncellemesi ertelenir ama risk büyür. Sağlıklı bir bakım anlaşması bu belirsizlikleri başlamadan azaltır.

Bakım anlaşması neden gereklidir?

Özel yazılım, işletmenin süreçlerine göre geliştirilir. Bu nedenle hazır bir ürün gibi tek seferlik teslim edilip unutulması doğru değildir. Kullanıcı sayısı artabilir, iş kuralları değişebilir, ödeme veya muhasebe entegrasyonu güncellenebilir, tarayıcılar ve işletim sistemleri değişebilir, güvenlik açıkları ortaya çıkabilir. Bakım anlaşması bu değişimlere kontrollü yanıt verme mekanizmasıdır.

ISO/IEC/IEEE 14764 standardı, yazılım bakımını yazılımın tesliminden sonra yapılan değişiklikleri ve destek süreçlerini ele alan bir yaşam döngüsü faaliyeti olarak konumlandırır ISO 14764. Bu yaklaşım, bakımın yalnızca hata düzeltme değil, yazılımın yaşamı boyunca sürdürülebilir kalmasını sağlayan disiplinli bir süreç olduğunu gösterir.

Özel web yazılım projelerinde bakım anlaşması; yazılımı ayakta tutan, kullanıcı destek sürecini düzenleyen ve yeni ihtiyaçların nasıl ele alınacağını belirleyen operasyonel çerçevedir.

Bakım ile yeni geliştirme aynı şey değildir

Bakım anlaşmasının en kritik bölümlerinden biri bakım ve yeni geliştirme ayrımıdır. Hata düzeltme, küçük uyarlama, güvenlik güncellemesi veya izleme faaliyeti bakım kapsamında olabilir. Ancak yeni modül, yeni entegrasyon, kapsamlı arayüz değişimi, yeni iş akışı veya büyük veri taşıma işlemi genellikle ayrı proje olarak değerlendirilmelidir.

Bu ayrım yazılı yapılmazsa bakım süreci hızla sınırsız talep listesine dönüşebilir. Müşteri “küçük bir ekleme” der, ama bu ekleme veritabanı değişikliği, yeni yetki kuralı, yeni rapor ve test gerektirebilir. Bu nedenle her talep önce sınıflandırılmalıdır.

Hata düzeltme kapsamı nasıl tanımlanmalı?

Bakım anlaşması, hatanın ne olduğunu ve nasıl önceliklendirileceğini açıklamalıdır. Her sorun aynı aciliyette değildir. Sistemin tamamen çalışmaması ile bir rapor başlığındaki metin hatası aynı kategoriye konmamalıdır. Önceliklendirme yapılmazsa destek ekibi de müşteri de aynı anda her şeyin acil olduğunu düşünür.

Hata öncelikleri iş etkisine göre tanımlanmalıdır:

• Kritik: Sistem kullanılamıyor, ödeme alınamıyor, veri kaybı riski var veya güvenlik açığı canlı etki yaratıyor.
• Yüksek: Ana iş akışı bozulmuş ama geçici çözüm var.
• Orta: Belirli kullanıcıları veya ikincil bir modülü etkileyen hata var.
• Düşük: Görsel, metinsel veya düşük etkili kullanım sorunu var.

Talep destek sistemi kullanılıyorsa her hata kaydı; ekran görüntüsü, kullanıcı, zaman, işlem adımı, beklenen sonuç, gerçekleşen sonuç ve varsa hata mesajı ile açılmalıdır. Bu bilgiler çözüm süresini doğrudan etkiler.

SLA ve SLO beklentileri net olmalı

Bakım anlaşmasında yanıt süresi, çözüm hedefi, mesai saatleri, destek kanalı ve acil durum prosedürü net yazılmalıdır. Ancak burada dikkat edilmesi gereken nokta, her anlaşmanın mutlak çözüm garantisi veremeyeceğidir. Özellikle üçüncü taraf API, hosting, ödeme sağlayıcı veya müşteri verisi kaynaklı sorunlarda çözüm süresi dış bağımlılıklara bağlı olabilir.

Google SRE kitabı, SLI, SLO ve SLA kavramlarını ayrı ele alır; SLI ölçüm göstergesi, SLO hedef seviye, SLA ise genellikle hizmet seviyesi taahhüdü ve sonuçları olan anlaşma olarak açıklanır Google SRE. Bu ayrım bakım anlaşmaları için önemlidir: önce neyin ölçüleceği ve hangi hedefin makul olduğu belirlenmelidir.

Örneğin bakım anlaşmasında “kritik hatalara mesai içinde 1 saat içinde dönüş”, “yüksek öncelikli sorunlarda aynı gün analiz”, “planlı güncellemeler için önceden bildirim” gibi maddeler yer alabilir. Çözüm süresi ise hatanın kaynağına ve kapsamına göre ayrıca tanımlanmalıdır.

Destek kanalı ve iletişim düzeni belirlenmeli

Bakım anlaşması, taleplerin nereden açılacağını ve nasıl takip edileceğini belirtmelidir. WhatsApp, e-posta, telefon, proje yönetim aracı ve destek sistemi aynı anda kontrolsüz kullanılırsa talepler kaybolabilir. En sağlıklı yöntem, tüm taleplerin tek kayıt sisteminde toplanmasıdır.

Destek sürecinde şu bilgiler net olmalıdır:

• Talep hangi kanaldan açılacak?
• Acil durumlarda kim aranacak?
• Talep açarken hangi bilgiler istenecek?
• Önceliği kim belirleyecek?
• Durum güncellemeleri hangi sıklıkta verilecek?
• Kapatılan talep nasıl onaylanacak?
• Aynı sorunun tekrar etmesi nasıl ele alınacak?

Bu düzen yalnızca yazılım ekibini değil, müşterinin iç operasyonunu da rahatlatır. Kim neyi ne zaman bildirdi, hangi aşamada, kimden bilgi bekleniyor soruları netleşir.

Güvenlik güncellemeleri bakımın parçası olmalı

Canlı yazılımda güvenlik bakım kapsamının dışında bırakılamaz. Kullanılan framework, kütüphane, sunucu bileşeni, API anahtarı, kullanıcı yetkisi ve oturum yönetimi zamanla kontrol edilmelidir. Güvenlik güncellemeleri ertelendikçe risk birikir.

OWASP Application Security Verification Standard, web uygulamaları ve servisler için güvenlik gereksinimlerini tanımlayan bir doğrulama standardı sunar OWASP ASVS. Bakım anlaşması bu standardın tamamını birebir uygulamak zorunda değildir; ancak kimlik doğrulama, yetki, oturum, veri koruma, hata yönetimi ve güvenli konfigürasyon başlıklarının düzenli gözden geçirilmesi gerektiğini hatırlatır.

Yazılım güvenliği açısından bakım anlaşmasında en azından bağımlılık güncellemeleri, kritik güvenlik yamaları, erişim yetkilerinin gözden geçirilmesi, admin hesaplarının kontrolü ve log inceleme yaklaşımı bulunmalıdır.

Yedekleme ve geri dönüş planı yazılı olmalı

Bakım anlaşması yedekleme sorumluluğunu açıkça tanımlamalıdır. Yedekler hangi sıklıkla alınacak, nerede saklanacak, ne kadar süre tutulacak, geri yükleme nasıl test edilecek, veri kaybı toleransı nedir? Bu sorular belirsizse gerçek bir arıza anında panik oluşur.

Yedekleme yalnızca dosya kopyalamak değildir. Veritabanı, kullanıcı yüklemeleri, görseller, konfigürasyonlar, loglar ve entegrasyon anahtarları ayrı ayrı düşünülmelidir. Ayrıca yedek alınması tek başına yeterli değildir; belirli aralıklarla geri yükleme testi yapılmalıdır.

Bu başlık ileride özel bir veri yedekleme stratejisiyle daha detaylı ele alınabilir; bakım anlaşmasında ise sorumluluk ve kontrol maddeleri net olmalıdır.

İzleme ve performans takibi kapsamda yer almalı

Bakım yalnızca müşteri hata bildirdiğinde başlayan pasif bir süreç olmamalıdır. Uygulama erişilebilirliği, sunucu kaynakları, hata oranı, API yanıtları, cron görevleri, ödeme ve fatura akışları, veritabanı performansı ve disk kullanımı izlenebilmelidir.

Google SRE yaklaşımı, kullanıcı açısından anlamlı göstergeleri ölçmeye ve hizmet hedeflerini buna göre belirlemeye odaklanır Google SRE. Özel yazılım bakımında bu yaklaşım, “sunucu çalışıyor mu?” sorusunun ötesine geçmeyi sağlar. Ödeme alınıyor mu, sipariş oluşuyor mu, kullanıcı giriş yapabiliyor mu, entegrasyon kuyruğu birikiyor mu gibi iş metrikleri de izlenmelidir.

API entegrasyonu olan projelerde izleme özellikle önemlidir. Üçüncü taraf servis çalışıyor ama yavaş yanıt veriyor olabilir; webhook geliyor ama işlenmiyor olabilir; token süresi bitmiş olabilir. Bakım anlaşması bu tür olayların nasıl fark edileceğini ve kimin müdahale edeceğini açıklamalıdır.

Küçük iyileştirme hakkı nasıl tanımlanmalı?

Bazı bakım anlaşmaları aylık belirli saat veya talep limiti içinde küçük iyileştirmeler içerebilir. Bu faydalıdır; çünkü canlı yazılımda metin düzeltme, küçük alan ekleme, filtre düzenleme, rapor başlığı değiştirme veya basit kullanıcı deneyimi iyileştirmeleri sık görülür. Ancak bu hakkın sınırı net olmalıdır.

Küçük iyileştirme tanımı şu kriterlere göre yapılabilir: yeni veri tabanı tablosu gerektiriyor mu, yeni yetki yapısı istiyor mu, yeni entegrasyon içeriyor mu, kapsamlı test gerektiriyor mu, birden fazla modülü etkiliyor mu? Eğer cevaplar evetse bu talep bakım değil, yeni geliştirme olarak planlanmalıdır.

Yazılım maliyetleri açısından bu ayrım kritiktir. Bakım anlaşmasının içine sınırsız yeni geliştirme beklentisi konursa hem bütçe hem teslimat yönetimi bozulur.

Versiyon, dokümantasyon ve değişiklik kayıtları tutulmalı

Bakım sürecinde yapılan her değişiklik kayıt altına alınmalıdır. Hangi hata düzeltildi, hangi dosya veya modül değişti, hangi versiyon yayına alındı, kim test etti, geri dönüş planı var mı? Bu bilgiler tutulmazsa birkaç ay sonra sistemin neden değiştiği anlaşılamaz.

Bakım anlaşması versiyon notları, yayın planı, test ortamı, canlıya alma saatleri ve değişiklik onayı gibi konuları içermelidir. Özellikle ödeme, fatura, stok, müşteri verisi veya yetki sistemi etkileniyorsa canlıya alma süreci daha kontrollü yürütülmelidir.

Google SRE postmortem kültürü, olaylardan öğrenmeyi ve tekrarını önlemek için suçlayıcı olmayan incelemeleri vurgular Google SRE Postmortem. Yazılım bakımında da kritik hatalar sonrası kısa kök neden analizi yapılması, aynı sorunun tekrarını azaltır.

Kapsam dışı işler açık yazılmalı

İyi bakım anlaşması yalnızca kapsadıklarını değil, kapsamadıklarını da yazar. Bu bölüm anlaşmazlıkları azaltır. Örneğin yeni modül geliştirme, büyük tasarım değişikliği, üçüncü taraf servis ücretleri, hosting maliyetleri, içerik girişi, veri temizliği, SEO çalışması veya yeni entegrasyonlar bakım dışında olabilir.

Kapsam dışı işler şu şekilde netleştirilebilir:

• Yeni özellik ve yeni modül geliştirme
• Kapsamlı arayüz veya marka tasarım değişikliği
• Yeni API, ödeme, kargo veya muhasebe entegrasyonu
• Eski verinin toplu temizliği veya veri taşıma projesi
• Hosting, domain, lisans veya üçüncü taraf servis ücretleri
• İçerik, ürün, kategori veya kampanya girişi
• Müşteri kaynaklı hatalı veri düzeltmeleri
• Mesai dışı destek, anlaşmada ayrıca belirtilmemişse

Raporlama ve aylık değerlendirme olmalı

Bakım anlaşmasının değeri yalnızca sorun çıktığında anlaşılmamalıdır. Aylık veya dönemsel raporlarla hangi talepler geldi, hangi hatalar düzeltildi, hangi güvenlik güncellemeleri yapıldı, hangi performans sorunları görüldü ve hangi yeni ihtiyaçlar oluştu takip edilmelidir.

Basit bir bakım raporu şu bilgileri içerebilir:

Bakım anlaşması için kontrol listesi

Özel yazılım bakım anlaşması hazırlarken aşağıdaki başlıklar kontrol edilmelidir:

• Bakım ve yeni geliştirme ayrımı yazılı mı?
• Hata öncelikleri ve iş etkisi tanımlı mı?
• Yanıt süresi, destek saatleri ve iletişim kanalı belli mi?
• Güvenlik güncellemeleri ve bağımlılık kontrolleri kapsamda mı?
• Yedekleme sorumluluğu ve geri yükleme testi yazılı mı?
• İzleme ve alarm başlıkları belirlenmiş mi?
• Küçük iyileştirme hakkı varsa sınırı net mi?
• Entegrasyon hatalarında sorumluluk dağılımı belli mi?
• Versiyon notu, test ve canlıya alma süreci tanımlı mı?
• Kapsam dışı işler açıkça yazıldı mı?
• Aylık veya dönemsel bakım raporu hazırlanacak mı?

Sonuç: Bakım anlaşması belirsizliği azaltır

Özel yazılımda bakım anlaşması, yalnızca arıza çıktığında devreye giren destek paketi değildir. Yazılımın güvenli, güncel, izlenebilir, yedeklenebilir ve geliştirilebilir kalmasını sağlayan operasyon çerçevesidir. Doğru hazırlanmış bir anlaşma hem müşterinin beklentisini hem yazılım ekibinin sorumluluğunu netleştirir.

Webioo, özel yazılım projelerinde bakım anlaşmasını proje tesliminden sonra eklenen ayrı bir evrak gibi değil; yazılımın sürdürülebilir çalışması için gerekli bir devam planı olarak ele alır. Hata yönetimi, güvenlik, izleme, yedekleme, küçük iyileştirmeler ve kapsam dışı işler baştan netleştiğinde yazılım uzun vadede daha sağlıklı yönetilir.