Durum Sayfası Nasıl Kurulur: Bileşenler, Olaylar ve Çalışma Süresi Kontrolleri

Bir durum sayfası, kullanıcılarınıza hizmetinizin çalışıp çalışmadığını tek bir yerden söyler. Bunu kurmak için bileşenlerin bir listesine (web sitesi, API, ödemeler, e-posta gönderimi), her birinin güncel durumuna, zaman damgalı olaylara, geçmiş olayların bir kaydına ve isterseniz insanların sorunları kontrol etmeden öğrenmesi için aboneliklere ihtiyacınız var. Sayfanın kendisi basittir. Asıl önemli karar nerede çalışacağıdır: durum sayfası, bildirdiği şey çöktüğünde de ayakta kalmalıdır; bu yüzden aynı barındırmayı, veritabanını ya da dağıtım hattını onunla paylaşmamalıdır.

Durum sayfası ne işe yarar

Bir şey bozulduğunda kullanıcılar üç şeyi öğrenmek ister: sorun yalnızca bende mi, siz farkında mısınız ve ne zaman düzelecek. Durum sayfası, destek talepleri yağmadan bu üç soruyu da yanıtlar. Ayrıca zaman içinde güven oluşturur, çünkü açık bir olay geçmişi ve dürüst açıklamalar sorunlarla nasıl başa çıktığınızı gösterir.

Bu bir değişiklik günlüğü değildir. Yeni özellikler değişiklik günlüğü sayfasına gider; kesintiler ve bakım çalışmaları buraya.

Sayfanın ihtiyaç duyduğu şeyler

Veri

Bileşen durumları genellikle kısa ve sabit bir listedir: Çalışıyor, Performans düşük, Kısmi kesinti, Büyük kesinti, Bakımda.

Sayfalar

• Herkese açık durum sayfası: genel bir üst bilgi (“Tüm sistemler çalışıyor” ya da mevcut en kötü durum), her bileşen ve durumu, aktif olay varsa güncellemeleri, yaklaşan bakım çalışmaları ve kontrol verisi varsa 90 günlük bir geçmiş şeridi.
• Olay sayfası: tek bir olayın tam güncelleme zaman çizelgesi; destek ekibinizin bağlantı verebilmesi için kendi URL’si olmalı.
• Geçmiş: geçmiş olaylar aylara göre.
• Abone ol: onaylı e-posta kaydı ve bileşen bazında tercihler.
• Yönetim: olay oluşturma, güncelleme yayınlama, bileşen durumlarını değiştirme, bakım planlama.

Yetkiler

Herkese açık olan, yayınlanan her şeydir. Yalnızca ekibiniz yayınlayabilir. Mümkünse yönetici girişini ana uygulamanızın oturum açma sisteminden ayrı tutun; böylece kimlik doğrulama sağlayıcınızdaki bir kesinti sizi kendi durum sayfanızdan kilitlemez.

Temel karar: bağımsız tutun

Ev yapımı durum sayfalarının çoğu tam burada başarısız olur. Durum sayfanız:

• uygulamanızla aynı sunucuda ya da barındırma hesabında çalışıyorsa,
• aynı veritabanını okuyorsa,
• aynı alan adı yapılandırmasının ya da CDN’in arkasındaysa,
• ya da aynı hatla dağıtılıyorsa,

o zaman birçok kesinti onu da götürür; tam da insanların ihtiyaç duyduğu anda. Pratik adımlar:

• Ayrı barındırma. Ana uygulamadan farklı bir proje ya da sağlayıcı kullanın.
• Kendi alt alan adı, örneğin status.example.com, DNS’te ayrıca yönlendirilmiş. Alan adlarının ve DNS’in nasıl çalıştığına bakın.
• Kendi verisi. Olaylar durum sayfasının kendi depolamasında yaşasın, uygulama veritabanınızda değil.
• Statik yedek. Bazı ekipler herkese açık sayfayı statik yapar ve her güncellemede yeniden üretir; böylece bozulacak neredeyse hiçbir şey kalmaz.

Elle güncelleme mi, otomatik kontrol mü

Elle (buradan başlayın)

Ekibiniz olayları ve bileşen durumlarını yönetim sayfasından elle girer. Birçok durum sayfası pratikte böyle çalışır; çünkü “kartların bir kısmında ödemeler yavaş” gibi insan değerlendirmesi, otomatik bir kırmızı noktadan daha faydalıdır.

Sorunları hızlı öğrenmek için uygulamanızı her dakika kontrol eden ve e-posta, SMS ya da sohbet üzerinden sizi uyaran harici bir çalışma süresi izleyicisi kullanın. Birçok izleme hizmetinin ücretsiz katmanı vardır.

Otomatik

Otomatikleştirme, her bileşeni düzenli olarak kontrol eden ve durumunu güncelleyen bir şey demektir. Bunun için ana uygulamanızın altyapısının dışında, bir zamanlamayla çalışan kod gerekir. İki yaygın model var:

• Harici bir izleyici, bir kontrol başarısız olduğunda ya da düzeldiğinde durum sayfanızı bir webhook ile çağırır ve durum sayfası bileşeni günceller.
• Durum sayfasının kendi barındırmasındaki zamanlanmış bir iş her bileşeni yoklar ve sonucu kaydeder. Buna güvenmeden önce barındırmanızın zamanlanmış görevleri nasıl ele aldığını kontrol edin; seçenekler için arka plan işlerini çalıştırma rehberimize bakın.

Otomatik değişiklikler yavaş bir ağda gidip gelebilir (yukarı, aşağı, yukarı). Durumu değiştirmeden önce iki üç başarısız kontrol isteyin ve büyük bir kesinti duyurulmadan önce bir insanın onaylamasını sağlayın.

