Hizmet Durumu

Hizmet Durumu sayfası; Nettescil hizmetleriyle ilgili planlı bakım, doğrulanmış kesinti, performans sorunu ve önemli operasyonel duyuruların anlaşılır biçimde paylaşılabilmesi için oluşturulmuştur. Bu sayfa, gerçek bir izleme kaynağından otomatik veri alınmadığı durumlarda servisleri varsayılan olarak “çalışıyor” göstermeyi amaçlamaz. Güncel bir durum bilgisi yalnızca doğrulanmış bir olay, bakım kaydı veya operasyonel değerlendirme bulunduğunda yayınlanmalıdır.

Genel sistem durumu nasıl değerlendirilir?

Bir web sayfasının açılması, tek başına bütün hizmetlerin sağlıklı olduğunu kanıtlamaz. Web hosting, DNS, e-posta, müşteri paneli, lisans servisi, ödeme akışı ve destek sistemi farklı bileşenlere sahiptir. Bir bileşendeki sorun diğer hizmetleri etkilemeden devam edebilir veya bir DNS problemi web sitesini etkilerken sunucunun kendisi çalışıyor olabilir. Bu nedenle hizmet durumu değerlendirmesinde erişilebilirlik, hata oranı, etkilenen müşteri veya hizmet grubu, başlangıç zamanı ve olayın devam edip etmediği birlikte ele alınmalıdır.

Web hosting ve reseller hosting

Web hosting durumunda alan adının DNS çözümlemesi, web sunucusu yanıtı, PHP uygulaması, veritabanı, SSL ve dosya erişimi ayrı ayrı incelenebilir. Reseller hosting ortamlarında bayi hesabı, alt müşteri hesapları ve kaynak limitleri de değerlendirmeye dahil olabilir. Bir müşterinin hesabındaki uygulama hatası genel hosting kesintisi anlamına gelmez; aynı şekilde bir DNS sağlayıcısındaki sorun sunucu hizmetinin kapalı olduğu anlamına gelmeyebilir.

VPS, VDS ve dedicated server

VPS, VDS ve dedicated server hizmetlerinde işletim sistemi, sanal kaynaklar, disk, ağ, kontrol paneli, güvenlik duvarı ve müşteri tarafından kurulan servisler ayrı sorumluluk katmanlarıdır. Bu hizmetlerde durum değerlendirmesi yapılırken sunucuya erişim, temel ağ bağlantısı, sistem kaynakları ve ilgili uygulamanın yanıtı birbirinden ayrılmalıdır. Müşteri tarafından yapılan bir yapılandırma değişikliği veya kapatılan bir servis portu, genel veri merkezi kesintisiyle karıştırılmamalıdır.

Domain, DNS ve lisans hizmetleri

Alan adı işlemleri kayıt kuruluşu, DNS, nameserver, WHOIS, transfer kilidi ve müşteri paneli gibi farklı sistemlere bağlı olabilir. Lisans hizmetlerinde ise ürün sağlayıcısı, lisans IP’si, aktivasyon servisi ve otomasyon yanıtı birlikte değerlendirilir. Bu dış bağımlılıklardan biri cevap vermediğinde sipariş, yenileme veya lisans durumunun güncellenmesi gecikebilir. Provider cevabı alınmadan başarılı veya tamamlandı ifadesi kullanılmamalıdır.

Durum sınıfları

Operasyonel bir durum kaynağı oluşturulduğunda aşağıdaki sınıflar kullanılabilir: Çalışıyor, Performans Sorunu, Kısmi Kesinti, Genel Kesinti ve Bakım. Bu sınıflar yalnızca olayın doğrulanmış kapsamını anlatmak için kullanılmalıdır. “Çalışıyor” etiketi, her müşterinin her uygulamasının test edildiği anlamına gelmez; belirli temel kontrollerin sonucu olarak değerlendirilmelidir.

Planlı bakım bildirimleri

Planlı bakım duyurusunda etkilenecek hizmet, planlanan tarih aralığı, beklenen etki, müşterinin yapması gereken bir işlem olup olmadığı ve tamamlanma bilgisi yer almalıdır. Kesin süre doğrulanmadan garanti verilmemeli; bakım tamamlandığında kontrol sonucu ayrıca paylaşılmalıdır. Bakım sırasında ortaya çıkan ek gecikmeler veya kapsam değişiklikleri mümkün olduğunca açık biçimde güncellenmelidir.

Olayların incelenmesi

Beklenmeyen bir olayda önce olayın başladığı zaman, etkilenen URL veya hizmet, hata mesajı, farklı ağlardan alınan test sonucu ve son yapılan değişiklikler toplanır. Ardından DNS, network, sunucu, uygulama, ödeme veya dış sağlayıcı katmanlarından hangisinin etkilendiği ayrıştırılır. Sorun giderildikten sonra yalnızca ana sayfanın açılması değil, etkilenen iş akışının tekrar çalıştığı da doğrulanmalıdır.

Müşterinin yapabilecekleri

Bir erişim sorunu yaşadığınızda alan adının doğru çözümlendiğini, farklı bir ağdan aynı hatanın görülüp görülmediğini, son DNS veya uygulama değişikliğini ve hata zamanını kontrol edin. Şifre, API anahtarı veya lisans kodu paylaşmadan destek talebi oluşturun. Sorun bir sunucu veya uygulama yönetiminden kaynaklanıyorsa ilgili hizmetin loglarını ve son değişikliklerini koruyun. Böylece destek incelemesi daha hızlı ve daha doğru yürütülebilir.

