Hangi sorunu çözüyoruz?
Yazılımı yapan firma artık ulaşılamıyor, ya da her destek talebi günlerce bekliyor. Küçük bir hata yüzünden sipariş alınamıyor ama kimin bakacağı belli değil.
Bu arada kullanılan kütüphaneler, PHP veya Node.js sürümü ve işletim sistemi güncellenmediği için güvenlik açıkları sessizce birikiyor. Bir gün sunucu sağlayıcısı eski sürümü desteklemeyi bırakıyor ve sistem bir anda çalışmaz hâle geliyor.
Bakım, bu tür sürprizleri önlemek için düzenli ve planlı yapılan işlerin toplamıdır. Destek ise bir sorun çıktığında kime, nasıl ulaşacağınızı ve ne kadar sürede cevap alacağınızı yazılı hâle getirir.
Ne yapıyoruz?
SLA'li destek
Her talep öncelik seviyesine göre sınıflandırılır; ilk yanıt ve çözüm hedefleri sözleşmede yazılıdır. Talepler bir sistemde kayıt altına alınır; ne zaman açıldığı, kimin üzerinde olduğu ve nasıl kapandığı her zaman görülebilir.
Güvenlik güncellemeleri
İşletim sistemi, programlama dili sürümü, çatı (framework) ve kütüphaneler düzenli olarak güncellenir. Kritik bir açık duyurulduğunda etkilenip etkilenmediğiniz kontrol edilir ve gerekiyorsa öncelikli yama uygulanır.
7/24 izleme
Erişilebilirlik, yanıt süresi, hata oranı, disk ve bellek kullanımı, SSL sertifika süresi ve yedeklerin başarıyla alınıp alınmadığı izlenir. Sorunların çoğu kullanıcı fark etmeden yakalanır.
Sürüm yükseltmeleri
Desteği biten PHP, Node.js, veritabanı veya çatı sürümlerinden yenisine geçiş planlanır, test ortamında denenir ve kesintisiz biçimde yapılır.
Küçük geliştirmeler
Pakete dahil aylık geliştirme saatiyle yeni rapor, ek alan veya küçük akış değişiklikleri ayrı bir proje açmadan yapılır. Kullanılmayan saatler paket koşullarına göre bir sonraki aya devredilebilir.
Devralma
Başka bir firmanın veya ayrılan bir çalışanın yazdığı yazılımı inceleyip bakımını üstleniriz. Önce durum tespiti yapar, riskleri ve eksikleri raporlarız.
Öncelik seviyeleri
| Seviye | Örnek durum | İlk yanıt hedefi |
|---|---|---|
| Kritik | Sistem tamamen erişilemez, ödeme veya sipariş alınamıyor, veri kaybı riski var | [Kritik ilk yanıt süresi] |
| Yüksek | Önemli bir özellik çalışmıyor, kullanıcıların bir kısmı etkileniyor | [Yüksek ilk yanıt süresi] |
| Orta | Geçici bir yolu olan hata, raporlarda tutarsızlık | [Orta ilk yanıt süresi] |
| Düşük | Görsel kusur, metin değişikliği, küçük iyileştirme isteği | [Düşük ilk yanıt süresi] |
Mesai içi ve 7/24 olmak üzere iki destek modeli sunarız. 7/24 modelde kritik seviyedeki talepler mesai dışında ve hafta sonunda da karşılanır.
Paket seçenekleri
| Temel | Standart | Kapsamlı | |
|---|---|---|---|
| Destek saatleri | Mesai içi | Mesai içi | 7/24 (kritik talepler) |
| Güvenlik güncellemeleri | ✓ | ✓ | ✓ |
| Erişilebilirlik ve hata izleme | ✓ | ✓ | ✓ |
| Sürüm yükseltme planlaması | — | ✓ | ✓ |
| Aylık geliştirme saati | — | [Saat] | [Saat] |
| Yedekten geri dönüş testi | — | Düzenli | Düzenli + rapor |
| Yıllık güvenlik testi planlaması | — | — | ✓ |
| Fiyat | [Aylık fiyat] | [Aylık fiyat] | [Aylık fiyat] |
Düzenli bakım takvimi
| Sıklık | Yapılan iş |
|---|---|
| Sürekli | Erişilebilirlik, hata oranı, kaynak kullanımı ve yedek durumunun izlenmesi |
| Haftalık | Güvenlik duyurularının ve bağımlılık uyarılarının kontrolü; acil yamaların uygulanması |
| Aylık | Planlı güncellemeler, log incelemesi, aylık rapor ve öncelik toplantısı |
| Üç aylık | Yedekten geri dönüş testi, kullanılmayan hesap ve erişimlerin temizlenmesi |
| Yıllık | Sürüm yol haritası, desteği bitecek bileşenlerin planı, güvenlik testi takvimi |
İyi bir destek talebi nasıl yazılır?
Talebin hızlı çözülmesinin en büyük belirleyicisi, ilk mesajda verilen bilgidir. Destek panelindeki form aşağıdaki bilgileri ister; eksik bilgi için tekrar sormak zaman kaybettirir.
- Ne oldu ve ne olmasını bekliyordunuz?
- Sorun hangi ekranda, hangi kullanıcıyla ve yaklaşık hangi saatte yaşandı?
- Sorunu tekrar oluşturmak için izlenen adımlar.
- Varsa ekran görüntüsü veya hata mesajının tam metni.
- Kaç kullanıcının etkilendiği ve işin durup durmadığı; öncelik buna göre belirlenir.
Devralma nasıl yapılır?
- Erişimlerin teslim alınması: Kaynak kodu, sunucu, alan adı, e-posta, ödeme ve üçüncü taraf servis hesapları listelenir; erişimler sizin adınıza düzenlenir, eski geliştiricinin erişimleri kontrollü biçimde kapatılır.
- Kod ve güvenlik incelemesi: Kod yapısı, kullanılan sürümler, bilinen açıklar ve test durumu incelenir; risk raporu hazırlanır.
- Yedek ve kurtarma doğrulaması: Mevcut yedeklerin gerçekten geri yüklenebildiği test edilir; yoksa yedekleme hemen kurulur.
- Eksik dokümantasyonun tamamlanması: Kurulum, yayın ve veritabanı şeması belgelenir; sistem tek bir kişinin bilgisine bağlı olmaktan çıkar.
- Düzenli bakıma geçiş: Risk raporundaki öncelikli maddeler kapatılır ve bakım paketiyle devam edilir.
Aylık bakım raporunda neler var?
- Dönem içinde açılan ve kapanan destek talepleri, öncelik dağılımı ve hedeflere uyum.
- Uygulanan güncellemeler ve kapatılan güvenlik açıkları.
- Erişilebilirlik oranı, yaşanan kesintiler ve nedenleri.
- Yedekleme durumu ve son geri dönüş testinin sonucu.
- Önümüzdeki dönem için öneriler: desteği bitecek sürümler, performans riskleri, iyileştirme fırsatları.
Bakımı ihmal etmenin maliyeti
Bakım, bir sorun yaşanmadığı sürece gereksiz bir masraf gibi görünür. Oysa ertelenen her güncelleme, sonraki güncellemeyi daha zor ve daha pahalı hâle getirir; birkaç sürüm geride kalan bir sistem, sonunda yeniden yazılmak zorunda kalabilir.
Güvenlik açısından da benzer bir durum vardır. Kullanılan bir kütüphanede açık duyurulduğunda, bu açık kısa sürede otomatik araçlarla taranmaya başlanır; güncellenmemiş sistemler ilk hedeftir.
Bakım sözleşmesinde nelere bakmalısınız?
Hangi firmayla çalışırsanız çalışın, bir bakım sözleşmesini imzalamadan önce aşağıdaki soruların cevabının yazılı olduğundan emin olun. Bizim sözleşmelerimizde hepsi açıkça yer alır.
- Öncelik seviyeleri nasıl tanımlanıyor ve her biri için ilk yanıt hedefi ne?
- Hangi işler pakete dahil, hangileri ayrıca fiyatlanıyor?
- Kaynak kodu, sunucu ve servis hesapları kimin adına ve kimin kontrolünde?
- Sözleşme sona erdiğinde erişimler ve dokümanlar nasıl teslim ediliyor?
- Yedekler nerede tutuluyor ve en son ne zaman geri dönüş testi yapıldı?
Örnek kullanım senaryoları
- Teslim sonrası devam: Geliştirdiğimiz bir web yazılımı garanti süresi bittikten sonra aylık bakım paketiyle izlenir ve güncellenir.
- Sahipsiz kalan yazılım: Geliştiricisi ayrılan bir sipariş sistemi devralınır, risk raporu çıkarılır, öncelikli açıklar kapatılır.
- Mağaza uyumu: Mobil uygulama her yıl yeni iOS ve Android sürümlerine uyarlanır, mağaza kural değişiklikleri takip edilir.
- Kampanya öncesi hazırlık: Yoğun satış döneminden önce yük kontrolü yapılır, sunucu kaynakları geçici olarak artırılır ve kampanya süresince izleme sıklaştırılır.
- Entegrasyon takibi: Pazaryeri veya ödeme kuruluşunun API değişiklikleri izlenir; entegrasyonlar eski sürüm kapanmadan güncellenir.
Komple çözümün son halkası
Bakım; sunucu altyapısının izlenmesini ve yılda en az bir kez yapılması önerilen güvenlik testinin planlanmasını da kapsayabilir. Tasarımdan desteğe kadar aynı ekiple çalıştığınızda, bir sorunun hangi katmanda olduğunu bulmak için firmalar arasında beklemezsiniz.
[Yayınlanabilir bir bakım veya devralma vaka çalışması hazır olduğunda buraya bağlantı ekleyin.]
Fiyatı etkileyen faktörler
- Yanıt süresi taahhüdü: mesai içi veya 7/24.
- Sistemin büyüklüğü, bileşen sayısı ve kullanılan teknolojilerin güncelliği.
- Pakete dahil aylık geliştirme saati.
- Sunucu yönetiminin pakete dahil olup olmadığı.
- Devralınan sistemlerde ilk durum tespitinin kapsamı.
Sık sorulan sorular
Başka firmanın yaptığı yazılımı devralıyor musunuz?
Evet. Önce teknik inceleme yapar, riskleri ve eksikleri raporlarız. Ardından öncelikli maddeleri kapatıp bakım paketine geçeriz.
Destek talepleri nasıl iletiliyor?
Talepler e-posta veya destek paneli üzerinden kayıt altına alınır; her talep için öncelik, ilk yanıt ve çözüm süresi takip edilir. Kritik durumlar için ayrıca telefon hattı tanımlanır.
Kaynak kodumuz yoksa da bakım yapabilir misiniz?
Kaynak kodu olmadan yalnızca sunucu ve altyapı bakımı yapılabilir. Yazılımın kendisinde değişiklik için kaynak koduna ihtiyaç vardır; kodu eski geliştiriciden veya sunucudan kurtarma konusunda yardımcı oluruz.
Aylık geliştirme saati kullanılmazsa ne olur?
Paket koşullarına göre bir sonraki aya devredilebilir. Devretme kuralı sözleşmede yazılıdır.
Bakım paketi ne kadar süreli?
Genellikle yıllık sözleşmeyle çalışırız; sözleşme koşullarına uygun bildirimle sonlandırılabilir. Sonlandırmada tüm erişimler ve dokümanlar size eksiksiz teslim edilir.
Garanti süresi ile bakım arasındaki fark nedir?
Garanti süresinde, teslim ettiğimiz yazılımdaki hatalar ücretsiz düzeltilir. Bakım ise güncelleme, izleme, sürüm yükseltme ve küçük geliştirmeleri kapsayan düzenli bir hizmettir.
Paketi sonradan değiştirebilir miyiz?
Evet. İhtiyacınız değiştiğinde, örneğin yeni bir modül yayına alındığında veya kullanıcı sayısı arttığında, paket bir üst ya da alt seviyeye geçirilebilir. Geçiş koşulları sözleşmede yazılıdır.
Gece yarısı sistem çökerse ne olur?
7/24 destek modelinde izleme sistemi nöbetçi ekibe otomatik uyarı gönderir ve kritik öncelik süreci başlar. Mesai içi modelde sorun ilk iş saatinde ele alınır.