Özel yazılım projeleri canlıya alındığında iş bitmez; asıl operasyon ondan sonra başlar. Kurum içinde kullanılan bir ERP entegrasyonu, saha ekiplerinin kullandığı mobil uygulama ya da müşteri portalı olması fark etmez. Kullanıcı davranışları değişir, yeni mevzuatlar gelir, üçüncü taraf servisler sürüm yükseltir, yük profili de beklenmedik şekilde artabilir. İşte tam bu noktada yazılım bakım ve destek modeli devreye girer.

İyi kurgulanmış bir bakım yapısı yalnızca arıza çözmek için kurulmaz. Amaç; hizmet sürekliliğini korumak, riskleri sınıflandırmak, değişiklikleri kontrollü biçimde yayınlamak ve ekipler arasındaki beklentileri yazılı hale getirmektir. Özellikle birden fazla entegrasyonu olan sistemlerde destek sürecinin sözlü ilerlemesi ciddi maliyet yaratır. Örneğin ödeme altyapısı, e-fatura servisi ve CRM arasında çalışan bir platformda tek bir API değişikliği 2 saat içinde fark edilmezse sipariş akışı tamamen durabilir.

Bu yazıda pratik bir çerçeve kuracağız: SLA nasıl yazılır, hatalar nasıl önceliklendirilir, sürüm yönetimi nasıl yürütülür, hangi metrikler takip edilmelidir? Amaç teorik bir şablon sunmak değil; gerçek projelerde uygulanabilecek, sınırları net bir model önermektir.

SLA neden sadece yanıt süresi değildir?

Birçok ekip SLA'yi yalnızca “kaç dakikada dönüş yapılacak” diye tanımlar. Oysa bu eksik bir yaklaşımdır. Destek kalitesi sadece ilk cevabın hızına bağlı değildir; çözüm süresi, geçici aksiyonlar, iletişim ritmi ve kapsam sınırları da belirleyicidir. 15 dakikada dönüş yapıp sorunu 3 gün boyunca çözemeyen bir model, operasyonel açıdan güçlü kabul edilmez.

Pratik bir SLA dokümanında en az şu başlıklar yer almalıdır:

  • Hizmet saati: Örneğin hafta içi 09:00–18:00 veya 7/24 kritik destek.
  • İlk yanıt süresi: P1 için 15 dakika, P2 için 1 saat gibi.
  • Hedef çözüm süresi: Örneğin P1 için 4 saat içinde workaround, 24 saat içinde kalıcı çözüm planı.
  • Kapsam: Hata düzeltme, izleme, küçük iyileştirme, sürüm yayını dahil mi?
  • Hariç tutulan kalemler: Yeni modül geliştirme, büyük UI revizyonu, veri temizliği gibi işler destekten ayrı tanımlanmalı.
  • Eskalasyon akışı: Hangi dakikada teknik lider, hangi aşamada ürün sahibi bilgilendirilir?

Buradaki kritik ayrım şudur: SLA, bir performans sözü olduğu kadar kapsam sözleşmesidir de. Eğer “küçük geliştirme” tanımı net yapılmazsa her iş destek kanalına düşer. Bir buton rengi değişikliğiyle çok adımlı stok algoritması revizyonu aynı kuyruğa girer. Birkaç ay sonra destek ekibi yangın söndürmeye, ürün ekibi ise backlog savunmaya başlar.

Örnek SLA tablosu nasıl görünmeli?

Aşağıdaki yapı, orta ölçekli kurumsal projelerde sıkça kullanılır:

  • P1 - Kritik kesinti: Sistem tamamen çalışmıyor, gelir kaybı veya operasyon durması var. İlk yanıt 15 dk, geçici çözüm 4 saat.
  • P2 - Yüksek etki: Ana fonksiyonlardan biri bozuk, alternatif yol kısıtlı. İlk yanıt 30 dk, hedef çözüm 1 iş günü.
  • P3 - Orta etki: İş akışı devam ediyor ama verim düşüyor. İlk yanıt 4 saat, çözüm 3 iş günü.
  • P4 - Düşük etki: Görsel hata, küçük kullanım kusuru, içerik problemi. İlk yanıt 1 iş günü.

Bu süreler mutlak standartlar değildir; sektör, kullanıcı sayısı ve çalışma saatlerine göre değişir. Sağlık, lojistik veya ödeme sistemlerinde eşikler daha sıkı olabilir. İç iletişim portalında ise daha esnek bir yapı kabul edilebilir.

Hata önceliklendirme için etki ve aciliyet matrisi

Destek süreçlerinde en sık yaşanan sorunlardan biri, herkesin kendi işini kritik görmesidir. Bunun çözümü sezgisel tartışmalar değil, ortak bir karar matrisidir. En kullanışlı yaklaşım, etki ve aciliyet eksenlerini bir araya getirmektir.

