Yazılım Bakım, Destek ve SLA Anlaşması Rehberi: Yazılımınızı Çalışır ve Güvende Tutun

SLA (Service Level Agreement / Hizmet Seviyesi Anlaşması), bakım hizmetinin ölçülebilir taahhütler bölümüdür: hangi öncelikteki soruna kaç saatte ilk yanıt verileceği, hedef çözüm süresi, hizmet penceresi ve taahhüde uyulmazsa uygulanacak yaptırım. Bakım anlaşması "ne yapılacağını", SLA ise "ne kadar sürede ve hangi güvenceyle yapılacağını" tanımlar; pratikte ikisi genellikle tek sözleşmede birleşir.

Tipik kapsam; hata giderme, güvenlik ve bağımlılık güncellemeleri, izleme, düzenli yedekleme, performans takibi ve aylık tanımlı saat havuzunda küçük değişikliklerdir. Kapsam dışında ise sıfırdan modül geliştirme, kapsamlı tasarım yenileme, üçüncü taraf yazılımların lisans ücretleri ve kullanıcı hatasından doğan işler kalır; bunlar ayrıca fiyatlanır. Sağlıklı bir sözleşmede her iki liste ve kapsam dışı işlerin birim saat ücreti açıkça yazılır.

Yazılım yayına alındıktan sonra çalıştığı ortam değişmeye devam eder: işletim sistemi ve kütüphane sürümleri güncellenir, yeni güvenlik açıkları duyurulur, entegre olunan banka, kargo ve pazaryeri servisleri API'lerini değiştirir, mevzuat yenilenir. Bakım yapılmayan yazılım bozulmasa bile ortamı ona uyumsuz hale gelir; ilk ciddi değişiklikte plansız ve pahalı bir acil müdahale gündeme gelir.

Tek bir liste fiyatı yoktur; sektörde yaygın referans, yıllık bakımın proje geliştirme bedelinin yaklaşık yüzde 10-20'si aralığında seyretmesidir. Fiyatı yukarı çeken etkenler; kısa SLA süreleri, 7/24 destek penceresi, sunucu yönetiminin dahil edilmesi, entegrasyon sayısı ve pakete dahil geliştirme saatleridir. Web sitelerinde bakım, hosting ve domain kalemlerinin ayrıntılı dökümünü bakım ve hosting maliyeti rehberimizde bulabilirsiniz.

Saat bankasında peşin bir destek saati havuzu (örneğin 10, 20 veya 30 saat) satın alınır; talepleriniz geldikçe bu havuzdan düşülür ve kullanılmayan saatlerin devri sözleşmeyle belirlenir. İş hacmi dalgalı, kesinti maliyeti düşük projelerde ekonomiktir. Dezavantajı, genellikle SLA taahhüdü içermemesi ve acil durumda sabit paketli müşterilerin öncelik almasıdır; kritik sistemler için sabit paket daha güvenlidir.

Asgari liste: kapsam ve kapsam dışı tablosu, öncelik sınıflarına göre SLA müdahale ve çözüm süreleri, SLA ihlalinde yaptırım, destek penceresi, ücret ve ödeme koşulları, gizlilik ve KVKK'ya uygun veri işleme, erişim yetkilendirme kuralları, hata bildirim usulü, fesih ve ihbar süresi ile fesih halinde kaynak kod, veri ve dokümantasyonun iade şekli. Bu maddeler netse taraflar arasında yorum farkı kalmaz.

Sözleşmede genellikle 30-60 günlük yazılı ihbar süresi tanımlanır; tacirler arasında bildirimin KEP veya noter kanalıyla yapılması ispat açısından güçlüdür. Fesihte kritik olan çıkış paketidir: güncel kaynak kod, veritabanı yedeği, sunucu ve alan adı erişimleri, kurulum dokümantasyonu ve varsa lisans devirleri eksiksiz teslim edilmelidir. Bu maddeyi imzadan önce pazarlık edin; ilişki bittikten sonra pazarlık gücünüz azalır.

