Status Page En İyi Uygulamalar: Siteniz Çöktüğünde Neler Eklenmeli?

Bir status page, bir şey bozulduğunda kullanıcıların kontrol ettiği ilk yerdir. Kafa karıştırıcı, güncel olmayan veya eksik bilgi içeriyorsa, stresli bir anda net iletişim kurma şansınızı boşa harcamış olursunuz.

İşte gerçekten işe yarayan bir status page nasıl oluşturulur.

Harika Bir Status Page'in Anatomisi

1. Genel Durum Göstergesi

Bir ziyaretçinin görmesi gereken ilk şey, "Her şey yolunda mı?" sorusuna net ve anında bir cevaptır.

Sayfanın üst kısmında üç durumdan birini gösterin:

• Tüm Sistemler Operasyonel — Yeşil. Her şey normal çalışıyor.
• Kısmi Kesinti — Sarı. Bazı hizmetler etkilenmiş.
• Büyük Kesinti — Kırmızı. Temel bir hizmet çökmüş.

Kullanıcıları bir sorun olup olmadığını anlamak için component listelerini taramaya zorlamayın. Durum ilk bakışta anlaşılmalıdır.

2. Component Listesi

Global durumun altında, izlediğiniz her hizmeti kendi durumuyla birlikte listeleyin:

• ✅ Operasyonel
• ⚠️ Yavaş Performans
• ❌ Çöktü
• 🔧 Bakım

Component'leri kullanıcıların bildiği dille adlandırın: "Uygulama" deyin, "web-frontend-prod-v2" değil; "API" deyin, "gateway.core.services.rest" değil.

İlgili component'leri gruplandırın. Mikroservis mimariniz varsa, 30 component'i tek bir listeye dökmek yerine ürün alanları altında listeleyin.

3. Aktif Incident'ler

Bir şey ters gittiğinde, aktif incident bölümü sayfanın en önemli kısmıdır. Şunları ekleyin:

• Başlık — "API Yanıt Sürelerinde Yavaşlama" veya "Büyük Kesinti — Ödeme Kullanılamıyor"
• Açıklama — Ne oluyor, neler etkilenmiş ve ne yapıyorsunuz
• Zaman çizelgesi — Incident ilerledikçe zaman damgalı güncellemeler
• Etkilenen component'ler — Etkilenen hizmetleri işaretleyin

Zaman çizelgesini sık güncelleyin. 3 saatte bir güncellenen bir status page, hiç status page olmamasından daha kötüdür — kimsenin ilgilenmediği sinyalini verir.

4. Incident Geçmişi

Bir incident çözüldükten sonra geçmiş günlüğüne taşınır. Bunun birden fazla amacı vardır:

• Geçmiş sorunlar hakkında şeffaf olduğunuzu gösterir
• Müşterilerin güvenilirlik geçmişinizi anlamasına yardımcı olur
• Kendi post-mortem analiziniz için veri sağlar
• SLA raporlamasını destekler

En az 90 günlük incident geçmişini görünür tutun. Bazı servisler her şeyi süresiz saklar.

5. Abone Bildirimleri

Kullanıcıların sayfayı sürekli yenilemek zorunda kalmaması için durum değişikliklerine abone olmasına izin verin. En azından şunları destekleyin:

• Email bildirimleri — Incident oluşturulduğunda, güncellendiğinde veya çözüldüğünde
• İsteğe bağlı olarak SMS veya webhook entegrasyonları

Kritik anlarda bildirim gönderin:

• Incident oluşturuldu
• Incident yeni bilgiyle güncellendi
• Bakım planlandı
• Bakım tamamlandı
• Incident çözüldü

Tasarım En İyi Uygulamaları

Markanızı Kullanın

Status page'iniz şirketinize ait gibi görünmelidir. Şunları eşleştirin:

• Logo ve tipografi
• Genel tema için marka renkleri
• Kendi domain'iniz (status.sirketiniz.com)

Genel görünümlü veya varsayılan markalama kullanan bir status page güvensizlik yaratır. Resmi görünmüyorsa, kullanıcılar güncellemelere inanmaz.

Sade Tutun

Bir status page, pazarlama sitesi değildir. Şunları eklemeyin:

• Hero animasyonları
• Pop-up veya modal'lar
• Birden fazla harekete geçirici mesaj
• Sayfayı yavaşlatan ağır JavaScript

Status page'iniz yavaş bağlantılarda bile hızlı yüklenmelidir. Mümkün olduğunca statik HTML ve CSS kullanın.

Mobil Öncelikli

Bir status page'i kontrol eden çoğu kullanıcı telefondadır — özellikle kesinti sırasında. Şunlardan emin olun:

• Metin yakınlaştırmadan okunabilir
• Tablolar ve component listeleri düzgün sarılır
• Abone formu mobilde kolay doldurulur

İletişim En İyi Uygulamaları

Okuyucu İçin Yazın

Incident güncellemeleri üç soruyu yanıtlamalıdır:

1. Ne oldu? — "Database bağlantı sorunu yaşadık."
2. Ne yapıyoruz? — "Replica'ya geçiş yaptık ve temel nedeni araştırıyoruz."
3. Ne zaman düzelecek? — "30 dakika içinde çözüm öngörüyoruz."

Mühendislik jargonundan kaçının. "Birincil replikada bellek baskısı" kullanıcılar için bir şey ifade etmez. "Database yavaş çalışıyor" anlamlıdır.

Sık Güncelleyin

Aktif bir incident sırasında, bildirilecek yeni bir şey olmasa bile status page'i her 30 dakikada bir güncelleyin. "Hala araştırıyoruz" sessizlikten iyidir.

İyi bir güncelleme takvimi örneği:

• T+0: Incident oluşturuldu — "...raporlarını araştırıyoruz"
• T+15: "Sorunu belirledik..."
• T+30: "Çözüm dağıtıyoruz..."
• T+45: "Çözüm yayılıyor..."
• T+60: "Hizmet geri geldi. İzlemeye devam ediyoruz..."

Bakımı Proaktif Planlayın

Planlı bir bakım penceresi başlayana kadar status page'inizi güncellemeyi beklemeyin. Bakım kaydını 24-48 saat önceden oluşturun ki aboneler bildirim alsın ve kullanıcılar ne bekleyeceğini bilsin.

Sık Yapılan Hatalar

Hiç status page'inin olmaması. Online hizmeti olan her işletmenin buna ihtiyacı vardır. İhtiyacınız olmadan önce kurun.

Status page oluşturup kesintiler sırasında güncellememek. Güncel olmayan bir status page, hiç olmamasından daha kötüdür — iletişim kuracak kadar umursamadığınızı gösterir.

Aşırı teknik dil kullanmak. Kitleniz teknik olmayan paydaşları, müşterileri ve yöneticileri içerir. Genel okuyucu için yazın.

Sayfayı yavaş veya zor gezinilir yapmak. Bir status page anında yüklenmeli ve ilk bakışta okunabilir olmalıdır.

Aboneliklere izin vermemek. Kullanıcılar manuel yenilemek zorunda kalırsa hayal kırıklığına uğrar ve destek ekibiniz bunu duyar.

Altın Kural

İyi bir status page destek taleplerini azaltır. Kötü bir status page onları artırır. Her tasarım ve içerik kararı bu ölçüte göre değerlendirilmelidir.

Bugün profesyonel bir status page kurun. isthisthing.online'da ücretsiz başlayın — monitor'ler, status page ve abone bildirimleri dahil.