Czym jest strona statusu i co powinno się na niej znaleźć

Co powinno się znaleźć na stronie statusu

Strona statusu ma trzy warstwy, a większość wartości leży w pierwszych dwóch.

Górna warstwa to bieżący stan każdego wymienionego komponentu. Komponenty to elementy, które klient potrafi od siebie odróżnić: witryna, API, panel, logowanie, proces płatności, backend aplikacji mobilnej. Stan zwykle przedstawia krótka drabinka, a nie wartość zero-jedynkowa, dzięki czemu możesz napisać "obniżona wydajność" dla usługi, która działa wolno, ale odpowiada, zamiast wybierać między zielonym haczykiem, który jest nieprawdziwy, a czerwonym krzyżykiem, który jest gorszy.

Środkowa warstwa to kanał incydentów. Każdy incydent to krótki wpis z czasem rozpoczęcia, prostym opisem tego, co zauważą klienci, i aktualizacjami dopisywanymi w miarę zmiany sytuacji, kończącymi się notatką o rozwiązaniu. Przeszłe incydenty pozostają widoczne, co zamienia stronę w zapis, a nie w przełącznik.

Dolna warstwa to historia: dostępność z ostatnich 30 lub 90 dni dla każdego komponentu. To najmniej pilna część, ale ta, którą najczęściej czytają osoby, które Cię oceniają.

Publiczna czy prywatna

Publiczna strona statusu jest otwarta dla każdego, kto ma link, i to właściwy wybór, gdy Twoimi klientami jest ogół odbiorców albo gdy publikujesz SLA. Przejmuje też ruch podczas awarii od osób, które w ogóle nie są klientami.

Prywatna strona statusu jest ograniczona do zalogowanych klientów albo odbiorców wewnętrznych. Zespoły korzystają z niej, gdy lista komponentów ujawniałaby wewnętrzną architekturę, gdy incydenty dotyczą konkretnych, nazwanych klientów korporacyjnych, albo gdy strona obejmuje wewnętrzne systemy, których żaden outsider nie powinien wyliczać. Kompromis polega na tym, że każdy, kto nie ma do niej dostępu, skontaktuje się zamiast tego ze wsparciem.

Niezależnie od wyboru, hostuj stronę z dala od infrastruktury, o której informuje. Strona statusu, która pada razem z usługą, jest gorsza niż brak strony statusu w ogóle, bo jej milczenie podczas awarii jest odczytywane jako twierdzenie, że nic się nie dzieje.

Pisanie incydentu

Wpis o incydencie pisze się dla klienta, nie dla inżynierów, którzy go naprawiają. Oznacza to, że najpierw jest objaw, a przyczyna później, jeśli w ogóle.

1. Otwórz incydent, gdy tylko potwierdzisz problem, nawet jeśli jeszcze nie znasz przyczyny. "Badamy zgłoszenia błędów przy finalizacji zamówienia" opublikowane w drugiej minucie jest warte więcej niż pełne wyjaśnienie w dziewięćdziesiątej.
2. Napisz, co zobaczy klient i co może z tym zrobić, w tym obejście, jeśli istnieje.
3. Aktualizuj w rytmie, który zapowiedziałeś z góry, i publikuj aktualizację nawet, gdy brzmi "wciąż bez zmian". Milczenie jest odczytywane jako porzucenie sprawy.
4. Zamknij wpis czasem rozwiązania i, przy czymkolwiek długim lub poważnym, krótką notatką o tym, co się stało później.

Dopasuj stan komponentu do incydentu. Otwarty incydent przy komponencie wciąż pokazującym zielony to najszybszy sposób na utratę zaufania do strony. Jeśli leżąca u podstaw awaria to serwer odmawiający przyjmowania żądań, 503 Service Unavailable to odpowiedź, którą Twoi klienci najprawdopodobniej Ci zacytują.

Planowane prace serwisowe

Zaplanowane prace mają miejsce na tej samej stronie, zapowiedziane z wyprzedzeniem, z podanym oknem czasowym i spodziewanym wpływem. Zapowiedzenie ich wcześniej zamienia awarię w umówiony termin: klienci, którzy widzieli zapowiedź, nie zgłaszają ticketów, a ci, którzy jej nie widzieli, mogą przynajmniej znaleźć wyjaśnienie w trakcie zdarzenia.

Odróżniaj prace serwisowe od incydentu wizualnie i w zapisie, i trzymaj się zapowiedzianego okna uczciwie. Okno serwisowe, które regularnie się przeciąga, uczy ludzi ignorować kolejne.

Dlaczego to zmniejsza obciążenie wsparcia

Podczas awarii kolejka wsparcia wypełnia się jednym pytaniem zadawanym wielokrotnie. Strona statusu odpowiada na nie raz, pod adresem, który możesz wskazać w autoresponderze wsparcia, stanie błędu aplikacji i kontach społecznościowych. To zamienia godzinę powtarzalnej segregacji zgłoszeń w jeden link.

Drugorzędny efekt dotyczy zaufania. Publikowanie incydentów kosztuje mniej, niż się wydaje, bo klienci, którzy zauważyli awarię, już wiedzą, że się wydarzyła. To, co oceniają, to czy im o niej powiedziałeś.

Skąd bierze się status

Strona statusu jest tak dobra, jak monitoring stojący za nią. Jeśli człowiek musi zauważyć awarię, zanim zmieni się strona, strona zawsze będzie opóźniona względem czytających ją klientów, więc stany komponentów powinny być napędzane sprawdzeniami działającymi nieprzerwanie spoza Twojej sieci. HostTracker hostuje strony statusu zasilane własnym monitoringiem, który sprawdza z ponad 300 punktów kontrolnych w 158 miastach, w 13 typach monitorów, dzięki czemu stan komponentu wynika z wyników sprawdzeń, a nie z tego, że ktoś pamiętał, żeby go zaktualizować. To, jak wyglądają te sprawdzenia, opisuje poradnik o sprawdzeniu HTTP, a resztę powiązanych terminów znajdziesz w sekcji pojęć monitoringu.