Kesinti raporu talep ederken sağlayıcıdan hangi bilgiler istenmeli?

Bir web sitesinde yaşanan erişim sorunu yalnızca teknik bir aksaklık değildir; satış, müşteri deneyimi, reklam performansı ve marka güveni üzerinde doğrudan etkisi olabilir. Bu nedenle kesinti yaşandıktan sonra sağlayıcıdan yalnızca “sorun giderildi” yanıtı almak yeterli değildir. Kurumsal açıdan doğru yaklaşım, olayın zaman çizelgesini, etki alanını, kök nedenini ve tekrarını önlemek için alınan aksiyonları içeren net bir kesinti raporu talep etmektir.

Özellikle kritik uygulamalar, e-ticaret siteleri veya yüksek trafik alan kurumsal projeler için hosting hizmetinin sürekliliği yakından izlenmelidir. Talep edeceğiniz rapor, hem teknik ekiplerin doğru değerlendirme yapmasını sağlar hem de hizmet seviyesi anlaşması, iç denetim ve müşteri bilgilendirmesi gibi süreçlerde kanıt niteliği taşır.

Kesinti raporunda mutlaka bulunması gereken temel bilgiler

Sağlayıcıdan istenecek bilgiler, olayın yalnızca ne zaman başladığını değil, neden yaşandığını ve ne kadar etkili olduğunu da açıklamalıdır. Raporun eksik olması, aynı problemin tekrar etmesi halinde karar almayı zorlaştırır.

Kesintinin başlangıç ve bitiş zamanı

Raporda kesintinin başlangıç saati, tespit saati, müdahale başlangıcı ve hizmetin tamamen normale döndüğü zaman ayrı ayrı belirtilmelidir. Burada saat dilimi özellikle önemlidir. “10:15’te sorun başladı” ifadesi yerine “10:15 GMT+3” gibi net zaman bilgisi istenmelidir.

Ayrıca kısmi erişim sorunları ile tam kesinti birbirinden ayrılmalıdır. Bazı durumlarda site tamamen kapalı değildir; ancak yönetim paneli, ödeme adımı, e-posta servisi veya veritabanı bağlantısı etkilenmiş olabilir.

Etkilenen hizmetler ve kapsam

Kesinti raporu, hangi servislerin etkilendiğini açıkça göstermelidir. Web sunucusu, veritabanı, DNS, e-posta, kontrol paneli, yedekleme sistemi veya ağ altyapısı ayrı ayrı değerlendirilmelidir.

Bu bölümde şu sorulara yanıt aranmalıdır:

• Kesinti yalnızca belirli bir sunucu üzerinde mi yaşandı?
• Aynı veri merkezindeki diğer müşteriler de etkilendi mi?
• Sorun belirli lokasyonlardan erişimde mi görüldü?
• IPv4, IPv6, DNS veya SSL tarafında ayrı bir problem oluştu mu?

Kök neden analizi neden kritik?

Bir kesinti raporunun en önemli kısmı kök neden analizidir. “Ağ problemi yaşandı” veya “teknik arıza oluştu” gibi genel ifadeler kurumsal değerlendirme için yeterli değildir. Sağlayıcıdan olayın teknik nedeni, tetikleyici faktörleri ve problemin hangi katmanda ortaya çıktığı açıkça istenmelidir.

Örneğin donanım arızası, yanlış yapılandırma, kapasite aşımı, DDoS saldırısı, bakım sürecindeki hata veya veri merkezi kaynaklı enerji problemi birbirinden çok farklı riskler taşır. Her birinin tekrarını önlemek için alınacak önlemler de farklıdır.

İlk müdahale ve düzeltici aksiyonlar

Raporda yalnızca neden değil, nasıl müdahale edildiği de yer almalıdır. Teknik ekibin hangi adımları attığı, geçici çözüm uygulanıp uygulanmadığı ve kalıcı düzeltmenin ne zaman tamamlandığı belirtilmelidir.

Burada özellikle geçici çözüm ile kalıcı çözüm ayrımına dikkat edilmelidir. Servisin yeniden erişilebilir olması, problemin tamamen ortadan kalktığı anlamına gelmeyebilir. Sağlayıcıdan “kalıcı önlem” başlığı altında yapılan veya planlanan işlemler ayrıca talep edilmelidir.

SLA, tazminat ve hizmet seviyesi bilgileri

Kurumsal sözleşmelerde hizmet sürekliliği genellikle SLA ile tanımlanır. Kesinti sonrası raporda toplam erişilemezlik süresi, SLA kapsamına girip girmediği ve varsa telafi prosedürü net şekilde belirtilmelidir.

Bu aşamada yalnızca tazminat odaklı düşünmek doğru değildir. Asıl değer, hizmetin taahhüt edilen seviyede çalışıp çalışmadığını ölçebilmektir. hosting sağlayıcınızdan aylık kullanılabilirlik oranı, bakım pencereleri ve planlı/plansız kesinti ayrımı hakkında doğrulanabilir veri istemeniz faydalı olur.

Log, izleme ve kanıt niteliğindeki veriler

Sağlayıcının paylaşabileceği teknik kayıtlar, olayın doğrulanması için önemlidir. Her log müşteriye açık şekilde verilmeyebilir; ancak raporda izleme sistemi çıktıları, alarm zamanları, hata kodları ve erişim testleri özetlenebilir.

Özellikle kendi izleme aracınız farklı süreler gösteriyorsa, sağlayıcıdan ölçüm metodolojisini açıklamasını isteyin. Hangi lokasyonlardan kontrol yapıldığı, kontrol aralığı ve hangi servislerin izlendiği net değilse süre hesaplamalarında anlaşmazlık yaşanabilir.

Sağlayıcıya gönderilebilecek pratik bilgi talep listesi

Talebinizi kısa ama kapsamlı hazırlamak yanıt kalitesini artırır. Aşağıdaki maddeler destek kaydına doğrudan eklenebilir:

• Kesintinin başlangıç, tespit, müdahale ve çözüm saatleri
• Etkilenen servisler, sunucu bilgisi ve etki kapsamı
• Kök nedenin teknik açıklaması
• Uygulanan geçici ve kalıcı düzeltici aksiyonlar
• Tekrar yaşanmaması için alınan önlemler
• SLA kapsamında hesaplanan erişilemezlik süresi
• Varsa bakım, kapasite, güvenlik veya ağ kaynaklı bağlantılar
• İzleme kayıtları, hata kodları veya olay referans numarası

Raporu değerlendirirken sık yapılan hatalar

En yaygın hata, kesintinin yalnızca süresine odaklanmaktır. Oysa beş dakikalık bir kesinti ödeme sistemini etkilediyse, bir saatlik statik sayfa erişim probleminden daha kritik olabilir. Etkiyi iş süreçleriyle birlikte değerlendirmek gerekir.

Bir diğer hata, her kesintiyi sağlayıcı değişikliği gerekçesi olarak görmektir. Tekil bir olaydan önce rapor kalitesi, müdahale hızı, şeffaflık ve tekrar önleme planı incelenmelidir. Buna karşılık aynı tür problem düzenli şekilde tekrarlanıyor ve net aksiyon alınmıyorsa, altyapı mimarisi ve hizmet modeli yeniden değerlendirilmelidir.

Rapor talebinizi yazılı kanaldan iletmek, ileride yapılacak teknik analizler ve sözleşme değerlendirmeleri için düzenli kayıt oluşturur. Kritik projelerde bu raporları tarih bazlı saklamak, sunucu performansı, erişilebilirlik trendleri ve sağlayıcı güvenilirliği hakkında daha sağlıklı karar vermenize yardımcı olur.