Yazılım Bakım ve Destek: Canlıya Geçişten Sonra Sürekliliği Nasıl Güvenceye Alırsınız?

Özel yazılım projesinin en riskli dönemi geliştirme değildir. Asıl risk, canlıya geçişten sonraki yıllardadır: projeyi kuran ekip başka işlere geçmiş, kullanılan kütüphaneler eskimeye başlamış ve ilk ciddi arıza bir cuma akşamı gelmiştir. Büyük bir projeyi orta ölçekli bir firmaya vermekte tereddüt eden alıcının aklındaki soru da çoğu zaman budur: Üç yıl sonra bu sisteme, onu gerçekten tanıyan biri bakıyor olacak mı?

Firmanın büyüklüğü bu soruya sanıldığı kadar iyi cevap vermez. Cevabı veren, bakım ve desteğin nasıl kurgulandığıdır. Üstelik bu kurgu, sözleşme imzalanmadan önce kontrol edilebilir.

Bakım ve destek gerçekte neleri kapsamalı?

Tekliflerde "destek" genellikle bir hata düzeltme kalemi ve saat ücretinden ibarettir. Oysa bir işletmeyi taşıyan sistemin altı ayrı ihtiyacı vardır ve her birinin sahibi de ritmi de farklıdır.

1. Düzeltici bakım. Arızalar ve hatalar; önceden tanımlanmış önem seviyelerine, yanıt ve çözüm sürelerine göre ele alınır.
2. Uyarlayıcı bakım. Çevre değiştikçe sistemin çalışmaya devam etmesi: işletim sistemi ve tarayıcı güncellemeleri, uygulama mağazası kuralları, üçüncü taraf API sürümleri, KVKK ya da GDPR gibi düzenlemelerdeki değişiklikler.
3. Önleyici bakım. Güvenlik yamaları, bağımlılık güncellemeleri, performans iyileştirmeleri ve teknik borç kesintiye dönüşmeden önce temizlenmesi.
4. Operasyon ve izleme. Erişilebilirlik ve hata izleme, uyarılar, yedekler ve en az onlar kadar önemli olan geri yükleme testleri. Yedeğin işe yaradığını ancak geri yükleme testi kanıtlar.
5. Gelişim. İş birimlerinin istediği yeni özellikler ve değişiklikler; dağınık talepler olarak değil, bir yol haritası olarak planlanır.
6. Bilgi sürekliliği. Dokümantasyon, çalışma kılavuzları (runbook), mimari kararların kaydı ve her kritik parçayı birden fazla kişinin bildiği bir ekip.

Sözleşmelerin çoğu ilk beşini anlatır. Diğer beşinin bir istifadan, bir yeniden yapılanmadan ya da tedarikçi değişikliğinden sağ çıkıp çıkmayacağını ise altıncısı belirler.

Süreklilik nerede kopar?

Sistemi tek bir kişi biliyor

En sık görülen sorun teknik değildir. Ödeme akışının, ERP entegrasyonunun ya da dağıtım hattının gerçekte nasıl çalıştığını tek bir geliştirici bilir. O kişi ayrıldığında, hangi taraftan olursa olsun, sistem durmaz ama her değişiklik yavaşlar, riskli ve pahalı hâle gelir.

Destek modeli canlıya geçtikten sonra konuşuluyor

Destek sonraya bırakıldığında genellikle ilk arızanın ardından, baskı altında tasarlanır. Önem seviyeleri, yanıt süreleri ve çalışma saatleri en yüksek sesle talep edene göre şekillenir. Geliştirme bütçesi ise çoktan harcanmıştır.

Bağımlılıklar sessizce eskiyor

"Çalışıyor" görünen bir sistem de güncelleme yayınlayan ve desteği sona eren çatılar, kütüphaneler ve bulut servisleri üzerinde durur. Bir yıl güncelleme yapmamak tasarruf gibi görünür. Bir güvenlik açığı ya da mağaza son tarihi geldiğinde ise bu tasarruf zorunlu ve büyük bir yükseltme projesine dönüşür.

Sistemi kimse izlemiyor

İzleme ve uyarı yoksa izlemeyi kullanıcılar yapar. Kesintiler şikâyetlerden öğrenilir, kök nedenler kayıtlardan değil hafızadan çıkarılmaya çalışılır.

Kuran ekip ortadan kayboluyor

Pek çok firma geliştirme aşamasına en güçlü ekibini koyar, canlıya geçişten sonra ise projeyi dönüşümlü çalışan ayrı bir destek havuzuna devreder. Talebinizi yanıtlayan kişi, yama yaptığı mimariyi ilk kez görüyordur.

