Yazılım Yayına Alındıktan Sonra: Bakım, Destek ve SLA'da Nelere Dikkat Etmeli?

Kısaca: Yazılım bir kez yapılıp bırakılan bir ürün değil, yaşayan bir sistemdir: işletim sistemleri, kütüphaneler ve tarayıcılar sürekli güncellenir, güvenlik açıkları keşfedilir, kullanıcı ihtiyaçları değişir. Bakım ve destek bu yüzden bir “ek masraf” değil, yazılımın güvenli, hızlı ve çalışır kalması için gerekli sürekli işletme maliyetidir. İyi bir bakım ve destek planı şunları net yazar: neleri kapsıyor (hata düzeltme, güvenlik güncellemesi, yedekleme, izleme, küçük geliştirme), ne kadar sürede yanıt verilecek ve ne kadar sürede çözülecek (SLA), kimlerle ve hangi kanaldan iletişim kurulacağı ve ne kadar ücretlendirileceği. Sözleşmeyi imzalamadan önce bu maddeleri yazılı hale getirin.

Son güncelleme: Ekim 2026

Yayına çıkmak bitiş değil, başlangıçtır

Yeni bir web uygulaması, e-ticaret sitesi veya mobil uygulama yayına girdiğinde ilk günlerde her şey yolunda görünür. Ancak aylar içinde şunlar yaşanır:

• Kullanılan kütüphanelerde güvenlik açıkları bulunur ve yama yayınlanır.
• Tarayıcı ve işletim sistemi güncellemeleri bazı özellikleri bozabilir.
• Kullanıcı ve veri arttıkça performans düşebilir.
• Sunucu, veritabanı veya üçüncü taraf servislerde (ödeme, e-posta, SMS, harita) kesinti ve değişiklikler olur.
• İşletmenizin süreçleri değişir; yeni ihtiyaçlar ortaya çıkar.

Bakımsız bir yazılım, “bir gün” aniden bozulmaz; yavaş yavaş eskir ve riskli hale gelir. Sonra sorun çıktığında ise çözmek hem pahalı hem acil olur.

Dört bakım türü

Bakım tek bir kavram değildir; dört ana türü vardır:

Teklif veya sözleşmede “bakım” yazıyorsa, hangi türlerin dahil olduğunu mutlaka sorun. Birçok firma yalnızca düzeltici bakımı “garanti” kapsamında tutar; önleyici ve geliştirici bakım ayrıca ücretlendirilir.

Garanti ile bakım aynı şey değil

• Garanti süresi: Teslimden sonra belirli bir süre (ör. birkaç ay) teslim edilen kapsamdaki hataların ücretsiz düzeltilmesidir. Yeni özellik, değişiklik veya üçüncü taraf kaynaklı sorunlar çoğunlukla kapsam dışıdır.
• Bakım ve destek: Garanti sonrasında sürekli bir hizmettir; kapsamı ve ücreti sözleşmeyle belirlenir.

Garantinin başlangıcının neye bağlı olduğunu (yayın tarihi mi, kabul tarihi mi?) ve nelerin kapsam dışında kaldığını yazılı netleştirin.

Bir bakım ve destek planında bulunması gereken 10 unsur

1. Güvenlik güncellemeleri ve bağımlılık yönetimi

Kullanılan çerçeve, kütüphane ve sunucu bileşenlerinin düzenli güncellenmesi en önemli önleyici bakımdır. Bilinen açıklar bu şekilde kapatılır. Hangi sıklıkta kontrol edildiğini ve kritik açıklarda nasıl hareket edildiğini sorun. Güvenlik konusunda web uygulaması güvenliği rehberimize göz atabilirsiniz.

2. Yedekleme ve geri yükleme

Yedek almak yetmez; geri yüklenebildiğini test etmek gerekir. Şunları netleştirin:

• Hangi veriler yedekleniyor (veritabanı, dosyalar, yapılandırma)?
• Hangi sıklıkta (günlük, saatlik)?
• Yedekler nerede saklanıyor; ana sistemden ayrı bir konumda mı?
• Geri yükleme düzenli test ediliyor mu?

Yedek stratejisi için yaygın bir ilke 3-2-1'dir: verinin en az üç kopyası, iki farklı ortamda, bir tanesi farklı bir konumda.

3. İzleme (monitoring) ve uyarı

Sistem kapandığında ilk fark eden müşteriniz olmamalı. İyi bir plan şunları izler:

• Sitenin/uygulamanın erişilebilirliği (uptime)
• Hata kayıtları ve beklenmedik istisnalar
• Sunucu kaynakları (işlemci, bellek, disk)
• Sayfa hızı ve temel performans göstergeleri
• SSL sertifikası ve alan adı süresi gibi “unutulan” tarihler

