Web Sitesi CMS Seçiminde Teknik Destek Hizmetleri

Bir CMS’i (WordPress, Drupal, Joomla ya da SaaS/headless çözümler) seçerken demo performansı, özellik listesi, lisans maliyeti ve mimari esneklik kadar kritik bir eksen daha var: teknik destek hizmetleri. Gerçek dünyada siteler; sürümler yükselir, entegrasyonlar değişir, trafik dalgaları gelir, güvenlik olayları yaşanır, içerik ekipleri büyür ve yeni pazarlara açılır. Bu dinamizm, “bir kere kur, unut” yaklaşımını hızla geçersiz kılar. Teknik destek, bu değişkenlikte sürekliliği güvenceye alan sigortadır: yanıt ve çözüm süreleri, kapsam ve sınırlar, iletişim kanalları, eskalasyon ve olay yönetimi, otomasyon ve KBA (knowledge base), gözlemlenebilirlik, eğitim ve koçluk, yazılım yaşam döngüsüne entegrasyon, maliyet/ROI ve tedarikçi yönetimi gibi başlıkların toplamıdır.
Bu rehberde CMS seçiminde teknik destek hizmetlerini ölçülebilir kriterlere döken bir çerçeve sunuyoruz. Gelişme bölümünde 25 alt başlıkla; destek katmanları ve SLA/SLO, talep–olay–değişiklik ayrımı, kanallar ve çalışma saatleri, metrikler ve panolar, runbook ve bilgi tabanı, otomasyon ve “shift-left”, güvenceler ve cezai şartlar, güvenlik/uyum, çoklu site/çok dilli gereksinimler, tedarikçi ekosistemi ve iç ekip rolleri, teklif/PoC aşamasında yapılacak testler, ROI modellemesi ve 90 günlük uygulama planı gibi konuları derinlemesine işlerken, karar matrisi için doğrudan kullanılabilecek kontrol listeleri de paylaşacağız.
1) Destek Kapsamını Tanımlamak: Talep–Olay–Değişiklik
Neden? Her istek “arızadır” yanılgısı bütçe ve beklentiyi bozar.
-
Talep (Request): Erişim açma, küçük yapılandırma, içerik şablonu değişikliği gibi planlı işler.
-
Olay (Incident): Üretimi etkileyen kesinti/bozulma; P1–P4 sınıflarıyla yönetilir.
-
Değişiklik (Change): Sürüm güncellemesi, modül/eklenti ekleme, tema refaktörü; CAB/planlama gerektirir.
Çıktı: Sözleşmede her birinin tanımı, örnekleri ve hedef süreleri ayrı yazılmalı.
2) SLA/SLO: Yanıt, Çözüm, Geçici Çözüm
SLA (Service Level Agreement): Tedarikçinin söz verdiği yanıt ve çözüm süreleri.
SLO (Service Level Objective): İç ekiplerin hedefleri (ör. P95 LCP, 5xx oranı).
-
Örnek: P1 (canlıda kesinti) — ilk yanıt: 15 dk, geçici çözüm: 1 saat, kalıcı çözüm: 24 saat.
-
Netlik: “Çözüm” ile “geçici çözüm” (workaround) ayrımı yazılı olsun.
Ölçüm: Aylık raporda hedeflerin yüzde karşılaması ve kaç SLA ihlali olduğu.
3) Çalışma Saatleri ve Kapsam: 8×5 mi, 24×7 mi?
-
Standart: 8×5 (mesai), Genişletilmiş: 8×5 + çağrı (on-call), Kritik: 24×7 NOC.
-
Bölgesel gereksinim: Farklı saat dilimleri için “takvimli nöbet” planı.
-
P1/P2 ayrımı: 24×7 genellikle yalnız yüksek önceliğe uygulanır; P3/P4 mesai içi.
4) Çok Katmanlı Destek Modeli: L0–L3
-
L0 (Self-Service): KBA/SSS, runbook’lar, otomasyon formları.
-
L1: İlk temas, triage, basit çözümler.
-
L2: Konfigürasyon, entegrasyon, performans ve güvenlik incelemeleri.
-
L3: Kod, çekirdek ve karmaşık mimari meseleler.
Amaç: L0 payını büyütmek → toplam maliyeti ve çözüm süresini düşürmek.
5) İletişim Kanalları: Tek Bilet Kapısı ve Canlı Hatlar
-
Bilet sistemi (tek kapı): Kategoriler, öncelikler, alanlar (URL, ekran görüntüsü, etki).
-
Gerçek zamanlı: Slack/Teams/telefon yalnız P1/P2’de; kayıt altına alınıp bilete bağlanır.
-
Durum sayfası: Planlı bakım ve olay güncellemeleri; abonelik/uyarı.
6) Eskalasyon Zinciri ve “Break-Glass” Prosedürü
-
Eskalasyon: Belirli sürede ilerleme yoksa L2→L3 ve yöneticilere otomatik yükseltme.
-
Break-glass: Acil erişim yükseltme (süreli, log’lu); olaysız kullanım yasak.
-
Şeffaflık: Olay raporlarında zincir adımları ve zaman çizelgesi yer almalı.
7) Gözlemlenebilirlik: Log–Metrik–İz Entegrasyonu
-
Log: HTTP, uygulama (CMS), WAF/edge, sistem logları merkezi toplanır.
-
Metrik: TTFB, 5xx/4xx, P95 yanıt, CWV, kuyruk uzunluğu, DB yavaş sorgu.
-
İz (Trace): Sorunu kimin/nerenin tetiklediği görünür olur.
Destek etkisi: Olay triage süresi kısalır, SLA ihlalleri azalır.
8) KBA (Knowledge Base) ve Runbook Kültürü
-
KBA: “Nasıl yapılır?” makaleleri; kısa, ekran görüntülü, rol bazlı.
-
Runbook: Olay ve bakım adımları; Koşul → Adımlar → Geri dönüş planı → Onay.
-
Güncellik: 6 ayda güncellenmeyen sayfalara otomatik uyarı; sahiplik ataması.
9) Otomasyon ve “Shift-Left” Destek
-
Formlar: Erişim talebi, yönlendirme, cache purge, sitemap ping, cron durdur/başlat.
-
Botlar: KBA önerisi, log anomalisi özeti, bundle boyutu uyarısı.
-
Hedef: L1’i rahatlatıp L2/L3’ün stratejik işe odaklanmasını sağlamak.
10) Güvenlik Boyutu: Olaylara Hazırlık ve Uyum
-
Sertleştirme: WAF, hız kısıtlaması, güvenlik başlıkları (CSP/HSTS), çerez politikası.
-
2FA/SSO: Panele erişen destek ekibinde zorunlu.
-
Uyum: KVKK/GDPR ve log/PII politikaları; veri silme/maskeleme runbook’u.
-
Olay tatbikatı: Phishing/hesap ele geçirme senaryoları; 90 dakikalık masaüstü alıştırma.
11) Performans ve CWV Odaklı Destek
-
Pano: LCP/INP/CLS (RUM + sentetik), edge hit ratio, TTFB.
-
Playbook: “LCP > hedef” olduğunda kontrol listesi (kritik CSS, hero preload, görsel boru hattı).
-
A/B deneyleri: Değişikliğin etkisi görünür raporlanır.
12) SEO & Erişilebilirlik Entegrasyonu
-
Otomatik kontrol: Canonical/hreflang/schema/robots testleri; kırmızıysa yayın yok.
-
A11y denetimi: Lighthouse/Axe raporları; kritik hatalar için destek bileti şablonu.
-
Raporda: “Tarama hataları”, “schema kapsamı”, “a11y blokajları”.
13) Entegrasyon Destekleri: Ödeme, PIM/DAM, Kimlik, Arama
-
SLA bağımlılığı: Dış servislerin SLA’ları haritada; olayı sınırlamak için circuit breaker.
-
Sandbox: Güncelleme/kontrat testlerinde zorunlu.
-
Gölgeleme: Prod’da sorun esnasında degrade akışları (ör. basit arama modu).
14) Çoklu Site ve Çok Dilli Destek
-
Kalıp: Ortak kod tabanı + site bazlı konfig; config split ve sürüm notu.
-
Hreflang & yönlendirme: Bölge/dil özel politikalar; test/checklist standardı.
-
Bölgesel on-call: Yoğun pazarların yerel saatlerinde nöbet.
15) Eğitim ve Koçluk Destekleri
-
Hedef: Destek bağımlılığını azaltmak.
-
Paketler: Editör üretkenliği, geliştirici güvenlik/perf, DevOps gözlemlenebilirlik, SEO teknik müfredat.
-
Ölçüm: Sınav/sertifika, PR inceleme geri bildirimi, içerik hataları metriği.
16) Sözleşmesel Güvenceler ve Cezai Şartlar
-
SLA ihlali: Kredi/indirim ve düzeltici aksiyon planı (CAPA).
-
Çıkış maddeleri: Bilgi/belge devri, KBA/runbook sahipliği, ortam erişimlerinin kapatılması.
-
Gizlilik: DPA/SCC, alt yüklenici yönetimi.
17) Maliyet Modelleri: Saatlik, Paket, Sonuç Bazlı
-
Saatlik/ön ödemeli paket: Esnek, ama tahmin güç.
-
Katmanlı abonelik: L0–L3 kota + 24×7 P1/P2; fazlası birim fiyat.
-
Sonuç odaklı: KPI anlaşmalı (ör. CWV/SEO iyileşmesi, olay MTTR düşüşü).
Tavsiye: Hibrit; kritikler için abonelik + proje bazlı talepler.
18) KPI ve Raporlama
-
Operasyonel: İlk yanıt/çözüm süresi, yeniden açılan bilet oranı, ilk temas çözüm oranı.
-
Teknik: 5xx/4xx, TTFB, LCP/INP/CLS, edge hit, indeksleme hataları, uptime.
-
İş: Dönüşüm oranı, organik görünürlük, sayfa üretim süresi, destek bileti trendi.
-
Görselleştirme: Aylık yönetim özeti + teknik ek.
19) Tedarikçi Ekosistemi ve Roller
-
Ajans vs. ürün şirketi: CMS çekirdek bilgisi ve topluluk katkısı fark yaratır.
-
Uzman havuzu: Güvenlik, performans, SEO, erişilebilirlik, altyapı gibi alt uzmanlıklar.
-
Back-to-back SLA: Üçüncü taraflarla zincirleme SLA yönetimi.
20) PoC Aşamasında Destek Testi
-
Simülasyon: “P2 performans düşüşü” senaryosunda tedarikçiyle birlikte 2 saatlik alıştırma.
-
Teslim: Olay raporu, RCA/CAPA, önerilen iyileştirmeler.
-
Değerlendirme: İletişim hızı, teknik doğruluk, belge kalitesi.
21) Güvenlik Olayı Oyunu (Tabletop Exercise)
-
Senaryo: Kimlik sağlayıcı hatası + bot saldırısı; WAF, rate limit, 2FA zorlaması.
-
Başarı ölçütü: RTO hedefi, kullanıcı iletişimi, log/kanıt seti bütünlüğü.
-
Çıktı: Güncellenmiş runbook ve yeni otomasyon maddeleri.
22) Değişiklik Yönetimi: CAB, Versiyon Notları, Canary
-
CAB: Major güncelleme ve kritik entegrasyon değişimlerinde onay.
-
Canary/rollback: Tek komutla dönüş; monitörleme ve PR’a bağlı kanıt.
-
Versiyon notu: Editör/geliştirici/SEO’ya özel özet + etkiler.
23) Olay Sonrası RCA ve Öğrenme Döngüsü
-
RCA raporu: Kök neden, etki, zaman çizelgesi, CAPA ve sahiplik.
-
Paylaşım: Aylık “öğrenilenler” oturumu; KBA’ya yansıtma.
-
Metrik: Aynı sınıf olayın tekrar oranı.
24) 90 Günlük Uygulama Planı
-
Ay 1: SLA/SLO taslağı, L0/L1/L2/L3 iş akışları, bilet şeması, temel panolar, ilk runbook’lar.
-
Ay 2: Otomasyon formları, olay tatbikatı, KBA yayımlama, canary/rollback süreci, SEO & CWV kapıları.
-
Ay 3: Eğitim paketleri, PoC destek testi, KPI raporlama ritmi, sözleşmesel cezai şartların netleşmesi.
25) Karar Matrisi: Destek Hizmetleri Puanlama Ölçütleri
-
SLA kalitesi (20%): Yanıt/çözüm hedefleri, 24×7 kapsamı.
-
L0/L1 olgunluğu (15%): KBA/runbook, otomasyon.
-
Gözlemlenebilirlik entegrasyonu (15%): Log/metric/trace, pano ve alarmlar.
-
Güvenlik & uyum (10%): 2FA/SSO, WAF, KVKK/GDPR.
-
Eğitim/koçluk (10%): Rol bazlı programlar, sertifikasyon.
-
PoC performansı (10%): Senaryo çalışması çıktıları.
-
Maliyet modeli (10%): Şeffaflık, ölçeklenebilirlik.
-
Referans ve topluluk katkısı (10%): Çekirdek/ekosistem deneyimi.
Sonuç: Teknik Destek, CMS Kararının “Sürdürülebilirlik Motoru”dur
CMS seçiminde “destek”i yalnız “biri telefona baksın” beklentisi olarak görmek, üretim gerçekliğinde ağır bedeller doğurur. Destek; SLA/SLO, çok katmanlı model (L0–L3), gözlemlenebilirlik entegrasyonu, KBA/runbook kültürü, shift-left otomasyon, güvenlik ve uyum, performans–SEO–erişilebilirlik eksenlerinde ölçülen ve iyileştirilen bir sistemdir. Bu yazıdaki çerçeveyle; tedarikçi ve iç ekibinizin rollerini netleştirip, riskleri düşürür, yanıt/çözüm sürelerini hızlandırır, toplam maliyeti dengeleyip üretim kalitesini artırırsınız.
Öneri: Önce SLA/SLO taslağınızı yazın, bilet–kanal–eskalasyon akışını kurun, KBA/runbook iskeletini yayınlayın. Gözlemlenebilirlik panolarını (TTFB, 5xx, LCP/INP/CLS, edge hit) tamamlayın; canary/rollback hazır hale getirin. Ardından otomasyon formları ve olay tatbikatlarını devreye alıp aylık KPI raporlamasına geçin. Böylece “destek”, sorun çıktığında aranan bir departman değil; sürekli kalite ve hız üreten bir organizasyon haline gelir.