Basit bir puanlama modeli uygulanabilir. Etkiyi 1 ile 5 arasında, aciliyeti de yine 1 ile 5 arasında puanlayın. Toplam skor yerine çarpım kullanmak daha keskin sonuçlar verir. Örnek:

priority_score = impact * urgency

if score >= 20: P1
elif score >= 12: P2
elif score >= 6: P3
else: P4

Bu kod tek başına yeterli değildir; karar kuralları da yazılı olmalıdır. Örneğin 50 kullanıcının kullandığı bir rapor ekranı bozuksa etki sınırlı kalabilir. Ancak sipariş oluşturma adımı çalışmıyorsa kullanıcı sayısı az olsa bile gelir akışı durduğu için P1 değerlendirmesi gerekir.

Önceliklendirme kurallarını yazılı hale getirin

Uygulanabilir bir çerçevede şu kriterler açıkça tanımlanmalıdır:

  • Etkilenen kullanıcı oranı: Tüm kullanıcılar mı, belirli bir rol mü, tek bir müşteri mi?
  • İş etkisi: Satış duruyor mu, veri kaybı var mı, manuel alternatif mevcut mu?
  • Regülasyon ve güvenlik: Kişisel veri riski veya mevzuat ihlali varsa öncelik otomatik yükselir.
  • Zaman bağımlılığı: Ay sonu kapanış, kampanya günü, sevkiyat saati gibi iş takvimi etkileri.

Gerçek bir senaryo düşünelim: B2B sipariş platformunda “favori ürünler” alanı görünmüyor. Kullanıcı deneyimi bozulur ama sipariş alınabiliyordur; bu sorun çoğu durumda P3 veya P4 olur. Aynı gün 17:00 sevkiyat kesim saatinden önce “sipariş onayla” adımı hata veriyorsa, zaman baskısı nedeniyle olay P1 düzeyine çıkabilir. Hatanın teknik tipi değil, iş etkisi belirleyicidir.

Bakım kapsamını dört hatta ayırmak işleri netleştirir

Tek bir destek kuyruğu, zamanla tüm taleplerin birbirine karıştığı bir yapıya dönüşür. Daha sağlıklı yöntem, bakım ve destek işlerini 4 ayrı hatta toplamaktır. Bu ayrım hem raporlamayı kolaylaştırır hem de kapasite planını daha gerçekçi hale getirir.

1) Olay yönetimi

Canlı ortamda oluşan bozulmalar bu hatta ele alınır. Alarm, log inceleme, hatanın tekrar üretilmesi, geçici çözüm ve kalıcı düzeltme burada yürütülür. Hedef süreler saat bazında tanımlanır. Örneğin CPU kullanımının 10 dakika boyunca %90 üstünde kalması bir alarm üretip olay kaydı açabilir.

2) Problem yönetimi

Burada odak, aynı hatanın tekrar etmesini engellemektir. P1 olayını çözdükten sonra kök neden analizi yapılmıyorsa destek ekibi her ay aynı sorunla karşılaşır. Bu aşamada 5 Why, log korelasyonu ya da dependency incelemesi gibi yöntemler kullanılır. Haftalık 30 dakikalık bir problem inceleme oturumu bile fark yaratır.

3) Küçük iyileştirmeler

2 saat ile 1 gün arasında tamamlanabilecek değişiklikler için ayrı bir mini backlog açılmalıdır. Alan adı güncellemesi, rapor filtre ekleme, hata mesajı iyileştirme gibi işler buna örnektir. Bu hattın sprint kapasitesi örneğin %15 ile sınırlandırılabilir.

4) Planlı bakım ve teknik borç

Kütüphane güncellemeleri, sertifika yenileme, log rotasyonu, indeks optimizasyonu, test iyileştirmeleri bu başlık altında toplanır. Dışarıdan görünmez ama ihmal edilirse 6-12 ay içinde sistem kırılgan hale gelir. Özellikle güvenlik yamaları için aylık rutin bir pencere tanımlanması faydalıdır.

Sürüm yönetiminde hedef hız değil, öngörülebilirlik

Canlı sistemlerde destek kalitesini belirleyen unsurlardan biri de sürüm disiplinidir. Düzensiz yayın yapan ekipler bakım yükünü artırır. Her sürüm küçük bir operasyon olduğundan, yayın süreci tekrar edilebilir ve izlenebilir olmalıdır.

Kurumsal projelerde sık kullanılan pratik bir model şöyledir:

  • Haftalık planlı sürüm: Düşük riskli iyileştirmeler ve doğrulanmış hata düzeltmeleri yayınlanır.
  • Aylık bakım sürümü: Altyapı güncellemeleri, bağımlılık yükseltmeleri, performans düzenlemeleri eklenir.
  • Acil hotfix akışı: Sadece P1/P2 olaylar için kullanılır; normal backlog'u bypass eder.

