Web Bakım Sözleşmesinde SLA: Yanıt Süresi, Kapsam ve Ölçüm

Bakım sözleşmesindeki “7/24 destek” ve “hızlı müdahale” ifadeleri, site düştüğü gün hiçbir şey taahhüt etmediği anlaşılan cümlelerdir. Ölçülebilir bir SLA (Service Level Agreement, hizmet seviyesi anlaşması) hangi olayın hangi önceliğe gireceğini, saatin ne zaman başlayıp ne zaman duracağını ve sonucun nasıl raporlanacağını yazar. Aşağıdaki çerçeve kurumsal web siteleri için bakım ve destek sözleşmesinde SLA’nın nasıl kurulacağını hem hizmeti alan IT ekibi hem de hizmeti veren taraf açısından ele alıyor; fiyatlandırmaya girmiyor.

Bakım sözleşmesinin kapsamı neleri içermeli

SLA kapsamın üzerine kurulur. Kapsam belirsizse her talep “bu bakım mı, geliştirme mi?” tartışmasıyla başlar ve süre ölçümü anlamını yitirir. Saat işlerken taraflar madde yorumluyor olur. Kapsam bölümü en az şu başlıkları açıkça listelemeli:

Başlık	Kapsam içi örnekler	Genellikle kapsam dışı
Güncelleme	Çekirdek, eklenti ve tema güncellemesi, staging testi	Ana sürüm geçişinden doğan yeniden geliştirme
Güvenlik	Yama, zafiyet takibi, şüpheli dosya incelemesi	Kapsamlı sızma testi
Yedekleme	Düzenli yedek, periyodik geri yükleme testi	Sunucu dışı arşiv altyapısının kurulması
İzleme	Uptime, SSL süresi, alan adı süresi takibi	Sunucu donanımı izleme (hosting ayrıysa)
Hata giderme	Mevcut işlevin bozulmasının düzeltilmesi	Yeni işlev eklenmesi
İçerik desteği	Sınırlı sayıda içerik ve görsel değişikliği	Yeni sayfa tasarımı, içerik üretimi
Raporlama	Aylık SLA ve bakım raporu	Pazarlama ve analitik raporları

Kapsam dışı işler yasak değildir; ayrı talep türü olarak, ayrı süre ve onay süreciyle işlenir. Bu ayrım ölçümü korur: yeni bir özellik talebi, kritik hata için tanımlanan çözüm süresinin içine girmez.

İkinci mesele sorumluluk sınırıdır. Site, hizmet sağlayıcının yönetmediği bir hostingde çalışıyorsa sağlayıcı sunucu kesintisi için erişilebilirlik taahhüdü veremez; yalnız tespit ve hosting firmasına eskalasyon taahhüt edebilir. Yönetmediğin altyapıyı garanti edemezsin. Aynı mantıkla ERP, ödeme sağlayıcısı veya CRM gibi üçüncü taraf sistemlerdeki arızalar için sözleşmede “bağımlı sistem” maddesi bulunmalı. Alan adı ve DNS paneline kimin erişimi olduğu da bu maddede yazılır; sahada en uzun süren kesintilerin bir kısmı, DNS kaydını değiştirebilecek kişiye ulaşılamamasından çıkar.

Öncelik sınıfları ve örnek SLA matrisi

Öncelik, talebi açanın aciliyet hissine göre değil, önceden yazılmış ölçütlere göre belirlenir. İki eksen kullanılır: etki (kaç kullanıcı, hangi iş süreci) ve aciliyet (geçici çözüm var mı, zarar zamanla büyüyor mu). Aşağıdaki matris bir başlangıç noktasıdır; süreler kurumun ihtiyacına ve hizmetin kapsamına göre müzakere edilir.

Öncelik	Tanım (örnek)	Yanıt süresi (örnek)	Çözüm hedefi (örnek)
P1 – Kritik	Site erişilemiyor, ödeme veya form tamamen çalışmıyor, aktif güvenlik ihlali	1 saat, 7/24	4 saat içinde geçici veya kalıcı çözüm
P2 – Yüksek	Önemli bir işlev bozuk, geçici çözüm var veya etki sınırlı	4 iş saati	2 iş günü
P3 – Normal	Görsel hata, tek sayfada sorun, işlevi engellemeyen hata	1 iş günü	5 iş günü veya sonraki bakım penceresi
P4 – Talep	Bilgi isteği, küçük içerik değişikliği, iyileştirme önerisi	2 iş günü	Planlamaya göre

Matrisi işler kılan tanım sütunudur. “Site yavaş” şikâyeti P1 mi, P3 mü? Tanımlar somut örneklerle yazılırsa bu tartışma talep anında değil, sözleşme masasında yapılmış olur. Önceliği kimin, hangi gerekçeyle yükseltip düşürebileceği de yazılmalı.