Piyasada yaygın kurgu, kritik arızada (sistem durdu, ödeme alınamıyor) 1-4 saat içinde müdahale ve aynı gün çözüm hedefidir; normal talepler 1-3 iş gününe yayılır. Doğru süre kesintinin maliyetine göre seçilir: sipariş kaybının dakikalarla ölçüldüğü e-ticaret altyapılarında 7/24 pencere ve en kısa süreler gerekir. Edge Bilişim'de kritik bildirimler nöbetçi kanala düşer ve SLA sayacı, talep açıldığı anda işlemeye başlar.

Uptime, sistemin erişilebilir kaldığı zaman oranıdır ve SLA'da hedef olarak yazılabilir. Yüzde 99,9 taahhüdü yılda yaklaşık 8,7 saate kadar kesintiye izin verir; yüzde 99,99 ise bu sınırı yaklaşık 52 dakikaya indirir. Oran yükseldikçe yedeklilik ve izleme maliyeti arttığından, her sistem için en yükseği değil, kesinti maliyetinize uygun olanı hedeflemek doğrudur. Taahhüdün nasıl ölçüleceği ve ihlal yaptırımı da sözleşmede yazmalıdır.

Evet; buna devralma denir ve teknik incelemeyle başlar. Edge Bilişim'de bu süreç, kaynak kod ve erişim envanterinin müşterinin kendi hesapları altında toplanmasıyla açılıyor; yaklaşık iki haftalık incelemede bağımlılıklar, güvenlik açıkları ve eksik dokümantasyon raporlanıyor, ardından 30-60-90 günlük bir bakım planı sunuluyor. Rapor aşaması, taahhüde girmeden yazılımınızın gerçek durumunu görmenizi de sağlar.

Sağlıklı bakım ve geliştirme için evet; kod olmadan yapılabilecekler sunucu ve veritabanı seviyesindeki müdahalelerle sınırlı kalır. Kaynak kod eski geliştiricideyse önce sözleşmenizdeki fikri mülkiyet maddesine göre teslimini talep etmelisiniz. Kodun tamamen kayıp olduğu durumlarda ise mevcut sistem ayakta tutulurken kademeli yeniden yazma planlanır; bu, maliyetli ama bazen tek gerçekçi seçenektir.

Doğru süreçle bozmaz. Güncellemeler önce test (staging) ortamında denenir, kritik akışlar — giriş, ödeme, form gönderimi gibi — kontrol edilir, sonra sürümlenerek canlıya alınır ve sorun halinde geri alma (rollback) planı devreye girer. Sözleşmede test ortamının varlığını ve canlıya alma öncesi onay adımını şart koşmanız, "güncelleme sonrası bozulan sistem" riskini büyük ölçüde ortadan kaldırır.

Doğru kurgulanırsa yapmaz. Bağımsızlığın üç şartı vardır: kaynak kodun size ait bir depoda (ör. Git) durması, sunucu ve alan adı hesaplarının sizin adınıza açılması ve güncel kurulum dokümantasyonunun teslim edilmesi. Bu üçü sağlandığında istediğiniz an başka bir ekiple devam edebilirsiniz; bakım firması sizi rehin tutamaz, hizmetin kalitesiyle tutmak zorunda kalır.

Uyarlayıcı bakımın kapsamındadır: KVKK, e-fatura/e-arşiv ve sektörel mevzuat değişiklikleri yazılımı etkiliyorsa gerekli güncellemeler planlanır. Bazı sektörlerde bu ihtiyaç dönemseldir; örneğin beyanname takvimiyle yaşayan mali müşavir ve muhasebe ofisi siteleri e-belge entegrasyonlarındaki değişikliklerden doğrudan etkilenir. Büyük mevzuat dönüşümlerinin bakım paketine mi, ayrı geliştirmeye mi girdiğini sözleşmede netleştirin.

Sitenin işlevine göre değişir. İçeriği seyrek güncellenen bir inşaat firması proje vitrini için güncelleme, yedekleme ve güvenlik içeren yıllık temel paket çoğu zaman yeterlidir. Randevu, ödeme veya üyelik gibi canlı işlem yürüten sitelerde ise kesinti doğrudan gelir kaybı demektir; SLA'lı aylık paket ve izleme şart hale gelir. Kural basit: site para veya randevu üretiyorsa bakım bütçesi de ona göre kurulmalıdır.