Her sürüm için en az şu artefaktlar tutulmalıdır: değişiklik listesi, etkilenen modüller, rollback planı, veritabanı migration adımları, test sonucu, yayın saati. Özellikle veritabanı değişikliği içeren sürümlerde rollback planı yazılmadan yayına çıkmak ciddi risk taşır. 3 dakikalık deployment kazanmak için geri dönüş kabiliyetinden vazgeçilmemelidir.

Semantik sürümleme ve değişiklik notu

Basit bir sürüm standardı, kafa karışıklığını azaltır. Örneğin v2.4.1 yapısında major.minor.patch yaklaşımı kullanılabilir. Patch hata düzeltmelerini, minor geriye uyumlu özellikleri, major ise kırıcı değişiklikleri temsil eder. Bu model özellikle API kullanan projelerde kritiktir. /api/v1/orders endpoint'ini sessizce bozmak yerine yeni versiyon açmak daha güvenlidir.

Her sürümden sonra 8-10 satırlık kısa bir release note paylaşmak yeterlidir. Destek ekibi, ürün yöneticisi ve müşteri temsilcisi aynı metni görürse “ne değişti?” sorusu azalır. Şeffaflık, operasyon yükünü doğrudan düşürür.

İzleme, loglama ve raporlama olmadan destek yönetilemez

Bakım süreci ölçülmüyorsa yönetim yalnızca hissiyata dayanır. Bu da çoğu zaman ya gereksiz panik ya da geç fark edilen riskler üretir. En azından temel operasyon göstergeleri takip edilmelidir.

Başlangıç için yeterli metrik seti:

  • MTTA: Olayın fark edilme veya ilk yanıt süresi.
  • MTTR: Ortalama çözüm süresi.
  • Tekrar eden olay oranı: Son 30 günde aynı kök nedenin kaç kez yaşandığı.
  • Sürüm başarı oranı: Rollback gerektiren yayın yüzdesi.
  • Backlog yaşlanması: 14 günü aşan açık kayıt sayısı.

Burada önemli olan, metrik sayısını gereksiz yere artırmamaktır. 20 KPI içeren ama hiç bakılmayan bir pano yerine, haftalık olarak izlenen 5 ölçüm çok daha faydalıdır. Örneğin son 90 günde P1 sayısı düşük olabilir; ancak P3 kayıtlarının çözüm süresi 12 günden 28 güne çıkıyorsa ekip görünmeyen bir darboğaza girmiştir.

İzleme tarafında uygulama logları, altyapı metrikleri ve iş metrikleri birlikte değerlendirilmelidir. Sunucu ayakta olabilir ama sipariş adedi 0'a düşmüşse iş açısından sistem aslında kesiktir. Teknik sağlık ile iş sağlığı aynı şey değildir.

Rol ve iletişim modeli: kim, ne zaman devreye girer?

Destek sürecinde belirsizlik çoğu zaman teknik eksiklikten değil, rol karmaşasından kaynaklanır. Bir P1 olayında geliştirici, DevOps mühendisi, ürün sahibi ve müşteri tarafı temsilcisi aynı anda ama farklı beklentilerle hareket eder. Bunu önlemek için RACI benzeri sade bir görev tablosu hazırlanabilir.

Örnek akış:

  • Destek sorumlusu: Kaydı açar, sınıflandırır, iletişim ritmini yönetir.
  • Teknik lider: Kök nedeni koordine eder, çözüm yaklaşımını belirler.
  • Geliştirici/DevOps: Düzeltmeyi uygular, test eder, yayına alır.
  • Ürün sahibi: İş etkisini teyit eder, öncelik kararına katkı verir.
  • Müşteri temsilcisi: Kullanıcı iletişimini ve beklenti yönetimini yürütür.

Kritik olaylarda 30 dakikada bir durum güncellemesi yapmak iyi bir pratiktir. “Çalışıyoruz” gibi boş mesajlar yerine somut bilgi verilmelidir: etkilenen modül, geçici önlem, tahmini sonraki güncelleme saati. Bu iletişim disiplini güven oluşturur.

Sonuç: iyi bakım modeli, yazılımın ömrünü uzatır

Yazılım bakım ve destek yaklaşımı, canlıya çıktıktan sonra ortaya çıkan belirsizlikleri sistematik hale getirir. Net SLA tanımları, iş etkisine göre önceliklendirme, ayrıştırılmış bakım hatları, kontrollü sürüm yönetimi ve ölçülebilir operasyon metrikleri bir araya geldiğinde ekipler daha az reaktif çalışır. Kurum açısından kazanım yalnızca daha az kesinti değildir; aynı zamanda daha öngörülebilir maliyet, daha şeffaf iletişim ve daha sağlıklı ürün evrimi anlamına gelir.

Özel yazılım projelerinde güçlü bir destek modeli en başta tasarlanmalıdır. Canlıya geçişten 6 ay sonra toparlamaya çalışmak her zaman daha pahalıya mal olur. Doğru kurgulanmış bir yapı, yazılımı yalnızca çalışan bir sistem olmaktan çıkarır; sürdürülebilir bir iş varlığına dönüştürür.