Durum sayfası nedir ve sayfada ne bulunmalıdır

Bir durum sayfasında ne bulunur

Bir durum sayfasının üç katmanı vardır, ve değerin çoğu ilk ikisindedir.

Üst katman, listelediğiniz her bileşenin mevcut durumudur. Bileşenler, bir müşterinin ayırt edebileceği parçalardır: web sitesi, API, kontrol paneli, oturum açmalar, ödeme akışı, bir mobil uygulama arka ucu. Durum genellikle ikili değil kısa bir merdivendir, böylece yanlış olan yeşil bir tik ile daha kötü olan kırmızı bir çarpı arasında seçim yapmak yerine, yavaş ama yanıt veren bir hizmet için "düşük performanslı" diyebilirsiniz.

Orta katman, olay akışıdır. Her olay, bir başlangıç saati, müşterilerin fark edeceği şeyin sade bir açıklaması, ve durum değiştikçe eklenen güncellemelerle sonunda bir çözüm notuyla biten kısa bir girdidir. Geçmiş olaylar görünür kalır, ki sayfayı bir ışık anahtarı yerine bir kayda dönüştüren şey budur.

Alt katman geçmiştir: bileşen başına son 30 veya 90 gündeki çalışma süresi. En az acil olan ve sizi değerlendiren kişiler tarafından en sık okunan kısımdır.

Genel mi özel mi

Genel bir durum sayfası, bağlantıya sahip herkese açıktır, ve müşterileriniz genel halksa veya bir SLA yayınlıyorsanız doğru seçimdir. Ayrıca bir kesinti sırasında hiç müşteri olmayan kişilerden gelen trafiği de emer.

Özel bir durum sayfası, oturum açmış müşterilerle veya dahili bir kitleyle sınırlıdır. Takımlar, bileşen listesi dahili mimariyi açığa çıkaracaksa, olaylar isimli kurumsal müşterileri içeriyorsa, veya sayfa hiçbir dış kişinin numaralandırmaması gereken dahili sistemleri kapsıyorsa bunu kullanır. Değiş tokuşu, ona erişemeyen herkesin bunun yerine destekle iletişime geçmesidir.

Hangisini seçerseniz seçin, sayfayı hakkında rapor verdiği altyapıdan uzakta barındırın. Hizmetle birlikte çöken bir durum sayfası, hiç durum sayfası olmamasından daha kötüdür, çünkü bir kesinti sırasındaki sessizliği hiçbir sorun olmadığına dair bir iddia olarak okunur.

Bir olayı yazmak

Bir olay girdisi, onu düzelten mühendisler için değil bir müşteri için yazılır. Bu, önce belirti, varsa ancak daha sonra neden anlamına gelir.

1. Sorunu henüz doğrulamamış olsanız bile, doğruladığınız anda olayı açın. İkinci dakikada yayınlanan "Ödeme sayfasındaki hata raporlarını araştırıyoruz" mesajı, doksanıncı dakikadaki tam bir açıklamadan daha değerlidir.
2. Bir müşterinin ne göreceğini ve bu konuda ne yapabileceğini söyleyin, varsa bir geçici çözüm dahil.
3. Önceden belirttiğiniz bir ritimle güncelleyin, ve "henüz değişiklik yok" olsa bile güncellemeyi yayınlayın. Sessizlik terk edilmiş gibi okunur.
4. Bir çözüm zamanıyla kapatın, ve uzun veya ciddi herhangi bir şey için sonrasında ne olduğuna dair kısa bir not ekleyin.

Bileşen durumunu olayla eşleştirin. Hâlâ yeşil gösteren bir bileşende açık bir olay, sayfaya duyulan güveni kaybetmenin en hızlı yoludur. Altta yatan hata bir sunucunun istekleri reddetmesiyse, 503 Service Unavailable müşterilerinizin size en çok söyleyeceği yanıttır.

Planlı bakım

Planlı çalışma, önceden bir pencere ve beklenen bir etkiyle duyurularak aynı sayfaya ait olmalıdır. Önceden yayınlamak bir kesintiyi bir randevuya dönüştürür: bildirimi gören müşteriler destek talebi açmaz, görmeyenler ise en azından olay yaşanırken açıklamayı bulabilir.

Bakımı bir olaydan görsel olarak ve kayıtta ayırt edin, ve duyurulan pencereyi dürüst tutun. Düzenli olarak aşan bir bakım penceresi, insanlara bir sonrakini görmezden gelmeyi öğretir.

Destek yükünü neden azaltır

Bir kesinti sırasında destek kuyruğu, birçok kez sorulan tek bir soruyla dolar. Bir durum sayfası bunu bir kez yanıtlar; destek otomatik yanıtlayıcınızdan, uygulamanızın hata durumundan ve sosyal hesaplarınızdan işaret edebileceğiniz bir adreste. Bu, bir saatlik tekrarlayan triyajı bir bağlantıya dönüştürür.

İkincil etki güven üzerinedir. Olayları yayınlamak göründüğünden daha az maliyetlidir, çünkü kesintiyi fark eden müşteriler zaten onun gerçekleştiğini bilir. Değerlendirdikleri şey, onlara söyleyip söylemediğinizdir.

Durum nereden gelir

Bir durum sayfası, arkasındaki izleme kadar iyidir. Sayfa değişmeden önce bir insanın kesintiyi fark etmesi gerekiyorsa, sayfa onu okuyan müşterilerin her zaman gerisinde kalır, bu yüzden bileşen durumları ağınızın dışından sürekli çalışan kontroller tarafından yönlendirilmelidir. HostTracker, kendi izlemesiyle beslenen durum sayfalarını barındırır; bu izleme, 158 şehirdeki 300'den fazla kontrol noktasından 13 monitör türüyle kontrol eder, bu yüzden bir bileşenin durumu birinin güncellemeyi hatırlamasını değil kontrol sonuçlarını izler. Bu kontrollerin neye benzediği için HTTP kontrolü rehberine, ve çevresindeki terimler için izleme kavramları bölümünün geri kalanına bakın.