Web Sitesi Yönetimi İçin Dış Kaynak Hizmet Sağlayıcısında SLA ve Operasyonel Sorumluluk Kriterleri

Web sitesi yönetimi dış kaynak sağlayıcısı ne üstlenir?

Dış kaynak sağlayıcısı, sözleşmede tanımlanan web sitesi operasyonlarını ve teknik destek işlerini üstlenir; ancak sitenin tüm sonuçlarından otomatik olarak sorumlu hale gelmez. İçerik yayını, yazılım güncellemeleri, yedek takibi veya arıza incelemesi gibi görevler sağlayıcıya verilebilir. İşletme ise içerik doğruluğu, onay, erişim yetkisi ve üçüncü taraf hesaplarının sahipliği gibi sorumlulukları koruyabilir. Bu sınırlar baştan yazılmalıdır.

Hizmet kapsamını iş akışlarıyla tarif edin

“Web sitesinin yönetimi” tek başına yeterince açık bir tanım değildir. Hangi taleplerin hizmet masasına iletileceği, bunların kim tarafından sınıflandırılacağı, onay gerektiren işlerin nasıl bekletileceği ve tamamlanmış işin nasıl bildirileceği açıklanmalıdır. Operasyonel sahiplik ile iş kararlarının sahipliği ayrıldığında sağlayıcıdan beklenen hizmet de daha ölçülebilir hale gelir.

• Günlük içerik ve teknik operasyonların kapsamı belirlenmeli.
• İşletme tarafındaki içerik onayı ve karar sahipleri atanmalı.
• Üçüncü taraf servis ve hesaplarının sorumlusu yazılmalı.
• Hizmet kapsamı dışındaki geliştirme işleri ayrıca tanımlanmalı.

“Önemli olan meşgul olmak değil, neyle meşgul olduğumuzdur.”- Henry David Thoreau

SLA sözleşmesinde hangi hizmet ölçütleri bulunmalı?

SLA sözleşmesinde hizmet saatleri, talep kanalları, olay öncelikleri, yanıt hedefleri, müdahale kapsamı, eskalasyon adımları ve raporlama yöntemi bulunmalıdır. Yanıt süresi ile çözüm süresi birbirinden farklıdır: sağlayıcı talebi belirli bir hedef içinde incelemeye başlayabilir, ancak çözüm üçüncü taraflara veya işletmenin onayına bağlı olabilir. Sözleşme bu ayrımı açıkça göstermelidir.

Hedefleri koşullarıyla birlikte yazın

Her öncelik düzeyinin hangi iş etkisine göre belirleneceğini tanımlayın. Örneğin, sitenin tamamına erişilememesi ile tek bir sayfadaki görsel hatası aynı öncelikte değerlendirilmemelidir. Destek saatleri dışında gelen taleplerin nasıl ele alınacağı ve planlı bakımın kullanıcıya nasıl duyurulacağı da SLA içinde yer almalıdır. Sağlayıcının sunamayacağı bir hizmet seviyesi varsayılmamalı; hedefler tarafların kapasitesine göre kararlaştırılmalıdır.

• Destek saatleri ve başvuru kanalları belirtilmeli.
• Olay önceliği iş etkisine göre tanımlanmalı.
• İlk yanıt ve müdahale hedefleri ayrı yazılmalı.
• İstisnalar, eskalasyon ve planlı bakım yöntemi açıklanmalı.

Arıza ve güvenlik olaylarında müdahale nasıl düzenlenir?

Arıza ve güvenlik olaylarında müdahale; olay bildirimi, sınıflandırma, ilk inceleme, sorumlu ekibe aktarım, güncelleme ve kapanış adımlarını kapsayan bir prosedürle düzenlenmelidir. Teknik arıza, barındırma kesintisi, yazılım hatası ve güvenlik şüphesi aynı ekip veya aynı yetki alanında olmayabilir. Bu nedenle her olay türü için ilk temas noktası ve karar yetkilisi önceden belirlenmelidir.

Yanıt hedefini çözüm garantisi gibi sunmayın