Uyarıların kime, hangi kanaldan gideceği de planda yazılı olmalıdır.

4. Hata düzeltme süreci

Hata nasıl bildirilecek (e-posta, destek paneli, telefon)? Kim değerlendirecek? Önceliği nasıl belirlenecek? Düzeltme nasıl test edilip yayına alınacak?

5. SLA: Yanıt süresi ve çözüm süresi

SLA (Service Level Agreement — hizmet seviyesi sözleşmesi), destek hizmetinin ölçülebilir taahhütlerini tanımlar. İki süreyi karıştırmayın:

• Yanıt süresi: Talebinize ilk geri dönüş süresi.
• Çözüm süresi: Sorunun giderilme süresi.

Süreler genellikle önceliğe göre tanımlanır:

Ayrıca çalışma saatlerini (mesai içi mi, 7/24 mü?) ve tatil günlerinde nasıl çalışıldığını sorun. “Kritik” bir sorun için mesai dışında da ulaşabilmek, işletmenizin tipine göre kritik olabilir.

6. Erişilebilirlik (uptime) hedefi

Bazı sözleşmelerde “%99,9 erişilebilirlik” gibi bir hedef geçer. Bu rakamın neyi ölçtüğünü (planlı bakım dahil mi?), nasıl ölçüldüğünü ve hedef tutmazsa ne olacağını (hizmet kredisi vb.) öğrenin. Hedef, altyapı ve bütçeyle uyumlu olmalıdır; her proje için %99,99 gerekmez ve pahalıdır.

7. Felaket kurtarma: RTO ve RPO

• RTO (Recovery Time Objective): Bir kesintiden sonra sistemin en geç ne kadar sürede tekrar çalışır hale getirilmesi hedeflenir?
• RPO (Recovery Point Objective): En kötü durumda ne kadarlık veri kaybı kabul edilebilir? (Örn. son 1 saat.)

Bu iki hedef, yedekleme sıklığını ve altyapı maliyetini belirler. İşletmeniz için kabul edilebilir kayıp ve kesinti süresini önceden konuşun.

8. Küçük geliştirme ve değişiklik talepleri

Bakım paketine aylık belirli bir saat bankası dahil mi? Dahil değilse küçük değişiklikler nasıl fiyatlanıyor? Hangi talepler “bakım”, hangileri “yeni proje” sayılıyor? Bu sınır net değilse tartışma çıkar.

9. Dokümantasyon ve bilgi devri

Sistemin mimarisi, kurulumu, yapılandırması ve kritik prosedürleri yazılı olmalı. Ekip değişse bile sürekliliğin sağlanması için dokümantasyon güncel tutulmalı; kaynak kod, hesaplar ve şifreler sizin kontrolünüzde olmalıdır.

10. Raporlama

Aylık veya üç aylık kısa bir bakım raporu isteyin: yapılan güncellemeler, çözülen talepler, çalışma süresi, tespit edilen riskler ve öneriler. Bu, hem şeffaflık sağlar hem de gelecek bütçeyi planlamanıza yardım eder.

Bakım ücretlendirme modelleri

Genel kural olarak, ürününüz işinizin merkezindeyse (e-ticaret, SaaS, operasyon yazılımı) sürekli bir paket, küçük ve durağan bir kurumsal site için ise daha hafif bir plan yeterli olabilir. Fiyatlandırma modellerinin ayrıntıları için yazılım projesi fiyatlandırma modelleri yazımıza bakabilirsiniz.

Bakımı ihmal etmenin gerçek maliyeti

Bakım bütçesi ayırmak maliyet gibi görünür; ancak ihmalin faturası genellikle daha büyük gelir:

• Güvenlik olayları: Güncellenmeyen bir bileşendeki açık, veri sızıntısına yol açabilir; kişisel veri söz konusuysa hukuki yükümlülükler doğar.
• Kesinti: Satış yapılamayan her saat gelir kaybıdır.
• Teknik borç: Güncellenmeyen sistem büyüdükçe değiştirmesi zorlaşır; sonunda büyük ve pahalı bir yeniden yazım gerekebilir.
• İtibar: Yavaş, hata veren bir sistem müşteri güvenini ve arama sıralamasını etkiler.

Pratik bir çerçeve: yıllık bakım ve işletme bütçenizi “sıfır” olarak bırakmayın; ürünün kritiklik düzeyine göre makul bir pay ayırın. Kesin oran projeye göre değişir; teklifteki bakım kalemini kapsam ve SLA ile birlikte değerlendirin.