Yol haritasının sahibi yok

Değişiklik talepleri farklı departmanlardan gelir, kimse önceliklendirmez ve sistem kimsenin planlamadığı yönlere büyür. Zamanla bakımı zorlaşır; sebep yaşı değil, yönetilmeyen değişikliktir.

Kolay cevap ve neden yetmediği

Kolay cevap, kısa listedeki en büyük firmayı seçmektir. Büyüklüğün gerçek getirileri vardır: daha geniş kadro, resmî süreçler, finansal dayanıklılık. Ama büyük bir firma da projenize her çeyrek değişen bir ekip atayabilir. O durumda satın aldığınız süreklilik sizin sisteminizde değil, organizasyon şemasında kalır.

Dürüst olmak gerekirse orta ölçekli bir firmanın da gerçek bir riski vardır: Sisteminizin bilgisi iki kişide toplanmışsa bu bir yoğunlaşma riskidir ve nasıl yönetildiğini sormanız gerekir. İki durumda da işe yarayan soru aynıdır. "Ne kadar büyüksünüz?" değil; "Bu sisteme tam olarak kim bakacak, biri izindeyken ne olacak ve ben bunu nereden bileceğim?"

2017'den beri teslim ettiğimiz 400+ projede iyi yaşlanan sistemlerin ortak bir noktası vardı: Destek, geliştirme sırasında, sistemi kuran ekip tarafından tasarlanmış ve canlıya geçişten önce sözleşmeye yazılmıştı.

İmzadan önce neye bakmalı?

Ekip yapısı. Canlıya geçişten sonra sistemde kalacak çekirdek ekibin isimlerini ve her kritik alan için (backend, mobil, altyapı, entegrasyonlar) isimli bir yedek kişiyi isteyin. "Destek ekibimiz var" bir cevap değildir.

Süreç olgunluğu. Her değişiklikte kod incelemesi, kritik akışlarda otomatik testler, ekipteki herkesin çalıştırabildiği bir CI/CD hattı ve sık görülen arızalar için çalışma kılavuzları. İkinci bir mühendisin sistemi kazı yapmadan devralabilmesini bunlar sağlar.

Destek modeli ve SLA. Örneklerle tanımlanmış önem seviyeleri, her seviye için yanıt ve çözüm süreleri, destek saatleri ve mesai dışı eskalasyon yolu. Yanıt süresi ile çözüm süresi farklı taahhütlerdir; hangisinin verildiğine bakın.

İzleme ve raporlama. Neyin izlendiği, uyarıların kime gittiği ve her ay ne gördüğünüz: arızalar, yanıt süreleri, bağımlılıkların durumu, açık riskler.

Güncelleme politikası. Bağımlılıkların ve çatıların ne sıklıkla gözden geçirilip güncellendiği ve bu işin destek kapsamına dahil mi, ayrıca mı fiyatlandığı.

Devir ve çıkış. Kendi ekibinizin ya da başka bir firmanın sistemi devralabilmesi için kaynak kod, dokümantasyon ve erişimler. Bu konuyu Yazılım Firmasına Bağımlı Kalmamak: Kaynak Kod ve Bilgi Sahipliğini Baştan Kurmak yazımızda ayrıntılı ele aldık.

Yol haritasının sahipliği. Bir sonraki değişikliğe sizin tarafınızda ve firmanın tarafında kimin karar verdiği ve bu konuşmanın ne sıklıkla yapıldığı.

Kalıcı bir destek için aşamalı plan

Aşağıdaki takvim, desteğin geliştirmenin bir parçası olarak planlandığını varsayar. Süreleri sistemin büyüklüğüne göre uyarlayın; haftaların kendisinden çok sıralama önemlidir.

Canlıya geçişten önceki 4 hafta: desteği önceden tasarlayın. Önem seviyelerini ve SLA hedeflerini netleştirin. İzlemeyi, uyarıları ve yedeklemeyi kurun, ilk geri yükleme testini yapın. Şimdiden öngörebildiğiniz arızalar için çalışma kılavuzlarını yazın. Her kritik bileşenin ikinci bir mühendis tarafından incelenip dağıtıldığından emin olun.

1-4. haftalar: yakın takip dönemi. Kuran ekip sistemin başında kalır. Arızalar her gün değerlendirilir, küçük düzeltmeler sık yayınlanır ve tekrarlayan her sorun için kök neden bulunup kılavuza eklenir.