Sağlayıcı, olayı kabul ettiğini ve incelemeye başladığını belirli bir hedef içinde bildirebilir; fakat kalıcı çözüm zamanı dış sistemlere, erişimlere ve problemin nedenine bağlı olabilir. Güvenlik olaylarında erişimi kısıtlama, kayıtları koruma ve işletmenin yetkili kişilerine haber verme sırası önem taşır. Olay sonrası rapor; etkiyi, yapılan işlemleri ve takip aksiyonlarını özetlemelidir.

• Arıza ve güvenlik olayları için ayrı sınıflandırma yapılmalı.
• İlk temas, teknik inceleme ve eskalasyon sorumluları atanmalı.
• Üçüncü taraf kesintilerinde bildirim ve takip yöntemi yazılmalı.
• Olay kapanışında işlem ve öğrenim kaydı paylaşılmalı.

Operasyonel sorumluluklar taraflar arasında nasıl paylaşılır?

Operasyonel sorumluluklar, her işin kim tarafından başlatılacağını, onaylanacağını, uygulanacağını ve kontrol edileceğini belirleyen bir görev matrisiyle paylaşılmalıdır. İçerik güncellemesinde işletme metin ve görsellerin doğruluğunu onaylarken sağlayıcı bunları sisteme aktarabilir. Sunucu kaynaklı sorunlarda sağlayıcı barındırma firmasıyla koordinasyon kurabilir; ancak sunucu sözleşmesinin sahibi işletme olabilir. Bu ayrım, gecikmelerde sorumluluk belirsizliğini azaltır.

Bağımlılıkları ve onay noktalarını gösterin

Üçüncü taraf entegrasyonundaki değişiklik, alan adı veya DNS ayarı, ödeme altyapısı ya da analitik hesabı gibi alanlarda doğrudan yetkili taraf belirlenmelidir. Sağlayıcının işlem yapabilmesi için gerekli erişimlerin kim tarafından ve hangi yöntemle verileceği de yazılmalıdır. Bakım, güvenlik güncellemesi ve müdahale süresinin hizmet kapsamına nasıl yansıdığını incelemek, bu görevlerin teklif ve sözleşmede ayrı görünmesine yardımcı olur.

• İçerik, teknik uygulama ve nihai onay sahipleri belirlenmeli.
• Barındırma, alan adı ve entegrasyon sorumluları yazılmalı.
• Erişim verme ve erişim kaldırma prosedürü tanımlanmalı.
• İşletme onayı beklenen durumlarda süre hesabı açıklanmalı.

İş takip sistemi ve raporlama kalitesi nasıl ölçülür?

Operasyonel yeterlilik, sağlayıcının talepleri kayıt altına alması, önceliklendirmesi, sorumlulara ataması ve sonuçları raporlaması üzerinden ölçülebilir. E-posta yazışmaları tek başına düzenli bir iş takibi sağlamayabilir. Sağlayıcıdan kullanılan iş takip yöntemini, müşteri görünürlüğünü ve açık taleplerin nasıl izleneceğini açıklamasını isteyin. Raporlar yapılan iş kadar bekleyen bağımlılıkları da göstermelidir.

Raporu karar vermeye yarar hale getirin

Periyodik rapor; tamamlanan işler, bekleyen talepler, tekrarlayan sorunlar, güncelleme durumu, yedekleme kontrolleri ve sonraki dönem risklerini içerebilir. Sadece talep sayısı veya çalışma süresi sunulması hizmetin niteliğini anlamaya yetmeyebilir. İşletmenin karar almasını sağlayacak göstergeler seçilmeli ve bunların hangi sıklıkta paylaşılacağı sözleşmede belirlenmelidir.

• Her talep için kayıt numarası ve güncel durum sağlanmalı.
• Öncelik, sorumlu kişi ve bekleyen aksiyon izlenebilmeli.
• Raporlarda tamamlanan ve geciken işler ayrıştırılmalı.
• Yedekleme ve bakım işlemlerinin kanıtı paylaşılmalı.

Yedekleme ve hizmet sürekliliği nasıl doğrulanır?

Hizmet sürekliliği, yedeklerin alınması kadar geri yükleme sürecinin, erişimlerin ve kritik teknik bilgilerin de planlanmasıyla değerlendirilir. Sağlayıcıdan yedekleme sıklığını, saklama koşullarını, geri yükleme yetkisini ve bir sorun halinde izlenecek adımları öğrenin. Sitenin altyapısına ve kullanılan hizmetlere bağlı olarak sorumluluklar işletme, yazılım sağlayıcısı ve barındırma firması arasında paylaşılabilir.

