Yazılım Bakım ve Destek Sözleşmesinde Hangi Teknik Hizmetler Olmalı?

Yazılım canlıya çıktıktan sonra yalnız kritik hata oluştuğunda geliştirici aramak sürdürülebilir bakım modeli değildir. Özellikle şirket operasyonunu taşıyan uygulamalarda destek kapsamı ve sorumluluklar önceden tanımlanmalıdır.

Teknik bakım; incident çözümünden güvenlik güncellemelerine, monitoring’den dependency yönetimine kadar farklı hizmetleri kapsayabilir.

Corrective Maintenance

Üretim ortamında tespit edilen bug ve beklenmeyen davranışların giderilmesidir. Hata önem seviyeleri önceden tanımlanmalıdır.

Preventive Maintenance

Hata oluşmadan dependency, framework, sertifika, disk kapasitesi veya altyapı risklerinin düzenli kontrol edilmesini kapsar.

Security Updates

Framework, paket ve işletim sistemi güvenlik güncellemelerinin hangi sürede uygulanacağı destek planında bulunmalıdır.

Monitoring

• Uptime
• HTTP hata oranı
• Application error
• CPU ve RAM
• Disk
• Queue
• Database bağlantısı
• Dış API hataları

SLA Seviyeleri

P1 kritik kesinti ile küçük görsel hata aynı SLA kapsamında değerlendirilmemelidir. Response time ve resolution target ayrı tanımlanabilir.

Backup ve Restore

Backup alınması kadar restore prosedürünün test edilmesi de önemlidir. Kullanılamayan backup gerçek koruma sağlamaz.

Dependency ve Runtime Yönetimi

PHP, Node, framework, database veya diğer runtime sürümleri EOL takvimlerine göre izlenmelidir.

Change Request

Yeni özellik geliştirme ile bakım hizmeti birbirinden ayrılmalıdır. Küçük change request için aylık kapasite modeli kullanılabilir.

Raporlama

• Açılan incident sayısı
• Ortalama response time
• Ortalama çözüm süresi
• Uptime
• Deployment sayısı
• Güvenlik güncellemeleri
• Açık teknik borç

Proje Kararını Nasıl Operasyonlaştırmalı?

Yazılım Bakım ve Destek Sözleşmesinde Hangi Teknik Hizmetler Olmalı? konusu gerçek bir projede değerlendirilirken Corrective Maintenance, Preventive Maintenance ve Security Updates aynı karar zincirinin parçaları olarak ele alınmalıdır. Teknik ekip yalnız yapılacak fonksiyonları değil; veri kaynaklarını, kullanıcı rollerini, güvenlik sınırlarını, entegrasyon bağımlılıklarını ve başarının hangi metriklerle ölçüleceğini de netleştirmelidir. Bu bilgiler backlog, acceptance criteria ve teknik risk listesine dönüştürüldüğünde proje ilerlemesi kişisel yorum yerine ölçülebilir çıktılar üzerinden takip edilebilir.

Özellikle kurumsal yazılım projelerinde kısa vadede çalışan çözüm ile uzun vadede sürdürülebilir sistem aynı şey değildir. Kodun test edilebilirliği, deployment süreci, loglama, monitoring, veri migration planı ve gerektiğinde rollback kabiliyeti başlangıç mimarisinin parçası olmalıdır. Bu yaklaşım geliştirme hızını yavaşlatmak yerine sonraki sürümlerde oluşabilecek yeniden geliştirme ve operasyon maliyetini kontrol altında tutar.

Uygulama Kontrol Listesi ve Teknik Riskler

Yazılım Bakım ve Destek Sözleşmesinde Hangi Teknik Hizmetler Olmalı? konusu gerçek projeye dönüştürülürken yalnız fonksiyon listesinin hazırlanması yeterli değildir. Özellikle Corrective Maintenance, Preventive Maintenance ve Security Updates kararları teknik tasarımın ilk aşamasında açık biçimde kayıt altına alınmalıdır. Her kritik gereksinim için sorumlu ekip, veri kaynağı, beklenen sistem davranışı, hata senaryosu ve kabul kriteri tanımlanmalıdır. Bu yöntem geliştirme başladıktan sonra ortaya çıkan kapsam tartışmalarını azaltır ve ürün, yazılım, operasyon ve iş birimleri arasında ortak bir referans oluşturur.

Teknik risk tarafında entegrasyon bağımlılıkları, kullanıcı yetkilendirmesi, veri bütünlüğü, üçüncü taraf servis kesintileri ve ölçek beklentisi ayrı başlıklar halinde değerlendirilmelidir. Örneğin dış API kullanan bir sistemde yalnız başarılı response senaryosu değil; timeout, rate limit, duplicate request, veri uyuşmazlığı ve geçici servis kesintisi gibi durumlar da tasarlanmalıdır. Benzer şekilde kritik işlemlerde audit log, rollback veya yeniden deneme mekanizması bulunması operasyon ekibinin hata sonrası sistemi güvenli biçimde toparlamasını kolaylaştırır.

Canlıya geçişten önce performans ve güvenlik hedefleri de ölçülebilir hale getirilmelidir. Hangi işlemin kaç saniyede tamamlanması gerektiği, hangi kullanıcı rolünün hangi veriye erişebileceği, logların ne kadar süre saklanacağı ve uygulama hatalarının nasıl izleneceği belirlenmelidir. Deployment sonrasında application log, error tracking, database performansı, queue durumu ve kritik dış servislerin gecikme değerleri takip edildiğinde teknik ekip yalnız kullanıcı şikâyetine bağlı kalmadan problemi erken görebilir. Bu yaklaşım yazılımı tek seferlik proje yerine sürdürülebilir dijital ürün olarak yönetmenin temelini oluşturur.

• Fonksiyon ve acceptance criteria eşleşmesi
• Yetki ve veri erişim kontrolü
• API ve entegrasyon hata senaryoları
• Backup ve rollback yaklaşımı
• Monitoring ve error tracking
• Performans ve kapasite hedefleri

Sıkça Sorulan Sorular

Bakım hizmeti ile yeni özellik geliştirme aynı şey midir?

Hayır. Bakım mevcut sistemin sürdürülebilirliğine, yeni geliştirme ise kapsam değişikliğine odaklanır.

SLA neyi belirler?

Öncelik seviyesine göre müdahale ve hedef çözüm sürelerini tanımlar.

Backup almak yeterli midir?

Hayır. Backup’ın gerçekten geri yüklenebilir olduğu periyodik olarak doğrulanmalıdır.

Yazılım güncellenmeden yıllarca çalışabilir mi?

Çalışabilir ancak güvenlik ve uyumluluk riski zaman içinde önemli ölçüde artabilir.

İlgili İçerikler

• Web Sitesi Yenileme Stratejileri: Audit, Refactor, Incremental Migration
• Startup’lar İçin Minimum Dijital Altyapı: Domain’den Veri Güvenliğine
• API-First Geliştirme: Backend’i Ayrıştırmak, Uygulamayı Çoklu Kanal Yapmak