Jak zbudować stronę statusu, której klienci naprawdę ufają

Większość stron statusu istnieje. Niewiele z nich budzi zaufanie. Strona, która zawsze świeci na zielono podczas awarii, jest gorsza niż jej brak, ponieważ uczy klientów, że nie warto na nią patrzeć. Godna zaufania strona statusu ma cztery cechy: jest szczera co do tego, co jest zepsute, szybko przyznaje się do incydentów, starannie określa zakres wpływu i odpowiada na pytanie «czy to dotyczy mnie?» bez zmuszania czytelnika do poszukiwań. Ten przewodnik omawia, jak ją zaprojektować.

Czego klienci naprawdę oczekują od strony statusu

Każdą wizytę na stronie statusu napędzają dwa pytania. Klienci chcą wiedzieć, czy to, na czym im zależy, jest zepsute i czy ktokolwiek to zauważył. Wszystko inne to dekoracja.

Jeśli strona odpowiada na oba pytania od razu, klienci jej ufają i przestają dzwonić do wsparcia. Jeśli nie odpowiada na żadne, każdy incydent generuje pięć dodatkowych zgłoszeń do wsparcia i stopniową utratę wiarygodności. Projekt wizualny ma mniejsze znaczenie niż struktura tego, co pokazane jest nad linią zagięcia.

Cztery cechy godnej zaufania strony

Cztery cechy odróżniają użyteczną stronę statusu od próżnej. Zrób wszystkie cztery dobrze, a klienci zaufają stronie podczas prawdziwego incydentu.

• Szczerość. Jeśli coś jest zepsute, jest oznaczone jako zepsute. Jeśli jeszcze nie wiesz, strona mówi: w trakcie analizy. Zielony status podczas prawdziwego incydentu niszczy zaufanie na zawsze.
• Szybkość. Incydenty są publikowane w ciągu kilku minut od wykrycia. Aktualizacja statusu, która spóźnia się o godzinę względem rzeczywistych awarii, traktowana jest jak tekst marketingowy.
• Jasność zakresu. Klient potrafi w kilka sekund stwierdzić, czy incydent dotyczy tego, z czego korzysta. Region, obszar produktu i waga to trzy wymiary do oznaczenia.
• Prosty język. Aktualizacje pisane są tym samym tonem, jakim wyjaśniłbyś incydent znajomemu, a nie w bezosobowej, korporacyjnej prozie.

Aktualizacje incydentów, które działają

Większość szablonów stron statusu domyślnie używa biernego, asekuracyjnego tonu. «Analizujemy zgłoszenia o podwyższonych opóźnieniach». Brzmi to jak unik. Wzorzec, który buduje zaufanie, jest odwrotny: nazwij, co jest zepsute, nazwij wpływ na użytkownika, nazwij, co z tym robisz.

Dobra pierwsza aktualizacja brzmi tak: «Logowanie nie działa dla około 30% klientów w regionach UE. Failover bazy danych jest w toku, szacowany czas 10 minut». Dobre rozwiązanie brzmi tak: «Logowanie zostało przywrócone. Główną przyczyną był zablokowany skrypt failovera. Dodaliśmy watchdoga, aby to nie mogło już cicho się zaciąć». Obie są krótkie. Obie nazywają wpływ, działanie i dalsze kroki.

Prawidłowe określenie zakresu wpływu

Pojedyncza, ogólna strona statusu to niewłaściwa abstrakcja, gdy masz więcej niż jedną linię produktową lub region. Klient z wdrożeniem wyłącznie w USA nie przejmuje się tym, że Twój region UE ma podwyższone opóźnienia.

• Podziel stronę według komponentu: API, dashboard, ingestia, billing i tak dalej. Pokazuj status per komponent, a nie pojedynczy globalny wskaźnik.
• Dodaj wymiar regionu lub środowiska, gdy ma to zastosowanie. Wyraźnie oznaczaj region dotknięty incydentem.
• Pokazuj ostatnie 90 dni incydentów poniżej statusu na żywo. Widok historyczny to to, co odwiedzający sprawdzają, decydując, czy jesteś wystarczająco niezawodny, by na Ciebie postawić.
• Jeśli to oferujesz, udostępnij kanał RSS lub JSON, aby zainteresowani klienci mogli zasubskrybować go we własnych narzędziach.

Planowane prace serwisowe bez milczenia

Planowane prace serwisowe to najłatwiejsza część strony statusu do zrobienia dobrze i jedna z najczęściej pomijanych. Opublikuj okno z 48-godzinnym wyprzedzeniem, podsumuj, co zostanie objęte, a co nie, i opublikuj kontynuację potwierdzającą zakończenie.

Traktuj planowane prace serwisowe tym samym tonem co aktualizacje incydentów. Nazwij okno. Nazwij dotknięte usługi. Nazwij wpływ. Czysty post o pracach serwisowych zapobiega zgłoszeniu do wsparcia. Niejasny tworzy ich tuzin.

Niezawodność samej strony statusu

Hostuj stronę statusu w miejscu niezależnym od głównej infrastruktury. Jeśli strona statusu zwraca ten sam błąd bazy danych co panel administracyjny podczas awarii bazy danych, sama strona staje się częścią incydentu. Strona statusu, która ładuje się od osobnego dostawcy, z osobnego regionu lub statycznego CDN, to ta odrobina dyscypliny architektonicznej, która zwraca się przy pierwszej prawdziwej awarii. Większość zespołów odkrywa to w trudny sposób.