Prosedürün uygulanabilirliğini sınayın

Yedek alınması tek başına çalışır bir kurtarma planı bulunduğunu kanıtlamaz. Geri yükleme testinin hangi kapsamda ve kim tarafından yapılacağı, hizmet kesintisinde hangi iletişim kanalının kullanılacağı ve kritik kararları kimin vereceği belirlenmelidir. Bakım, güvenlik ve SLA maliyetlerinin profesyonel web sitesi hizmetinde nasıl hesaba katıldığını anlatan içerik, bu kalemlerin kapsamla ilişkisini değerlendirmeye yardımcı olur.

• Yedekleme sıklığı ve saklama süresi tanımlanmalı.
• Geri yükleme yetkisi ve test sorumluluğu belirtilmeli.
• Kesinti sırasında iletişim ve karar zinciri oluşturulmalı.
• Yedek, alan adı ve kritik hesap erişimleri düzenli kontrol edilmeli.

Sözleşme sona erdiğinde devir nasıl güvenceye alınır?

Hizmet sona erdiğinde devir; yönetim paneli ve barındırma erişimlerinin, alan adı kontrolünün, yedeklerin, kaynak kodunun ve teknik dokümantasyonun kararlaştırılmış biçimde teslim edilmesiyle güvenceye alınır. İşletmenin sahip olduğu hesaplar sağlayıcıya ait hesaplardan ayrıştırılmalıdır. Sözleşme, devir takvimini, teslim formatlarını ve geçiş sırasında sağlayıcının vereceği desteği açıklamalıdır.

Devir planını başlangıçta yazın

Son güne bırakılan erişim devri, hizmet kesintisi veya bilgi kaybı riski doğurabilir. Bu nedenle depo erişimleri, lisans kayıtları, yapılandırma bilgileri ve kullanılan üçüncü taraf servisler güncel tutulmalıdır. Sağlayıcı değişiminde kod, erişim ve barındırma devrinin nasıl yönetileceğini incelemek, çıkış sürecini sözleşme maddelerine dönüştürmek için yararlı bir kontrol sunar.

• Alan adı ve kritik hesapların yasal sahibi belirlenmeli.
• Yedek, kaynak kod ve doküman teslim biçimi yazılmalı.
• Geçiş desteği, süre ve varsa ücretlendirme açıklanmalı.
• Erişimlerin kapatılması ve verilerin silinmesi prosedürü eklenmeli.

Hizmet sağlayıcılarını karşılaştırırken ne sorulmalı?

Sağlayıcıları karşılaştırırken benzer senaryolar üzerinden SLA, iş takibi, raporlama, sorumluluk paylaşımı ve devir yaklaşımını sorun. Her firmaya aynı örnek olayları yöneltmek, yanıtların kapsam ve açıklık açısından kıyaslanmasını sağlar. Bir arıza bildiriminin nasıl açıldığını, kritik olayın kime aktarıldığını ve tamamlanan işin hangi kanıtla raporlandığını adım adım anlatmalarını isteyin.

Operasyonel yeterlilik sorularını teklif dosyasına ekleyin

Teklif değerlendirmesinde sunulan saatleri ve hedefleri iş ihtiyaçlarınızla eşleştirin. Sağlayıcının güçlü olduğu alanlar kadar işletmenin üstleneceği sorumlulukları, dış sistemlere bağlılıkları ve kapsam dışı işleri de kaydedin. Böylece uzun vadeli hizmet ilişkisi, beklentiler ve sınırlar baştan anlaşılır şekilde kurulabilir. İdesa uzmanlarıyla yapılacak değerlendirme, mevcut süreçlerinizi inceleyip uygun hizmet planı için ihtiyaçları netleştirmenize yardımcı olabilir.

• Olay önceliğini ve müdahale adımlarını örnekle açıklamalarını isteyin.
• İş takip ekranı ve örnek operasyon raporu talep edin.
• Yedekleme, erişim ve hizmet sonu devir prosedürlerini sorun.
• Dahil işler, sorumluluklar ve istisnaları yazılı karşılaştırın.