“7/24” ile “iş saati” ayrımını da netleştirin: iş saatleri hangi saat dilimine göre, hangi günleri kapsıyor, resmi tatiller nasıl sayılıyor? P1 için 7/24 yanıt taahhüt ediliyorsa mesai dışı bildirim kanalı (telefon, nöbet hattı) ayrıca tanımlanır. Gece e-postayla gelen P1 sabaha kadar okunmayabilir. Kanal yoksa taahhüt de yoktur.

Yanıt süresi ile çözüm süresi ayrımı

Sözleşmelerde en sık rastladığımız belirsizlik “müdahale süresi”nin neyi ölçtüğüdür. Ölçülebilir bir SLA’da üç ayrı zaman damgası tanımlanır:

• Yanıt (ilk müdahale) süresi: Talebin kayda girmesinden, yetkin bir kişinin talebi inceleyip ilk anlamlı geri dönüşü yapmasına kadar geçen süre. Otomatik “talebiniz alındı” e-postası yanıt sayılmaz.
• Geçici çözüm süresi: İş sürecinin yeniden çalışır hale gelmesine kadar geçen süre; örneğin bozulan bir eklentinin önceki sürüme döndürülmesi.
• Kalıcı çözüm süresi: Kök nedenin giderilmesi. P1 olaylarında kalıcı çözüm, geçici çözümden sonra P2 veya P3 olarak ayrı izlenebilir.

Saatin durdurulma koşulları (clock stop) da yazılı olmalı. Tipik nedenler: müşteriden bilgi veya erişim beklenmesi, müşterinin onaylaması gereken bir değişiklik, üçüncü taraf sağlayıcının yanıtı. Bu nedenler talep sisteminde ayrı bir durum olarak tutulmazsa ay sonunda hangi sürenin kimden kaynaklandığı tartışmaya döner. Kayıt yoksa ölçüm de yoktur.

Planlı bakım, acil müdahale ve geliştirme talepleri

Bakım işleri üç ayrı akışta ilerler ve her birinin kuralı farklıdır.

Planlı bakım: Güncellemeler, yedek testleri, performans kontrolleri. Önceden duyurulan bir bakım penceresinde yapılır. Bu pencerede yaşanan planlı kesinti erişilebilirlik hesabından düşülür; bunun için pencerenin süresi, sıklığı ve duyuru süresi sözleşmede tanımlı olmalı. Güncellemelerin hangi test akışıyla yapılacağı ayrıca WordPress güncelleme politikası belgesiyle tanımlanıp sözleşmeye ek olarak bağlanabilir.

Acil müdahale: P1 ve P2 olayları, kritik güvenlik yamaları. Bakım penceresini beklemez. Ama acil değişiklik de kayda girer ve olaydan sonra kısa bir kök neden notu yazılır; yazılmayan not, aynı arızanın üç ay sonra tekrar etmesi demektir.

Geliştirme talepleri: Yeni sayfa, yeni işlev, entegrasyon değişikliği. SLA sürelerine değil, kapsam ve takvim mutabakatına tabidir. Birçok sözleşme aylık bir saat havuzu tanımlayarak küçük geliştirmeleri bakım içinde karşılar; havuzun kullanımı aylık raporda gösterilir. Havuzun bir kısmı biriken teknik borcun azaltılması için ayrılabilir.

SLA ölçümü ve aylık raporlama

Ölçülemeyen taahhüt raporlanamaz. Ölçüm kaynakları sözleşmede adıyla yazılır: talepler için bir kayıt sistemi (helpdesk), erişilebilirlik için harici bir izleme aracı. İki taraf da bu kaynaklara erişebilmeli; yalnız sağlayıcının gördüğü bir panel, müşteri açısından ölçüm değildir.

Erişilebilirlik ölçümü

Erişilebilirlik taahhüdü verilecekse ölçüm yöntemi en az şu soruları cevaplamalı: Hangi URL’ler izleniyor (yalnız ana sayfa mı, form ve ödeme adımları da mı)? Kontrol sıklığı nedir? Kaç ardışık başarısız kontrol kesinti sayılır? Kontrol kaç farklı konumdan yapılıyor? Planlı bakım nasıl hariç tutuluyor? Ana sayfa 200 dönerken ödeme adımı 500 veriyorsa yalnız ana sayfayı izleyen araç “site ayakta” der.

Yüzde hedeflerin dakika karşılığı sözleşmede yazılırsa beklenti netleşir. Örnek hesap: 30 günlük bir ay 43.200 dakikadır. %99,9 erişilebilirlik bu ayda yaklaşık 43 dakika, %99,5 ise yaklaşık 216 dakika (3 saat 36 dakika) kesintiye izin verir. Kontrol aralığı 5 dakika olan bir izleme aracı birkaç dakikalık kesintileri hiç görmeyebilir veya 5 dakikalık adımlarla ölçer. Hedef ile ölçüm hassasiyeti birbirine uymalı.

Talep ölçümü ve rapor içeriği

Aylık rapor, sözleşmedeki her taahhüdün karşılığını göstermeli. Önerilen içerik:

• Önceliğe göre açılan ve kapanan talep sayısı
• Her öncelik için yanıt ve çözüm süresi hedefini karşılayan ve aşan talepler, aşımların gerekçesi
• Saati durdurulmuş talepler ve durdurma nedenleri
• Ölçülen erişilebilirlik, kesinti olayları ve kök neden notları
• Yapılan güncellemeler (bileşen, eski ve yeni sürüm), yedek geri yükleme testinin sonucu
• Geliştirme saat havuzunun kullanımı
• Bir sonraki ay için önerilen iyileştirmeler ve açık riskler

Hedef aşımlarının sonucu (hizmet kredisi, ek çalışma saati veya iyileştirme planı) sözleşmede tanımlanır. Ölçülemeyen kalem için yaptırım yazmak iki taraf için de boş bir tartışma üretir; yaptırım yalnız ölçüm kaynağında mutabık kalınmış kalemlere bağlanmalı. Entegrasyonların sessiz hatalarının nasıl izleneceği, raporun teknik altyapısı için entegrasyon izleme ve mutabakat rehberinde anlatılıyor.

Hizmet yönetimi süreçlerini kurumsal bir çerçeveye oturtmak isteyen ekipler için ISO/IEC 20000-1 hizmet seviyesi yönetimi gerekliliklerini tanımlar. Küçük bir bakım sözleşmesi için standardın tamamını uygulamak gerekmez; terimleri ortak bir dile oturtmak için iyi bir başvuru kaynağıdır.

Sözleşme öncesi kontrol listesi

Teklif değerlendirirken veya taslağı incelerken aşağıdaki soruların yazılı cevabı olmalı:

• Kapsam içi ve kapsam dışı işler örneklerle listelenmiş mi?
• Öncelik tanımları somut örnek içeriyor mu; önceliği kim belirliyor?
• Yanıt, geçici çözüm ve kalıcı çözüm süreleri ayrı ayrı tanımlı mı?
• İş saatleri, saat dilimi ve tatil günleri belirtilmiş mi; mesai dışı P1 kanalı var mı?
• Saatin durdurulma koşulları yazılı mı?
• Planlı bakım penceresi, sıklığı ve duyuru süresi tanımlı mı?
• Erişilebilirlik hedefi varsa ölçüm aracı, kontrol sıklığı ve izlenen URL’ler belirtilmiş mi?
• Hosting, alan adı, DNS ve üçüncü taraf sistemlerin sorumluluk sınırları net mi?
• Yedekleme sıklığı, saklama süresi ve geri yükleme testi taahhüdü var mı?
• Aylık raporun içeriği ve teslim tarihi belirtilmiş mi?
• Yönetici hesapları, lisanslar ve erişim bilgilerinin sahipliği ve sözleşme bitiminde devri tanımlı mı?

Son madde en sık unutulandır. Lisans hesapları ve yönetici erişimi sağlayıcının adına kayıtlıysa, sözleşme bittiğinde site sahibi kendi sitesine erişmekte zorlanabilir. Sahibi belli olmayan erişim, risktir. Talep kayıtlarını Microsoft 365 üzerinde tutan kurumlar için Microsoft 365 ile helpdesk kurulumu rehberi ölçüm altyapısına örnek olabilir. Kapsamı ve SLA’sı tanımlı bir bakım hizmeti için web sitesi bakım ve destek sözleşmeleri, erişilebilirlik ölçümünü kurmak için web izleme ve uptime monitoring sayfalarına bakılabilir.

Sık sorulan sorular

Yanıt süresi ile çözüm süresi arasındaki fark nedir?

Yanıt süresi, talebin yetkin bir kişi tarafından incelenip ilk anlamlı geri dönüşün yapılmasına kadar geçen süredir. Çözüm süresi, iş sürecinin yeniden çalışır hale gelmesine veya kök nedenin giderilmesine kadar geçen süredir. Sözleşmede ikisi ayrı ayrı tanımlanmalı.

Hosting başka firmadaysa bakım sağlayıcısı erişilebilirlik taahhüdü verebilir mi?

Sunucu ve ağ kesintileri için veremez; o altyapıyı yönetmez. Bu durumda sağlayıcı kesintiyi tespit etme, hosting firmasına bildirme ve uygulama tarafındaki sorunları çözme sürelerini taahhüt edebilir.

SLA ölçümünde saat ne zaman durdurulur?

Tipik olarak müşteriden bilgi, erişim veya onay beklendiğinde ve üçüncü taraf bir sağlayıcının yanıtı beklendiğinde. Durdurma koşulları sözleşmede yazılı olmalı ve talep sisteminde ayrı bir durum olarak kaydedilmeli.

Aylık SLA raporunda neler olmalı?

Önceliğe göre talep sayıları, hedefi karşılayan ve aşan talepler ile aşım gerekçeleri, saati durdurulmuş talepler, ölçülen erişilebilirlik ve kesinti olayları, yapılan güncellemeler, yedek testi sonucu ve geliştirme saat havuzunun kullanımı.