Jak zbudować stronę statusu: komponenty, incydenty i kontrole dostępności

Strona statusu informuje użytkowników w jednym miejscu, czy usługa działa. Żeby ją zbudować, potrzebujesz listy komponentów (strona www, API, płatności, wysyłka e-maili), bieżącego statusu każdego z nich, incydentów z opatrzonymi datą aktualizacjami, historii minionych incydentów i opcjonalnie subskrypcji, dzięki którym ludzie dowiedzą się o problemach bez sprawdzania strony. Sama strona jest prosta. Ważna decyzja dotyczy tego, gdzie działa: strona statusu musi być dostępna wtedy, gdy twoja aplikacja nie działa, więc nie powinna współdzielić hostingu, bazy danych ani potoku wdrożeń z tym, o czym informuje.

Do czego służy strona statusu

Gdy coś się psuje, użytkownicy chcą wiedzieć trzy rzeczy: czy problem dotyczy tylko ich, czy wiesz o nim i kiedy zostanie naprawiony. Strona statusu odpowiada na wszystkie trzy bez zalewu zgłoszeń do pomocy technicznej. Z czasem buduje też zaufanie, bo widoczna historia incydentów z rzetelnymi opisami pokazuje, jak radzisz sobie z problemami.

To nie jest dziennik zmian. Nowe funkcje trafiają na stronę ze zmianami, a awarie i prace serwisowe tutaj.

Czego potrzebuje strona

Dane

Statusy komponentów to zwykle krótka, stała lista: Działa, Obniżona wydajność, Częściowa awaria, Poważna awaria, Prace serwisowe.

Strony

• Publiczna strona statusu: baner ogólny („Wszystkie systemy działają” albo najgorszy bieżący status), każdy komponent z jego statusem, aktywny incydent z aktualizacjami, nadchodzące prace serwisowe oraz pasek historii z 90 dni, jeśli masz dane z kontroli.
• Strona incydentu: pełna oś czasu aktualizacji jednego incydentu, z własnym adresem, żeby pomoc techniczna mogła do niego linkować.
• Historia: minione incydenty pogrupowane według miesięcy.
• Subskrypcja: zapis przez e-mail z potwierdzeniem i preferencjami dla poszczególnych komponentów.
• Panel administracyjny: tworzenie incydentu, publikowanie aktualizacji, zmiana statusów komponentów, planowanie prac serwisowych.

Uprawnienia

Publiczność widzi wszystko, co zostało opublikowane. Publikować może tylko twój zespół. Jeśli to możliwe, trzymaj logowanie do panelu osobno od systemu logowania w głównej aplikacji, tak aby awaria dostawcy uwierzytelniania nie zablokowała ci dostępu do własnej strony statusu.

Kluczowa decyzja: uniezależnij stronę

To właśnie tutaj najczęściej zawodzą samodzielnie budowane strony statusu. Jeśli twoja strona statusu:

• działa na tym samym serwerze lub koncie hostingowym co aplikacja,
• czyta z tej samej bazy danych,
• znajduje się za tą samą konfiguracją domeny lub CDN,
• albo jest wdrażana tym samym potokiem,

to wiele awarii położy ją razem z aplikacją, dokładnie wtedy, gdy ludzie jej potrzebują. Praktyczne kroki:

• Osobny hosting. Inny projekt albo dostawca niż główna aplikacja.
• Własna subdomena, na przykład status.example.com, wskazująca osobno w DNS. Zobacz jak działają domeny i DNS.
• Własne dane. Incydenty są przechowywane w pamięci strony statusu, a nie w bazie aplikacji.
• Statyczny zapas. Niektóre zespoły tworzą publiczną stronę jako statyczną i przebudowują ją przy każdej aktualizacji, dzięki czemu prawie nie ma czego zepsuć.

Ręcznie czy automatyczne kontrole

Ręcznie (od tego zacznij)

Zespół publikuje incydenty i zmienia statusy komponentów ręcznie, z panelu administracyjnego. Tak działa wiele stron statusu w praktyce, ponieważ ludzka ocena („płatności są wolne dla niektórych kart”) jest bardziej użyteczna niż automatyczna czerwona kropka.

Aby szybko dowiedzieć się o problemach, użyj zewnętrznego monitora dostępności, który sprawdza aplikację co minutę lub mniej i alarmuje e-mailem, SMS-em albo na czacie. Wiele usług monitoringu ma darmowe plany.

Automatycznie

Automatyzacja oznacza, że coś regularnie sprawdza każdy komponent i aktualizuje jego status. Potrzebny jest do tego kod uruchamiany według harmonogramu, działający poza infrastrukturą głównej aplikacji. Są dwa częste wzorce:

• Zewnętrzny monitor wywołuje twoją stronę statusu przez webhook, gdy kontrola się nie powiedzie lub powróci do normy, a strona statusu aktualizuje komponent.
• Zaplanowane zadanie w hostingu strony statusu odpytuje każdy komponent i zapisuje wynik. Przed poleganiem na tym sprawdź, jak twój hosting obsługuje zadania cykliczne. Nasz przewodnik o uruchamianiu zadań w tle wyjaśnia dostępne opcje.

Automatyczne zmiany potrafią migotać (działa, nie działa, działa) przy wolnym łączu. Wymagaj dwóch lub trzech nieudanych kontroli przed zmianą statusu i pozwól człowiekowi potwierdzić poważną awarię, zanim zostanie ogłoszona.

