Ako vytvoriť stránku so stavom služby: komponenty, incidenty a kontroly dostupnosti

Stránka so stavom služby na jednom mieste ukazuje vašim používateľom, či služba funguje. Na jej vytvorenie potrebujete zoznam komponentov (webová stránka, API, platby, doručovanie e-mailov), aktuálny stav každého z nich, incidenty s časovo označenými aktualizáciami, históriu minulých incidentov a voliteľne odber, aby sa ľudia o problémoch dozvedeli bez toho, aby ich museli kontrolovať. Samotná stránka je jednoduchá. Dôležité rozhodnutie je, kde beží: stránka so stavom musí zostať dostupná, keď vaša aplikácia nie je, preto nesmie zdieľať hosting, databázu ani proces nasadzovania s tým, čo hlási.

Na čo slúži stránka so stavom

Keď sa niečo pokazí, používatelia chcú vedieť tri veci: či je problém iba u nich, či o ňom viete a kedy bude opravený. Stránka so stavom odpovie na všetky tri bez záplavy podporných lístkov. Zároveň buduje dôveru, pretože viditeľná história incidentov s úprimnými opismi ukazuje, ako riešite problémy.

Nie je to changelog. Nové funkcie patria na stránku so zmenami; výpadky a údržbu uvádzajte tu.

Čo stránka potrebuje

Dáta

Stavy komponentov sú zvyčajne krátky pevný zoznam: Prevádzkyschopné, Znížený výkon, Čiastočný výpadok, Úplný výpadok, Údržba.

Stránky

• Verejná stránka so stavom: celkový banner („Všetky systémy fungujú“ alebo najhorší aktuálny stav), každý komponent so stavom, aktívny incident s aktualizáciami, nadchádzajúca údržba a pás histórie za 90 dní, ak máte údaje z kontrol.
• Stránka incidentu: úplná časová os aktualizácií pre jeden incident, s vlastnou adresou, aby na ňu mohla podpora odkázať.
• História: minulé incidenty podľa mesiacov.
• Odber: prihlásenie e-mailom s potvrdením a nastavením podľa komponentov.
• Správa: vytvorenie incidentu, zverejňovanie aktualizácií, zmena stavov komponentov, plánovanie údržby.

Oprávnenia

Verejnosť vidí všetko, čo je zverejnené. Zverejňovať môže iba váš tím. Ak to ide, oddeľte prihlásenie do správy od prihlasovacieho systému hlavnej aplikácie, aby výpadok poskytovateľa prihlasovania nezamkol vás von z vlastnej stránky so stavom.

Kľúčové rozhodnutie: buďte nezávislí

Tu zlyhá väčšina domácky vytvorených stránok so stavom. Ak vaša stránka so stavom:

• beží na tom istom serveri alebo hostingovom účte ako aplikácia,
• číta z tej istej databázy,
• sedí za rovnakým nastavením domény alebo CDN,
• alebo ju nasadzuje ten istý proces,

potom ju mnohé výpadky zhodia tiež, presne vtedy, keď ju ľudia potrebujú. Praktické kroky:

• Samostatný hosting. Iný projekt alebo poskytovateľ než hlavná aplikácia.
• Vlastná subdoména, napríklad status.example.com, nasmerovaná samostatne v DNS. Pozri si ako fungujú domény a DNS.
• Vlastné dáta. Incidenty žijú vo vlastnom úložisku stránky so stavom, nie v databáze aplikácie.
• Statický záložný variant. Niektoré tímy robia verejnú stránku statickú a pri každej aktualizácii ju znova vygenerujú, takže takmer nie je čo rozbiť.

Ručné aktualizácie alebo automatické kontroly

Ručne (na začiatok)

Tím zverejňuje incidenty a mení stavy komponentov ručne zo správy. Tak mnohé stránky so stavom v praxi fungujú, lebo ľudský úsudok („platby sú pomalé pri niektorých typoch kariet“) je užitočnejší než automatická červená bodka.

Na rýchle zistenie problémov použite externý monitor dostupnosti, ktorý kontroluje aplikáciu zhruba každú minútu a upozorní vás e-mailom, SMS alebo v chate. Mnohé monitorovacie služby majú bezplatnú úroveň.

Automaticky

Automatizácia znamená, že niečo pravidelne kontroluje každý komponent a aktualizuje jeho stav. Na to je potrebný kód, ktorý beží podľa plánu, mimo infraštruktúry vašej hlavnej aplikácie. Dva bežné vzory:

• Externý monitor zavolá vašu stránku so stavom cez webhook, keď kontrola zlyhá alebo sa obnoví, a stránka aktualizuje komponent.
• Plánovaná úloha v hostingu stránky so stavom pingne každý komponent a zaznamená výsledok. Pred spoliehaním sa na to skontrolujte, ako váš hosting spracúva plánované úlohy; náš sprievodca spúšťaním úloh na pozadí vysvetľuje možnosti.

Automatické zmeny môžu pri pomalej sieti kolísať (hore, dole, hore). Vyžadujte dve alebo tri zlyhané kontroly pred zmenou stavu a nechajte človeka potvrdiť väčší výpadok, skôr než ho oznámite.

Ako písať aktualizácie incidentov

