Mobil Uygulama Bakım, Teknik Destek ve SLA Satın Alma Rehberi
Mobil uygulama bakım anlaşmasında teknik destek, hata önceliği, müdahale ve çözüm hedefi, izleme, sürüm güncelleme ile SLA maliyetini doğru planlayın.
Kısa cevap: Bakım paketi, sınırsız küçük iş listesi değildir
Mobil uygulama bakım ve teknik destek hizmeti; yayındaki ürünün kullanılabilir, güvenli, mağaza kurallarıyla uyumlu ve gerektiğinde güncellenebilir kalmasını sağlayan operasyon modelidir. İyi bir bakım anlaşması “aylık destek verilir” demekle yetinmez. Hangi sistemlerin izlendiğini, olayın nasıl bildirildiğini, önem seviyesini kimin belirlediğini, ne kadar sürede yanıt verildiğini, hangi değişikliklerin dahil olduğunu ve kullanılan kapasitenin nasıl raporlandığını açıklar.
SLA ise yalnızca “çok hızlı döneriz” vaadinin kurumsal adı değildir. Ölçülebilir hizmet göstergeleri, hedefler, destek pencereleri, istisnalar, iletişim ve telafi yaklaşımı birlikte tanımlanır. Uygulamanın backend’i başka ekipte, ödeme hizmeti dış sağlayıcıda ve mağaza kontrolü müşteri hesabındaysa tek tedarikçinin her olay için kesin çözüm süresi vermesi gerçekçi olmayabilir. Buna karşılık olayı kabul etme, tanılama, geçici çözüm, düzenli bilgi verme ve doğru tarafa eskale etme yükümlülükleri ölçülebilir.
Bakım ihtiyacını gösteren işaretler
Uygulama aylarca yeni sürüm almıyorsa, çökme ve API hataları ancak müşteri şikâyetiyle fark ediliyorsa, işletim sistemi güncellemeleri yayın öncesi paniğe dönüşüyorsa veya eski geliştirici dışında kimse build alamıyorsa bakım borcu vardır. Benzer biçimde sunucu maliyetinin neden yükseldiği bilinmiyor, yedek geri yükleme hiç denenmemiş ve mağaza uyarıları tek kişinin e-postasına gidiyorsa sorun koddan önce operasyon sahipliğidir.
Bakım, aktif kullanıcı sayısı düşük üründe de gerekebilir; veri hassasiyeti veya iş kritikliği kullanıcı hacminden önemlidir. Bir saha ekibinin günde yalnızca yüz işlem yaptığı uygulama, arıza halinde sevkiyatı durduruyorsa yüksek önceliklidir. Buna karşılık milyon indirmeli fakat kritik işlemi olmayan içerik uygulamasında farklı destek penceresi seçilebilir. Hizmet seviyesi kullanıcı sayısından değil, olayın iş etkisi ve kabul edilebilir riskten türetilir.
Üç bakım modeli arasında karar
| Model | Uygun olduğu durum | Satın alırken dikkat |
|---|---|---|
| Reaktif destek havuzu | Düşük değişim, mesai içinde tolere edilebilir olay | Minimum çağrı, saat tüketimi ve yanıt penceresi |
| Planlı bakım + destek | Düzenli mağaza/SDK güncellemesi ve küçük iyileştirme | Bakım işleri ile ürün geliştirme kapasitesinin ayrımı |
| Kritik hizmet / nöbet | Gelir veya operasyon kesintisi yüksek uygulama | 7/24 nöbet, eskalasyon, izleme ve olay sonrası rapor |
Bazı ekipler dördüncü bir model olarak gömülü ürün kapasitesi satın alır. Bu modelde geliştirici, QA ve ürün desteği belirli kapasiteyle sürekli çalışır. Roadmap’i sık değişen ürünlerde verimli olabilir; fakat “ne çıkarsa yapılır” şeklinde yönetilmemelidir. Kapasite birimi, öncelik sahibi, devreden iş, tatil/nöbet planı ve acil olayın planlı geliştirmeyi nasıl etkilediği yazılır.
SLA, SLI ve SLO ayrımı satın alma kararını nasıl iyileştirir?
SLI, ölçülen göstergedir: başarılı ödeme isteklerinin oranı, API gecikmesi, çökmesiz oturum veya bildirim teslimi gibi. SLO, bu göstergenin hedef değeridir. SLA ise hizmet sağlayıcı ile müşteri arasındaki taahhüt, sorumluluk ve olası sonuçları içeren anlaşma katmanıdır. Google’ın Service Level Objectives bölümü bu kavramların kullanıcı için önemli davranışlardan türetilmesini önerir.
Her metriği SLA yapmak doğru değildir. Uygulamanın telefon tarafı kullanıcının ağına, cihazına ve işletim sistemine bağlıdır; üçüncü taraf ödeme veya harita sağlayıcısının kesintisi bakım ekibinin doğrudan kontrolünde olmayabilir. Bu yüzden uçtan uca göstergeyle bileşen göstergesi ayrılır. Örneğin “sipariş verilemiyor” iş etkisidir; altında API hata oranı, ödeme sağlayıcı yanıtı ve stok servisi gecikmesi ayrı sinyallerdir.
Aylık yüzde kullanılabilirlik hedefi tek başına yetersizdir. Ölçüm hangi URL, bölge, kullanıcı rolü ve zaman penceresinden yapılacak? Planlı bakım dahil mi? Kısmi yavaşlama kesinti sayılıyor mu? Veriyi hangi izleme sistemi üretecek ve iki tarafın erişimi var mı? Tanım net değilse çok hassas görünen yüzde uyuşmazlığı yalnızca daha teknik hale getirir.
Önem seviyeleri için uygulanabilir bir örnek
| Seviye | İş etkisi örneği | İlk hedef | İletişim biçimi |
|---|---|---|---|
| P1 Kritik | Tüm kullanıcılar giriş/ödeme yapamıyor, veri güvenliği şüphesi | Nöbeti tetikle, hizmeti güvenli biçimde geri getir | Sık durum güncellemesi ve yönetici eskalasyonu |
| P2 Yüksek | Önemli akış kullanıcıların bir bölümünde çalışmıyor | Aynı destek penceresinde analiz ve geçici çözüm | Tanımlı aralıkta ilerleme bildirimi |
| P3 Orta | Alternatifi olan işlev hatası veya performans sorunu | Planlanan bakım sırasına al | Destek kaydı üzerinden takip |
| P4 Düşük | Görsel kusur, metin veya küçük kullanılabilirlik iyileştirmesi | Ürün backlog’u ile önceliklendir | Periyodik rapor |
Bu tablo sözleşmeye doğrudan kopyalanmamalı; uygulamanın gerçek iş akışına uyarlanmalıdır. Ödeme alamamak e-ticarette P1 olabilir, fakat ödeme özelliği henüz pilot kullanıcıya açıksa P2 değerlendirilebilir. Önceliği ilk bildirim sahibi seçebilir, bakım ekibi kanıta göre teyit eder ve anlaşmazlık için eskalasyon yolu bulunur. Güvenlik olaylarında kapsam ve iletişim, normal hata kaydından farklı yürütülmelidir.
Teknik bakımın görünmeyen kapsamı
Mobil istemci tek başına ürün değildir. Backend, veritabanı, mesaj kuyruğu, dosya depolama, bildirim servisi, CDN, DNS, sertifika, yönetim paneli ve üçüncü taraf API’ler aynı kullanıcı akışını etkiler. Bakım teklifi sistem sınırını çizmelidir: ekip yalnızca iOS/Android koduna mı bakıyor, yoksa backend ve bulut operasyonunu da mı yönetiyor? Sorumlu olmadığı bileşen için hangi gözlemi toplayıp kime eskale edeceği belirtilmelidir.
Planlı bakım; framework ve paket güncellemeleri, güvenlik yamaları, hedef SDK gereksinimleri, sertifika süresi, mağaza beyanları, cihaz uyumluluğu, veritabanı bakımı ve yedek geri yükleme testini içerebilir. Google Play’in hedef API seviyesi gereksinimi gibi kurallar zamanla değişir. Apple’ın üçüncü taraf SDK gereksinimleri de kullanılan bağımlılıkların gizlilik ve imza koşullarını yayın sürecine taşır. Bu değişiklikler “uygulama bozulunca” değil takvimli uyumluluk çalışmasıyla yönetilmelidir.
Güvenlik bakımı yalnızca paket güncellemek değildir. Yetki, oturum, cihazda veri saklama, ağ güvenliği, loglarda kişisel veri ve API erişimi risk bazlı kontrol edilir. OWASP MASVS mobil istemci için depolama, kimlik doğrulama, ağ, platform, kod ve gizlilik kontrol grupları sunar. Backend için ayrıca uygun uygulama güvenliği standardı ve tehdit modeli gerekir.
İzleme ve olay yönetimi mimarisi
Kullanıcı şikâyetinden önce haber almak için dört sinyal katmanı kurulabilir. Birincisi mobil kararlılık: çökme, donma, uygulama başlangıç ve sürüm dağılımı. İkincisi iş olayı: giriş, arama, sipariş, ödeme veya rezervasyon başarısı. Üçüncüsü servis sağlığı: gecikme, hata oranı, doygunluk ve kuyruk. Dördüncüsü dış bağımlılıklar: ödeme, SMS, harita ve mağaza servisleri.
Alarm, her tekil hatada nöbetçiyi uyandırmamalıdır. Eşik iş etkisine dayanır; yinelenen kayıtlar tek olaya gruplanır ve uyarı doğru ekibe yönlenir. Alarmın yanında bir runbook bulunur: nasıl doğrulanır, güvenli geçici çözüm nedir, hangi gösterge kontrol edilir ve kim bilgilendirilir? İzleme aracı kurulup kimse tarafından takip edilmiyorsa operasyonel değer üretmez.
Olay kapandığında yalnızca “düzeltildi” yazmak öğrenmeyi kaybettirir. Kritik olay için zaman çizelgesi, kullanıcı etkisi, tetikleyici, katkıda bulunan koşullar, restorasyon, kalıcı aksiyon ve sahip/tarih bilgisi hazırlanır. Amaç kişiyi suçlamak değil sistemin aynı sınıf hatayı daha erken yakalamasını sağlamaktır. Sözleşmede olay sonrası raporun hangi seviyelerde ve kaç iş günü içinde verileceği belirlenebilir.
Maliyet ve süreyi etkileyen etkenler
Mobil uygulama bakım maliyetinin evrensel bir yüzdeyle hesaplanması sağlıklı değildir. En güçlü etken destek penceresidir: mesai içi, uzatılmış saat veya 7/24 nöbet farklı ekip organizasyonu gerektirir. İkinci etken sistem genişliğidir; iki mobil istemciye backend, panel, bulut ve entegrasyonlar eklendikçe uzmanlık ve izleme kapsamı büyür. Üçüncü etken mevcut teknik borçtur. Testsiz, belgesiz ve eski bağımlılıklı ürünün ilk ayları normal bakımdan çok stabilizasyon içerebilir.
Olay sıklığı, yayın ritmi, regülasyon, veri hassasiyeti, aktif ülke ve dil sayısı, cihaz aralığı, üçüncü taraf sayısı ile beklenen geliştirme kapasitesi teklifi etkiler. Araç lisansı, SMS/e-posta, log saklama ve bulut bedeli hizmet ücretinden ayrı gösterilmelidir. Bakım kotasına yeni özellik ekleniyorsa analiz, tasarım ve QA kapasitesinin de gerektiği unutulmamalıdır.
Teklifin daha ucuz görünmesi bazen izleme, nöbet, QA veya planlı güncellemelerin dışarıda olmasından kaynaklanır. Karşılaştırmayı aylık bedelle değil senaryo üzerinden yapın: Cuma gecesi ödeme çalışmazsa kim alarm alıyor, ilk bilgiyi kim veriyor, backend başka firmadaysa kim koordine ediyor, geçici çözüm nasıl yayınlanıyor? Teklif bu sorulara cevap vermiyorsa SLA tablosundaki dakikalar tek başına güvence değildir.
Aylık bakım teslimatları
- Açılan, kapanan ve devreden destek kayıtları; önem seviyesi ve harcanan kapasite
- Uygulama sürüm dağılımı, çökme ve kritik iş akışı sağlık özeti
- Bağımlılık, sertifika, mağaza politikası ve güvenlik güncelleme takvimi
- Yedekleme ve geri yükleme doğrulaması ile kapasite/maliyet gözlemleri
- Yayınlanan sürümler, değişiklik notları ve geri alma durumu
- Kritik olay raporları ve düzeltici aksiyonların sahip/tarih takibi
- Teknik borç, risk ve gelecek ay için önerilen öncelikler
Rapor yalnızca faaliyet dökümü olmamalıdır. Kullanıcıya ve işe etkisini açıklamalı, tekrar eden sorunları göstermeli, kapasitenin ne kadarının olay, planlı bakım ve geliştirmeye ayrıldığını ayırmalıdır. Böylece müşteri “kaç saat kullandık?” yanında “hangi riski azalttık?” sorusunu da görebilir.
Riskler ve yanlış beklentiler
En yaygın risk, yeni özelliklerle hata düzeltmenin tek belirsiz havuzda tutulmasıdır. Acil olaylar roadmap’i sürekli iter veya roadmap baskısı bakım işlerini erteler. İki iş sınıfı için kapasite, öncelik ve onay yöntemi tanımlanmalıdır. İkinci risk, hiçbir izleme erişimi olmayan ekibe kısa çözüm hedefi vermektir. Ekip log, kaynak kod, mağaza ve canlı ortam yetkisine sahip değilse saat tanımı kağıt üzerinde kalır.
“Sınırsız destek” de yanıltıcı olabilir. Kaç kanal, kaç yetkili, hangi saat, hangi sistem ve hangi değişiklik dahil belirtilmelidir. WhatsApp mesajı resmi olay kaydı sayılıyor mu? Telefonla açılan kayıt daha sonra sisteme giriliyor mu? Yetkisiz bir çalışanın canlı veri silme talebi nasıl doğrulanıyor? Operasyon akışı yazılı olmazsa hız adına güvenlikten ödün verilebilir.
Teklif ve SLA kontrol listesi
- Destek kapsamındaki uygulama, backend, panel ve altyapı bileşenleri listeli mi?
- Mesai saatleri, tatiller, saat dilimi ve 7/24 nöbet sınırı belli mi?
- Öncelik seviyeleri gerçek iş etkisi örnekleriyle tanımlı mı?
- Yanıt, restorasyon ve kalıcı çözüm hedefleri birbirinden ayrılmış mı?
- Ölçüm kaynağı, zaman damgası ve istisnalar iki tarafça görülebiliyor mu?
- Olay açma, yetki doğrulama, eskalasyon ve durum iletişim kanalı belli mi?
- Planlı bakım, mağaza/SDK uyumu ve güvenlik güncellemeleri dahil mi?
- Yeni özellik, hata, garanti ve danışmanlık sınırları açık mı?
- Kullanılmayan veya aşan kapasitenin nasıl işlendiği yazıyor mu?
- Aylık rapor, kritik olay incelemesi ve hizmet gözden geçirmesi var mı?
- Kaynak kod ve canlı ortam erişimleri bakım ekibine güvenli rollerle veriliyor mu?
- Sözleşme bittiğinde açık olaylar, belgeler ve erişimler nasıl devredilecek?
Bakım hizmetine geçiş süreci
İlk adım kaynak kod, mimari, erişim, mağaza, bulut ve aktif sorun envanteridir. Ekip temiz ortamda build alır, test ve canlı ortam farklarını doğrular, kritik akışları haritalar. Mevcut çökme kayıtları, kullanıcı yorumları, destek talepleri ve altyapı göstergeleri incelenir. Bu başlangıç değerlendirmesi normal aylık destek kapasitesinden ayrı bir stabilizasyon fazı gerektirebilir.
İkinci adım hizmet seviyesini iş etkisine bağlamaktır. Paydaşlarla kritik kullanıcı akışları, kabul edilebilir kesinti, iletişim sorumluları ve dış bağımlılıklar belirlenir. İzleme boşlukları kapatılır, olay kayıt sistemi ve runbook kurulur. Başlangıç hedefleri gerçek veriye göre gözden geçirilmek üzere belirli bir kalibrasyon dönemi içerebilir.
Sonrasında planlı bakım takvimi, ürün backlog’u ve olay kapasitesi birlikte yönetilir. Aylık hizmet görüşmesinde sadece kapanan biletler değil SLO eğilimi, tekrar eden sorun, yaklaşan mağaza gereksinimi ve teknik risk konuşulur. Bu ritim, bakım anlaşmasını pasif sigortadan ürün sürekliliği sistemine çevirir.
Sonuç: İyi SLA en kısa süreyi değil, doğru tepkiyi satın alır
Mobil uygulama teknik desteğinde değer, her soruna imkânsız bir kesin çözüm süresi yazmak değildir. Kritik akışı gözlemleyen, olayı doğru sınıflandıran, yetkili ekibi hızla harekete geçiren ve tekrarını azaltan bir düzen kurmaktır. MobiCraft’a bakım talebi iletirken mevcut teknoloji yığınını, kullanıcıların en kritik üç görevini, destek saatlerini ve bugün erişebildiğiniz izleme araçlarını paylaşın. Bunları sorumluluk sınırı, ölçüm ve kapasitesi açık bir bakım planına dönüştürelim.