Jak pisać aktualizacje incydentów

• Publikuj wcześnie. „Badamy zgłoszenia o nieudanych logowaniach” po kilku minutach jest lepsze niż idealny komunikat godzinę później.
• Napisz, co zauważą użytkownicy, a nie co zepsuło się wewnętrznie.
• Obiecaj czas kolejnej aktualizacji i dotrzymaj go.
• Zakończ krótkim podsumowaniem po rozwiązaniu: co się stało, jak długo trwało i co zmieniasz.

Pierwszy prompt, który działa

Zbuduj samodzielną stronę statusu dla naszej aplikacji Parcelio, hostowaną osobno pod adresem status.parcelio.com. Komponenty: Strona, API śledzenia, Powiadomienia, Płatności, każdy ze statusem Działa, Obniżona wydajność, Częściowa awaria, Poważna awaria albo Prace serwisowe. Publiczna strona pokazuje baner ogólny według najgorszego bieżącego statusu, każdy komponent ze statusem, aktywne incydenty z datowanymi aktualizacjami od najnowszych, nadchodzące prace serwisowe oraz listę minionych incydentów pogrupowanych według miesięcy. Każdy incydent ma własną stronę. Dodaj chroniony hasłem panel administracyjny do tworzenia incydentów (tytuł, wpływ, dotknięte komponenty), publikowania aktualizacji (treść i status: Badanie, Zidentyfikowano, Monitorowanie, Rozwiązano), zmiany statusów komponentów i planowania prac serwisowych. Dodaj endpoint POST /api/check-result, który przyjmuje nazwę komponentu i informację up/down od zewnętrznego monitora, chroniony tajnym tokenem, i oznacza komponent jako Obniżona wydajność dopiero po trzech kolejnych awariach. Zapisuj wszystko w bazie danych tej aplikacji. Prosty, spokojny design, który szybko się ładuje na telefonach.

Kroki budowy

1. Publiczna strona i panel z ręcznymi incydentami. Sama w sobie to działająca strona statusu.
2. Hostuj ją osobno i wskaż subdomenę.
3. Strony incydentów i historia.
4. Okna prac serwisowych.
5. Subskrypcje. Zapis e-mailem z podwójnym potwierdzeniem i powiadomienia o nowych incydentach i aktualizacjach. E-maile wymagają dostawcy; zobacz jak wysyłać e-maile z aplikacji.
6. Webhook monitora, jeśli chcesz automatycznych zmian statusów.
7. Przeprowadź próbę. Utwórz testowy incydent, opublikuj aktualizacje, rozwiąż go, sprawdź e-maile, a potem usuń.

Częste błędy

• Hostowanie razem z aplikacją. Najczęstszy i najpoważniejszy błąd.
• Strona, która zawsze mówi „Wszystkie systemy działają”. Jeśli nigdy nie pokazuje problemów, użytkownicy przestają jej ufać.
• Brak znaczników czasu i strefy czasowej. Zawsze pokazuj godziny wraz ze strefą.
• Polegania na logowaniu do głównej aplikacji w panelu administracyjnym.
• Cisza między aktualizacjami. „Bez zmian, nadal pracujemy nad tym” to poprawna aktualizacja.
• Migoczące automatyczne statusy. Wymagaj powtarzających się awarii przed zmianą.

Kiedy lepszy jest gotowy serwis stron statusu

Gotowe usługi stron statusu powstały właśnie po to, by rozwiązać problem niezależności: działają na osobnej infrastrukturze, obsługują powiadomienia dla subskrybentów przez e-mail i SMS, a często zawierają monitoring i integracje z narzędziami do obsługi incydentów. Jeśli dostępność jest czymś, za co klienci płacą, albo masz umowne obowiązki zgłaszania incydentów, dedykowana usługa zwykle się opłaca. Wiele z nich ma darmowe lub tanie plany dla małych zespołów, więc sprawdź je, zanim zaczniesz budować.

Buduj własną stronę, gdy chcesz pełnej kontroli nad designem i treścią, gdy twoje potrzeby są proste (kilka komponentów, ręczne aktualizacje) albo gdy strona statusu jest częścią produktu, który tworzysz dla innych.

Budowa z Mythex

W Mythex możesz zbudować stronę statusu jako osobny projekt, oddzielony od głównej aplikacji, co daje osobny hosting i własną bazę danych. Opisz ją w czacie, sprawdź w podglądzie na żywo, a potem opublikuj i podłącz subdomenę, na przykład status.twojadomena.pl (własne domeny są w planie Pro). Pamiętaj, że opublikowane aplikacje Mythex i ich bazy danych usypiają po bezczynności i budzą się przy kolejnej wizycie, więc pierwsze wejście po dłuższej przerwie może być wolniejsze. Lekka, prosta strona temu pomaga.

Mythex nie udokumentował zadań cyklicznych, więc do automatycznych kontroli użyj zewnętrznego monitora dostępności, który wywołuje endpoint webhook na twojej stronie statusu (zobacz przepis na webhooki). E-maile dla subskrybentów wysyłasz przez własnego dostawcę, z kluczem zapisanym jako sekret projektu (przepis na wysyłkę e-maili).

Pytania