Sözleşme öncesi kontrol listesi

• Bakım kapsamı yazılı: düzeltici, önleyici, uyarlayıcı, geliştirici hangileri dahil?
• SLA: öncelik seviyeleri, yanıt ve çözüm süreleri, çalışma saatleri net mi?
• Yedekleme: sıklık, saklama yeri, geri yükleme testi tanımlı mı?
• İzleme ve uyarı: neler izleniyor, kime bildirim gidiyor?
• Güvenlik güncellemeleri: hangi sıklıkta, kritik açıklarda süre nedir?
• RTO/RPO hedefleri konuşuldu mu?
• Küçük değişiklikler için saat bankası veya fiyat belirlendi mi?
• Dokümantasyon ve hesap/kod mülkiyeti sizde mi?
• Raporlama sıklığı ve içeriği belli mi?
• Sözleşme süresi, yenileme ve fesih koşulları açık mı?

Firma seçiminin bütününü ele alan yazılım firması seçerken sorulacak 15 soru rehberimizde de bakım ve destek sorusuna yer verdik.

Aktaş Digital'de destek ve bakım

Geliştirdiğimiz yazılımların yayına alınmasıyla işimizin bitmediğini biliyoruz. Projeye göre güncelleme, yedekleme, izleme, hata düzeltme ve geliştirme kalemlerini kapsayan destek ve bakım planları sunuyoruz; kapsam ve ücretler teklifte açıkça belirtiliyor. Web uygulamaları, SaaS platformları, e-ticaret çözümleri ve operasyon yönetimi sistemleri gibi sürekli çalışan sistemlerde bu planlar ürünün güvenliğini ve sürekliliğini sağlıyor.

Mevcut bir sisteminiz için bakım ve destek mi arıyorsunuz, yoksa yeni bir proje için bakım planını baştan mı yapmak istiyorsunuz? Teklif formumuz üzerinden durumunuzu anlatabilirsiniz.

Sık Sorulan Sorular

Bakım sözleşmesi şart mı?

Yasal bir zorunluluk değildir; ancak sürekli çalışan ve iş için kritik bir yazılımda önerilir. Sözleşmesiz yaklaşımda sorun çıktığında kime, ne kadar sürede ulaşacağınız belirsiz kalır ve çözüm genellikle daha pahalıya gelir.

Garanti süresince bakım ücreti öder miyim?

Garanti, teslim edilen kapsamdaki hataların ücretsiz düzeltilmesini kapsar. Yeni özellik, değişiklik veya sizin tarafınızdan yapılan müdahaleler kaynaklı sorunlar genelde kapsam dışıdır. Sözleşmedeki garanti maddesini dikkatle okuyun.

Küçük bir kurumsal site için de SLA gerekir mi?

Çoğu zaman ayrıntılı bir SLA gerekmez; ancak yedekleme, güvenlik güncellemesi ve hata bildirimi için kimin sorumlu olduğunu bilmek yine de önemlidir. Hafif bir plan yeterli olabilir.

Bakım için başka bir firmaya geçebilir miyim?

Kaynak kod, dokümantasyon ve hesap erişimleri sizdeyse evet. Bu yüzden proje başında mülkiyet ve erişim konularını netleştirmek, bakım firmasını değiştirme özgürlüğünüzü korur.

Mesai dışında acil destek şart mı?

İşletmenizin yapısına bağlıdır. Online satış yapan veya 7/24 çalışan bir sistemde kritik sorunlar için mesai dışı erişim önemlidir; yalnızca mesai saatlerinde kullanılan iç sistemlerde daha esnek bir plan yeterli olabilir.

Bakımın ne kadarı yapay zekâ ile yapılabilir?

İzleme, log analizi ve rutin kontroller otomasyonla desteklenebilir; ancak güvenlik kararları, üretime alma ve kritik hataların çözümü hâlâ deneyimli mühendislik ve sorumluluk gerektirir. Otomasyon süreci hızlandırır, yerine geçmez.

Sonuç

Yazılım bakımı, bir arabanın periyodik bakımı gibidir: yapıldığında fark edilmez, ihmal edildiğinde pahalıya patlar. Bakım türlerini, SLA maddelerini, yedekleme ve izleme düzenini ve ücret modelini yazılı sözleşmeye bağlayın; yayın sonrasında kimin neden sorumlu olduğu bilinsin. Bugün yapabileceğiniz ilk iş: mevcut sisteminiz için “bir sorun çıkarsa kime, nereden, ne kadar sürede ulaşırım?” sorusunun cevabını yazıp eksikleri listelemek.