Şeffaflık ve gelecekteki durum entegrasyonu

Gerçek bir monitoring, uptime veya status API kaynağı bulunması halinde bu sayfa doğrulanmış verilerle beslenebilir. Böyle bir entegrasyon; veri kaynağının kimliği, kontrol aralığı, hata toleransı, bakım kayıtları, olay geçmişi ve bildirim mekanizmasıyla birlikte tasarlanmalıdır. Kaynak doğrulanmadan sahte canlı durum kartları göstermek yerine, teyit edilmiş olayları ve bakım açıklamalarını yayınlamak daha güvenilir bir yaklaşımdır.

Teknik altyapı hakkında Altyapımız, network bağlantıları hakkında Ağ ve Network Altyapısı, güvenlik kontrolleri hakkında Güvenlik Altyapımız ve veri sürekliliği hakkında Yedekleme Politikamız sayfalarını inceleyebilirsiniz. Doğrulanmış bir olay veya planlı bakım duyurusu gerektiğinde müşteri panelindeki destek kanallarından bizimle iletişime geçebilirsiniz.

Durum sayfasını okurken dikkat edilmesi gerekenler

Durum sayfasındaki bir duyuru, olayın bütün müşterilerde aynı şekilde yaşandığını veya bütün ürünlerin aynı anda etkilendiğini ifade etmeyebilir. Bir kayıt belirli bir bölgeyi, hizmet grubunu, ağ yolunu, ürün sağlayıcısını veya belirli bir işlem tipini kapsayabilir. Müşteriler kendi alan adı, hizmet numarası ve hata zamanını duyurudaki kapsamla karşılaştırmalıdır.

Bir olay çözüldü olarak işaretlendiğinde kullanıcı tarafında önbellek, DNS yayılımı veya tarayıcı oturumu nedeniyle eski hata kısa süre daha görülebilir. Bu durumda farklı bir ağdan test yapmak, DNS önbelleğini kontrol etmek ve destek talebine güncel ekran görüntüsü eklemek yararlı olabilir. Durum kaydı ile müşteri özelindeki teknik inceleme birbirinin yerine geçmez.

İleride gerçek bir durum API’si bağlanırsa yalnızca renkli kartlar oluşturmak yeterli olmayacaktır. Kaynağın zaman aşımı, hatalı veri döndürmesi, olayların kapanış bilgisi, bakım kayıtlarının yayınlanması ve bildirimlerin tekrarlanmasını önleyecek bir kayıt yapısı da tasarlanmalıdır. Böylece ziyaretçiye anlaşılır, yöneticilere izlenebilir ve müşteriye karşı dürüst bir durum iletişimi sağlanabilir.

Durum bilgisinin müşteri iletişimiyle ilişkisi

Durum sayfası teknik olayların kısa bir özeti olabilir; müşterinin hesabına özel tüm ayrıntıları içermez. Örneğin tek bir alan adındaki DNS hatası genel bir DNS kesintisi olmayabilir veya bir lisans sağlayıcısının yanıt vermemesi tüm Nettescil panellerinin kullanılamadığı anlamına gelmeyebilir. Bu ayrım, müşterinin doğru kanaldan yardım istemesi ve gereksiz işlem yapmaması için önemlidir.

Planlı bakım tamamlandıktan sonra yalnızca bakım bitti ifadesi yerine, kontrol edilen hizmet grubu ve varsa bekleyen etkiler açıklanmalıdır. Bir olay tamamen incelenmemişse kesin kök neden yazılmamalı; geçici bulgu, doğrulanmış sonuç ve sonraki izleme adımı birbirinden ayrılmalıdır. Böyle bir iletişim hem yanlış beklentiyi hem de aynı olay için tekrarlanan destek taleplerini azaltır.

Durum kaydı ile sözleşmesel hizmet seviyesi aynı kavram değildir. Bu sayfadaki açıklamalar müşteriye genel bilgilendirme sağlar; ürün, paket ve sözleşmede yer alan özel koşullar ayrıca geçerlidir. Müşteriler kritik sistemleri için kendi izleme, yedekleme ve olay iletişimi planlarını da oluşturmalıdır.

Durum duyurularının anlaşılır olması için teknik terimler gerektiğinde kısa bir açıklamayla kullanılmalı, müşteriden beklenen işlem açıkça yazılmalı ve çözüm sonrası kayıt güncellenmelidir. Duyuru geçmişi, tekrarlayan problemleri ve gelecekteki kapasite veya bakım planlarını değerlendirmek için de yararlı bir referans oluşturur.

Bir sorun için destek talebi açarken müşteri numarası, hizmet adı, alan adı, hata zamanı, hata metni ve sorunun hangi ağlarda görüldüğü bilgileri paylaşılabilir. Gizli parola ve anahtarlar kesinlikle eklenmemelidir.

Bu yöntem sayesinde duyurular; doğrulanabilir teknik bilgi, açık müşteri yönlendirmesi ve sonradan incelenebilir olay geçmişi arasında dengeli bir yapı sunar. Gerçek veri oluşmadığında bunu açıkça belirtmek, müşterinin doğru beklenti kurması ve destek ekibinin gerçek duruma odaklanması açısından daha sağlıklıdır.