Özel bir yazılım canlıya alındığında proje bitmiş gibi görünür: kullanıcılar sisteme girer, veriler işlenir ve ana akışlar çalışır. Oysa canlı kullanım; gerçek veri hacmini, beklenmeyen kullanıcı davranışlarını, üçüncü taraf servis değişikliklerini ve yeni güvenlik ihtiyaçlarını görünür hâle getirir. Bakım planı olmayan bir sistemde küçük sorunlar birikir, sorumlular belirsizleşir ve kritik bir hata çıktığında kimden ne kadar sürede destek alınacağı ancak kriz sırasında konuşulur.
Yazılım bakım ve destek hizmeti, sınırsız geliştirme sözü değildir. Ama yalnızca sistem bozulduğunda geliştiriciye ulaşmaktan da fazlasıdır. İyi tanımlanmış bir kapsam; hata giderme, güvenlik güncellemeleri, izleme, yedekleme, küçük iyileştirmeler, destek kanalları ve hizmet seviyelerini birbirinden ayırır. Böylece işletme süreklilik beklentisini bütçeler, yazılım ekibi de hangi talebe nasıl öncelik vereceğini bilir.
1. Garanti, bakım, destek ve yeni geliştirme aynı şey değildir
Garanti dönemi genellikle teslim edilen ve kabul edilen kapsamın hatalı çalışmasıyla ilgilidir. Bakım, yazılımın kullandığı kütüphaneleri, çalışma ortamını ve güvenlik bileşenlerini sağlıklı tutmayı kapsar. Destek ise kullanıcıların sorun bildirmesi, olayın incelenmesi ve kullanım konusunda yönlendirilmesi için kurulan süreçtir. Yeni rapor, rol, entegrasyon veya iş akışı eklemek ise çoğu durumda geliştirme talebidir. Bu ayrımlar teklifte yazmıyorsa taraflar aynı aylık bedelden farklı sonuçlar bekleyebilir.
Örneğin mevcut sipariş ekranının belirlenen kurala rağmen kayıt yapmaması hata sayılabilir. Kullanıcıya filtreyi nasıl kullanacağını anlatmak destek işidir. Kullanılan altyapının güvenlik güncellemesini kontrollü biçimde uygulamak bakımdır. Siparişlere yeni bir onay seviyesi eklemekse analiz, geliştirme ve test gerektiren yeni kapsamdır. Talep türünü doğru sınıflandırmak, hem çözüm süresini hem maliyet takibini iyileştirir.
Bakım anlaşmasının amacı her talebi tek sepete koymak değil, canlı sistemin hangi koşullarda nasıl korunacağını öngörülebilir hâle getirmektir.
2. Temel bakım kapsamındaki işler neler olmalı?
Her yazılımın teknolojisi ve işteki önemi farklıdır; yine de sürdürülebilir bir bakım hizmetinde ortak başlıklar bulunur. Önce uygulama, veritabanı, zamanlanmış görevler ve kritik entegrasyonlar için izleme kurulmalıdır. Hata kayıtları yalnızca sunucuda tutulmamalı; incelenebilir, erişimi kontrollü ve gerekli süre boyunca saklanan bir yapıda olmalıdır. Güvenlik yamaları ve bağımlılık güncellemeleri körlemesine canlıya alınmadan test ortamında doğrulanmalıdır.
- Uygulama ve entegrasyon hatalarının incelenmesi ve mevcut kapsamdaki kusurların giderilmesi
- İşletim ortamı, framework ve bağımlılıklar için planlı güvenlik güncellemeleri
- Uygulama erişilebilirliği, hata oranı, disk kullanımı ve kritik işlerin izlenmesi
- Veritabanı ve dosyalar için yedekleme yapılması, sonuçların kontrol edilmesi ve geri yükleme denemeleri
- Performans sorunlarının analizi, yavaş sorguların ve kaynak darboğazlarının takibi
- SSL sertifikası, zamanlanmış görev, e-posta ve üçüncü taraf bağlantı sürelerinin izlenmesi
- Yapılan müdahaleleri, açık riskleri ve yaklaşan güncellemeleri gösteren düzenli raporlama
Liste kadar sorumluluk sınırı da önemlidir. Sunucu başka firmadaysa altyapı müdahalesini kimin yapacağı; ödeme, ERP veya SMS servisi kesilirse bakım ekibinin hangi noktaya kadar sorumlu olduğu açıklanmalıdır. Üçüncü taraf arızası bakım ekibinin kontrolünde olmayabilir, ancak olayın tespit edilmesi, doğru sağlayıcıya iletilmesi, geçici çözüm değerlendirilmesi ve işletmenin bilgilendirilmesi hizmetin parçası olarak tanımlanabilir.
3. SLA hangi süreleri ve öncelikleri açıklamalı?
SLA, yani hizmet seviyesi anlaşması, yalnızca “hızlı destek” ifadesini somutlaştırır. İlk yanıt süresi ile sorunun tamamen çözülme süresi aynı değildir. İlk yanıt, talebin alındığını ve incelemenin başladığını gösterir. Çözüm süresi ise problemin karmaşıklığına, dış servis bağımlılığına ve gerekli değişikliğin riskine göre değişebilir. Bu nedenle anlaşmada müdahale hedefi, durum güncelleme sıklığı ve mümkünse geçici çözüm beklentisi ayrı yazılmalıdır.
Öncelik sınıfları iş etkisine göre tanımlanmalıdır. Tüm kullanıcıların sipariş verememesi kritik bir olayken tek kullanıcının rapor görünümündeki küçük hizalama sorunu aynı sıraya giremez. Kritik, yüksek, normal ve düşük gibi seviyeler için örnek senaryolar verilmesi tartışmayı azaltır. Hizmet saatleri de açık olmalıdır: mesai içi destek ile gece ve hafta sonunu kapsayan nöbet yapısı farklı ekip ve bütçe gerektirir. İşletme gerçekten ihtiyaç duymuyorsa her sistem için 7/24 taahhüt satın almak zorunda değildir.
- Talep hangi kanal üzerinden açılacak ve zorunlu bilgiler neler?
- Her öncelik seviyesinin iş etkisi ve örnek olayı nasıl tanımlanıyor?
- İlk yanıt, müdahale ve durum güncelleme hedefleri ayrı mı?
- Destek saatleri, resmi tatiller ve mesai dışı çağrı koşulları belli mi?
- Üçüncü taraf servisler, kullanıcı hataları ve planlı bakımlar nasıl ele alınıyor?
- Hizmet performansı hangi raporla ve hangi dönemde değerlendirilecek?
4. Yedek var demek neden tek başına yeterli değildir?
Yedekleme, dosyanın oluşturulmasından ibaret değildir. Hangi verinin ne sıklıkta yedeklendiği, kopyaların nerede tutulduğu, erişimin kimde olduğu ve ne kadar süre saklandığı bilinmelidir. En önemlisi geri yükleme süreci denenmelidir. Hiç test edilmemiş bir yedek, ihtiyaç anında eksik, bozuk veya uygulamayla uyumsuz çıkabilir. Kritik sistemlerde işletmenin tolere edebileceği veri kaybı ve hizmet kesintisi bakım tasarımını belirlemelidir.
Felaket senaryosu yalnızca sunucunun tamamen kaybolması değildir. Yanlış veri silme, hatalı güncelleme, hesap ele geçirilmesi veya entegrasyondan bozuk veri gelmesi de geri dönüş gerektirebilir. Bu nedenle uygulama kodu, veritabanı, kullanıcı dosyaları, yapılandırmalar ve altyapı tanımları birlikte değerlendirilir. Geri yükleme yetkisinin kimde olduğu ve işlem öncesi hangi onayın alınacağı da prosedürde yer almalıdır.
5. Küçük iyileştirmeler ve aylık kapasite nasıl yönetilmeli?
Canlı kullanımdan sonra metin değişikliği, küçük rapor düzenlemesi veya bir alanın zorunlu hâle getirilmesi gibi talepler oluşur. Bakım paketinde bu işler için aylık belirli bir kapasite ayrılabilir. Ancak “küçük iş” tanımı süre, risk veya kapsam ölçütüyle açıklanmalıdır. Kullanılmayan kapasitenin sonraki aya devredip devretmediği, acil hataların bu havuzdan düşüp düşmediği ve daha büyük taleplerin nasıl fiyatlandırılacağı baştan bilinmelidir.
Talepler tek bir kayıt sisteminde toplanmalı, iş etkisi ve beklenen sonuçla birlikte önceliklendirilmelidir. Mesajlaşma uygulamasında farklı kişilere gönderilen dağınık istekler hem unutulur hem raporlanamaz. Düzenli değerlendirme toplantısında açık hatalar, teknik riskler ve iyileştirme listesi birlikte ele alınır. Böylece bakım ekibi yalnızca en çok ses çıkaran talebe değil işletmeye en fazla değer veya risk azaltımı sağlayan işe odaklanabilir.
6. Bakım teklifi alırken hangi teslimleri istemelisiniz?
Bakım hizmetinin başlayabilmesi için teknik sahiplik görünür olmalıdır. Kod deposu, canlı ve test ortamları, alan adı ve DNS, sunucu, veritabanı, e-posta, üçüncü taraf servisler ve yönetici hesapları envanterlenir. Parolalar güvenli yöntemle paylaşılır; kişisel hesaplara bağlı kritik servisler mümkünse kurumsal sahipliğe taşınır. Yazılım başka ekipten devralınıyorsa önce kod kalitesi, güncellik, yedekler ve bilinen sorunlar incelenerek başlangıç risk raporu hazırlanması doğru olur.
- Sistem ve erişim envanteri ile sorumluluk matrisi
- Destek kanalı, öncelik tanımları ve SLA tablosu
- Yedekleme, geri yükleme ve planlı bakım prosedürü
- Güncelleme öncesi test ve canlıya alma yaklaşımı
- Aylık olay, müdahale, kapasite ve risk raporu
- Sözleşme bittiğinde kod, veri, dokümantasyon ve erişimlerin devir yöntemi
Fiyatları karşılaştırırken yalnızca aylık toplamı değil hizmet saatlerini, dâhil kapasiteyi, kritik olay yaklaşımını ve kapsam dışı kalemleri değerlendirin. Daha düşük bedelli bir paket izleme, yedek kontrolü veya mesai dışı müdahale içermiyorsa daha ucuz görünen teklif işletmenin ihtiyacını karşılamayabilir. Tersine, yalnızca birkaç kişinin kullandığı ve kısa kesintileri tolere edebilen iç sistem için ağır bir nöbet organizasyonu gereksiz olabilir. Doğru seviye, yazılımın iş durduğunda yaratacağı etkiye göre belirlenir.
Sonuç olarak özel yazılım bakımı, proje sonrasında belirsiz bir güvence bedeli değil canlı sistemin işletme modelidir. Hata, bakım, destek ve geliştirme ayrıldığında; SLA gerçek iş etkisine göre yazıldığında; yedek, izleme ve erişim sahipliği doğrulandığında iki taraf da ne bekleyeceğini bilir. Canlıya geçmeden önce bu planı hazırlamak, acil bir sorun sırasında ekip ve süreç aramaktan daha güvenli ve daha öngörülebilir bir yaklaşımdır.