• Pište včas. „Vyšetrujeme hlásenia o zlyhaných prihláseniach“ do pár minút je lepšie než dokonalá správa o hodinu neskôr.
• Napíšte, čo si používatelia všimnú, nie čo sa interne pokazilo.
• Sľúbte čas ďalšej aktualizácie a držte sa ho.
• Na záver pridajte krátke zhrnutie, keď je vyriešené: čo sa stalo, ako dlho to trvalo, čo meníte.

Prompt, ktorý funguje

Vytvor samostatnú stránku so stavom pre našu aplikáciu Parcelio, hostovanú osobitne na status.parcelio.com. Komponenty: Webová stránka, API na sledovanie, Notifikácie, Platby, každý so stavom Prevádzkyschopné, Znížený výkon, Čiastočný výpadok, Úplný výpadok alebo Údržba. Verejná stránka zobrazuje celkový banner podľa najhoršieho aktuálneho stavu, každý komponent so stavom, aktívne incidenty s časovo označenými aktualizáciami od najnovšej, nadchádzajúcu údržbu a zoznam minulých incidentov podľa mesiacov. Každý incident má vlastnú stránku. Pridaj stránku správy chránenú heslom na vytváranie incidentov (názov, dopad, zasiahnuté komponenty), zverejňovanie aktualizácií (správa a stav: Vyšetrujeme, Identifikované, Sledujeme, Vyriešené), zmenu stavov komponentov a plánovanie údržby. Pridaj endpoint POST /api/check-result, ktorý prijíma názov komponentu a stav hore/dole z externého monitora, chránený tajným tokenom, a označí komponent ako Znížený výkon až po troch po sebe idúcich výpadkoch. Všetko ukladaj do vlastnej databázy tejto aplikácie. Jednoduchý, pokojný dizajn, ktorý sa rýchlo načíta na telefóne.

Postup budovania

1. Verejná stránka a správa s ručnými incidentmi. Už len to je funkčná stránka so stavom.
2. Samostatný hosting a nasmerovanie subdomény.
3. Stránky incidentov a história.
4. Plánovaná údržba.
5. Odbery. Prihlásenie e-mailom s dvojitým potvrdením a upozornenia na nové incidenty a aktualizácie. E-mail potrebuje poskytovateľa; pozri ako posielať e-maily z aplikácie.
6. Webhook monitora, ak chcete automatické zmeny stavov.
7. Nacvičte to. Vytvorte falošný incident, zverejnite aktualizácie, vyriešte ho, skontrolujte e-maily a potom ho zmažte.

Časté chyby

• Hostovanie spolu s aplikáciou. Najčastejšia a najvážnejšia chyba.
• Stránka, ktorá vždy hlási „Všetky systémy fungujú“. Ak nikdy neukazuje problémy, ľudia jej prestanú veriť.
• Bez časových značiek alebo časového pásma. Časy vždy zobrazujte s pásmom.
• Spoliehanie sa na prihlásenie hlavnej aplikácie pri správe stránky so stavom.
• Ticho medzi aktualizáciami. „Bez zmeny, stále pracujeme na tom“ je platná aktualizácia.
• Kolísajúce automatické stavy. Pred zmenou vyžadujte opakované zlyhania.

Kedy je lepšia hotová služba na stav

Hotové služby na stránky so stavom sú postavené práve na nezávislosti: bežia na samostatnej infraštruktúre, zvládajú upozornenia odberateľov e-mailom a SMS a často zahŕňajú monitoring a integrácie s nástrojmi na riešenie incidentov. Ak je dostupnosť súčasťou toho, za čo zákazníci platia, alebo máte zmluvné povinnosti hlásiť incidenty, dedikovaná služba sa väčšinou oplatí. Mnohé majú bezplatné alebo lacné úrovne pre malé tímy, takže sa oplatí pozrieť si ich pred budovaním.

Vlastnú stránku budujte vtedy, keď chcete plnú kontrolu nad dizajnom a formuláciami, keď sú vaše potreby jednoduché (pár komponentov, ručné aktualizácie) alebo keď je stránka so stavom súčasťou produktu, ktorý stavate pre iných.

Vytvorenie s Mythexom

V Mythexe môžete stránku so stavom vytvoriť ako samostatný projekt oddelený od hlavnej aplikácie, čo jej dá vlastný hosting a vlastnú databázu. Opíšte ju v chate, skontrolujte v živom náhľade, potom ju publikujte a pripojte subdoménu ako status.vasadomena.sk (vlastné domény sú v Pro). Majte na pamäti, že publikované aplikácie v Mythexe aj ich databázy pri nečinnosti zaspia a prebudia sa pri ďalšej návšteve, takže prvé načítanie po tichom období môže byť pomalšie; jednoduchá, ľahká stránka pomáha.

Mythex zatiaľ nedokumentuje plánované úlohy, preto na automatické kontroly použite externý monitor dostupnosti, ktorý volá webhook endpoint vašej stránky so stavom (pozri recept na webhooky). Upozornenia odberateľom e-mailom idú cez vášho vlastného poskytovateľa a kľúč je uložený ako tajomstvo projektu (recept na odosielanie e-mailov).

Otázky