5-12. haftalar: olağan işleyişe geçiş. Günlük değerlendirmeden anlaşılan SLA düzenine geçilir. İlk bağımlılık gözden geçirmesi ve güvenlik yaması döngüsü yapılır. İlk aylık rapor sunulur ve iş birimleriyle ilk yol haritası öncelikleri belirlenir.

Her çeyrek: sağlık değerlendirmesi. Arıza eğilimleri, bağımlılıkların yaşı, güvenlik durumu, dokümantasyon eksikleri ve ekip kapsamı gözden geçirilir. Sıradaki teknik borç kararlaştırılır ve her kritik alanın hâlâ bir yedek mühendisi olduğu teyit edilir.

Yapılmaması gereken üç şey

1. Desteği pazarlıkta ilk kesilecek kalem olarak görmeyin. Belirsiz bir destek maddesiyle düşürülen geliştirme fiyatı, sistemin ömrü boyunca fiyatı ve kapsamı belli bir destek planından genellikle daha pahalıya gelir. İş yine yapılır; yalnızca daha geç ve baskı altında.
2. Sistemin tek bir kişiye dönüşmesine izin vermeyin. Hem sizin tarafınızda hem firmanın tarafında her kritik alanı güvenle değiştirebilecek en az iki kişi olmalı.
3. Her şey çalışıyor diye güncellemeleri ertelemeyin. Küçük ve düzenli güncellemeler ucuzdur. İki sessiz yılın ardından gelen zorunlu yükseltme ise nadiren öyledir.

Sık sorulan sorular

Yazılım bakım ve destek hizmeti neleri kapsar?

Yazılım bakım ve destek hizmeti; hata ve arızaların giderilmesini, sistemin platform, API ve mevzuat değişikliklerine uyarlanmasını, güvenlik yamaları ve bağımlılık güncellemeleri gibi önleyici işleri, izleme ve yedeklemeyi ve planlı özellik değişikliklerini kapsar. İyi bir destek sözleşmesi bilgi sürekliliğini de güvenceye alır: dokümantasyon, çalışma kılavuzları ve her kritik parçayı bilen birden fazla mühendis.

Yazılım destek sözleşmesinde (SLA) neler olmalı?

Bir yazılım destek SLA'sı, somut örneklerle tanımlanmış önem seviyelerini, her seviye için yanıt ve çözüm sürelerini, destek saatlerini ve mesai dışı eskalasyon yolunu içermelidir. Ayrıca neyin izlendiğini, arızaların nasıl raporlandığını ve bağımlılık güncellemelerinin kapsama dahil olup olmadığını açıkça yazmalıdır.

Büyük bir projeyi orta ölçekli bir yazılım firmasına vermek riskli mi?

Risk, firmanın büyüklüğünden çok projenin nasıl kadrolandığına ve desteklendiğine bağlıdır. Canlıya geçişten sonra kalacak isimli bir çekirdek ekip, her kritik alan için yedek mühendis, belgelenmiş süreçler ve yazılı bir destek modeli isteyin. Bunlara sahip orta ölçekli bir firma, ekiplerini projeler arasında döndüren büyük bir firmadan daha fazla süreklilik sunabilir.

Yazılım bakım maliyeti neye göre belirlenir?

Bakım maliyeti; sistemin büyüklüğüne ve yaşına, entegrasyon sayısına, ihtiyaç duyulan SLA seviyesine, bağımlılıkların ne sıklıkla güncellendiğine ve beklenen yeni geliştirme miktarına göre değişir. Maliyeti kontrol etmenin en güvenilir yolu destek kapsamını geliştirme sırasında tanımlamaktır; böylece önleyici işler acil müdahale olarak değil, planlı olarak yapılır.

Yazılım bakımını ileride kendi ekibimize alabilir miyiz?

Evet, sistem buna göre kurulduysa alabilirsiniz. Bunun için kaynak kodun ve altyapının tamamen size ait olması, güncel dokümantasyon ve çalışma kılavuzları ve mühendislerinizin firmanın ekibiyle birlikte çalıştığı planlı bir devir dönemi gerekir. Birçok şirket, yol haritasını kendi ekibinin yönettiği, operasyonu ve uzmanlık gerektiren işleri ise dış ortağın üstlendiği hibrit bir model kullanır.

Kurmak üzere olduğunuz sistemin desteğini planlıyor musunuz?

Büyük bir proje için firma değerlendiriyorsanız, sözleşme imzalanmadan önce sisteminiz için destek, ekip sürekliliği ve devrin nasıl işleyeceğini birlikte üzerinden geçebiliriz. Ekibimizle görüşün.