Olay güncellemeleri nasıl yazılır

• Erken yayınlayın. Dakikalar içinde “giriş hatalarıyla ilgili bildirimleri inceliyoruz” demek, bir saat sonra mükemmel bir mesajdan daha iyidir.
• Kullanıcıların ne fark ettiğini söyleyin, içeride neyin bozulduğunu değil.
• Bir sonraki güncelleme saatini vaat edin ve buna uyun.
• Çözüldüğünde kısa bir özetle kapatın: ne oldu, ne kadar sürdü, neyi değiştireceksiniz.

İşe yarayan bir ilk istem

Uygulamamız Parcelio için bağımsız bir durum sayfası oluştur; status.parcelio.com adresinde ayrı barındırılacak. Bileşenler: Web sitesi, Takip API’si, Bildirimler, Ödemeler; her biri şu durumlardan birinde: Çalışıyor, Performans düşük, Kısmi kesinti, Büyük kesinti ya da Bakımda. Herkese açık sayfa, mevcut en kötü duruma göre genel bir üst bilgi, her bileşen ve durumu, aktif olaylar ve zaman damgalı güncellemeleri (en yeniden eskiye), yaklaşan bakımları ve ay ay geçmiş olayların listesini göstersin. Her olayın kendi sayfası olsun. Parola korumalı bir yönetim sayfası ekle; olay oluşturma (başlık, etki, etkilenen bileşenler), güncelleme yayınlama (mesaj ve durum: İnceleniyor, Belirlendi, İzleniyor, Çözüldü), bileşen durumlarını değiştirme ve bakım planlama işlemleri yapılabilsin. Bir harici izleyiciden bileşen adı ve çalışıyor/çalışmıyor bilgisini alan, gizli bir belirteçle korunan bir POST /api/check-result uç noktası ekle; bir bileşen yalnızca üç ardışık başarısız kontrolden sonra Performans düşük olarak işaretlensin. Her şeyi bu uygulamanın kendi veritabanında sakla. Sade, sakin bir tasarım; telefonlarda hızlı açılsın.

Yapım adımları

1. Herkese açık sayfa ve elle olay girişi olan yönetim. Yalnızca bu bile çalışan bir durum sayfasıdır.
2. Ayrı barındırın ve bir alt alan adını buraya yönlendirin.
3. Olay sayfaları ve geçmiş.
4. Bakım pencereleri.
5. Abonelikler. Çift onaylı e-posta kaydı ve yeni olay ve güncellemelerde bildirimler. E-posta için bir sağlayıcı gerekir; bkz. uygulamanızdan e-posta gönderme.
6. Otomatik durum değişiklikleri isterseniz izleyici webhook’u.
7. Bir tatbikat yapın. Sahte bir olay oluşturun, güncelleme yayınlayın, çözün, e-postaları kontrol edin ve sonra silin.

Sık yapılan hatalar

• Uygulamayla aynı yerde barındırmak. En yaygın ve en ciddi hata.
• Her zaman “Tüm sistemler çalışıyor” diyen bir sayfa. Hiçbir zaman sorun göstermiyorsa, kullanıcılar ona güvenmeyi bırakır.
• Zaman damgası ya da saat dilimi olmaması. Saatleri her zaman bölgesiyle gösterin.
• Yönetim sayfası için ana uygulamanızın girişine güvenmek.
• Güncellemeler arasında sessizlik. “Değişiklik yok, hâlâ üzerinde çalışıyoruz” geçerli bir güncellemedir.
• Dalgalanan otomatik durumlar. Bir değişiklikten önce tekrarlanan hatalar isteyin.

Barındırılan bir durum sayfası hizmeti ne zaman daha iyi

Barındırılan durum sayfası hizmetleri, bağımsızlık sorununa göre tasarlanmıştır: ayrı altyapıda çalışırlar, abonelere e-posta ve SMS ile bildirim gönderirler ve çoğu zaman izleme ve olay araçlarıyla entegrasyon sunarlar. Çalışma süresi müşterilerinize satılan bir şeyse ya da kesintileri bildirme sözleşmesel bir yükümlülüğünüz varsa, özel bir hizmet genellikle değerlidir. Birçoğunun küçük ekipler için ücretsiz ya da düşük maliyetli katmanları vardır; kendiniz kurmadan önce kontrol edin.

Kendi sayfanızı, tasarımın ve metnin tam kontrolünü istediğinizde, ihtiyaçlarınız basit olduğunda (birkaç bileşen, elle güncelleme) ya da durum sayfası başkaları için geliştirdiğiniz bir ürünün parçasıysa yapın.

Mythex ile yapmak

Mythex’te durum sayfasını ana uygulamanızdan ayrı, kendi projesi olarak kurabilirsiniz; bu da ayrı barındırma ve kendi veritabanı demektir. Sohbette tarif edin, canlı önizlemede kontrol edin, sonra yayınlayın ve status.alanadiniz.com gibi bir alt alan adını bağlayın (özel alan adları Pro’dadır). Unutmayın ki yayınlanmış Mythex uygulamaları ve veritabanları boşta kaldığında uykuya geçer ve bir sonraki ziyarette uyanır; bu yüzden sessiz bir dönemden sonraki ilk açılış biraz yavaş olabilir. Basit, hafif bir sayfa bunu azaltır.

Mythex zamanlanmış işleri belgelemediği için otomatik kontroller için, durum sayfanızdaki bir webhook uç noktasını çağıran harici bir çalışma süresi izleyicisi kullanın (bkz. webhook tarifi). Abonelere e-posta uyarıları kendi sağlayıcınız üzerinden gider ve anahtar proje sırrı olarak saklanır (e-posta gönderme tarifi).

Sorular