> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/ozel-yazilimda-bakim-anlasmasi-neleri-kapsamali*

---

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

*Yayın Tarihi: 2026-09-12 14:00:01*

Ö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.
**Kısa cevap:** Özel yazılımda bakım anlaşması; hata düzeltme, güvenlik güncellemeleri, performans takibi, yedekleme kontrolü, destek kanalları, yanıt süreleri, öncelik seviyeleri, küçük iyileştirme kapsamı, entegrasyon izleme, raporlama, versiyon yönetimi ve kapsam dışı işleri açık şekilde tanımlamalıdı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](https://www.iso.org/standard/39064.html). 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](/ozel-web-yazilim-hizmeti) 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.
Talep türüBakım kapsamında olabilirAyrı geliştirme olabilirHata düzeltmeMevcut fonksiyon beklenen şekilde çalışmıyorsaBeklenmeyen yeni davranış isteniyorsaKüçük iyileştirmeMetin, küçük alan düzeni, basit filtre gibi sınırlı değişikliklerYeni modül, yeni ekran veya yeni iş akışıGüvenlikBağımlılık güncellemesi, erişim kontrolü düzeltmesiKapsamlı güvenlik mimarisi değişikliğiEntegrasyonMevcut API hatasının izlenmesi ve küçük uyarlamaYeni muhasebe, ödeme veya CRM entegrasyonuRaporlamaMevcut raporda hesaplama hatası düzeltmeYeni KPI seti veya dashboard tasarımı

## 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](/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](https://sre.google/sre-book/service-level-objectives/). 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](https://owasp.org/www-project-application-security-verification-standard/). 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](/web-sitesi-ve-yazilimlarinizin-guvenligini-nasil-sagliyorsunuz) 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.
BaşlıkAnlaşmada sorulması gereken soruNeden önemli?Yedek sıklığıGünlük, saatlik veya işlem bazlı mı?Olası veri kaybı aralığını belirlerSaklama süresiYedekler kaç gün veya ay tutulacak?Geç fark edilen hatalarda geri dönüş sağlarGeri yükleme testiYedek gerçekten çalışıyor mu?Bozuk yedek riskini azaltırSorumlulukHosting, müşteri veya yazılım ekibi neyi üstleniyor?Arıza anında rol karmaşasını önlerKritik veriHangi veri mutlaka korunmalı?İş sürekliliğini etkiler
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](https://sre.google/sre-book/service-level-objectives/). Ö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](/api-entegrasyon-hizmeti) 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](/yazilim-maliyetleri-neye-gore-belirlenir) 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](https://sre.google/sre-book/postmortem-culture/). 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:
Rapor alanıİçerikFaydasıTalep özetiAçılan, çözülen, bekleyen taleplerDestek yükünü görünür kılarHata kategorileriKritik, yüksek, orta, düşük dağılımıRiskli modülleri gösterirGüncellemelerYayınlanan versiyonlar ve değişikliklerŞeffaflık sağlarGüvenlikYama, yetki kontrolü, kritik uyarılarRisk takibini güçlendirirÖnerilerYeni geliştirme veya iyileştirme ihtiyaçlarıRoadmap planlamasına yardımcı olur

## 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.

## Yazılım bakım kapsamınızı netleştirin
Mevcut özel yazılımınız veya yeni projeniz için bakım, destek, güvenlik, yedekleme ve iyileştirme kapsamını birlikte planlayabiliriz.[Projemi Değerlendir](/iletisim)

## Sıkça Sorulan Sorular

### Özel yazılım bakım anlaşması nedir?

Özel yazılım bakım anlaşması, canlı yazılımın hata düzeltme, güvenlik güncellemesi, izleme, yedekleme kontrolü, destek kanalı, yanıt süresi ve küçük iyileştirme kapsamını belirleyen çalışma çerçevesidir.

### Bakım anlaşması yeni geliştirmeleri kapsar mı?

Her bakım anlaşması yeni geliştirmeleri kapsamaz. Küçük iyileştirmeler belirli saat veya talep limiti içinde dahil edilebilir; ancak yeni modül, yeni entegrasyon, kapsamlı arayüz değişimi veya büyük iş akışı genellikle ayrı proje olarak değerlendirilmelidir.

### Bakım anlaşmasında SLA olmalı mı?

Evet, yanıt süresi, destek saatleri ve öncelik seviyeleri net olmalıdır. Ancak çözüm süresi hatanın kaynağına, üçüncü taraf servis bağımlılıklarına ve iş etkisine göre ayrıca tanımlanmalıdır.

### Güvenlik güncellemeleri bakım kapsamına dahil edilmeli mi?

Evet. Kullanılan framework, kütüphane, sunucu bileşeni, yetki yapısı ve kritik güvenlik yamaları bakım sürecinde izlenmelidir. Güvenlik güncellemelerinin tamamen kapsam dışı bırakılması canlı yazılım için risk oluşturur.

### Yedekleme bakım anlaşmasında nasıl ele alınmalı?

Yedeklerin hangi sıklıkta alınacağı, nerede saklanacağı, ne kadar süre tutulacağı, kimin sorumlu olduğu ve geri yükleme testinin nasıl yapılacağı yazılı olmalıdır. Yedekleme sorumluluğu belirsiz bırakılmamalıdır.

### Bakım anlaşmasında kapsam dışı işler neden yazılmalı?

Kapsam dışı işler yazılmazsa beklenti belirsizliği oluşur. Yeni modül, büyük tasarım değişikliği, yeni entegrasyon, veri temizliği, üçüncü taraf servis ücretleri veya içerik girişi gibi işler açıkça ayrıldığında süreç daha sağlıklı yönetilir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/ozel-yazilimda-bakim-anlasmasi-neleri-kapsamali