Jak vytvořit stavovou stránku: komponenty, incidenty a kontroly dostupnosti

Stavová stránka na jednom místě říká vašim uživatelům, zda služba funguje. Potřebujete seznam komponent (webová aplikace, API, platby, doručování e-mailů), aktuální stav každé z nich, incidenty s časově označenými aktualizacemi, historii minulých incidentů a volitelně odběr upozornění, aby se lidé o problémech dozvěděli, aniž by museli stránku kontrolovat. Samotná stránka je jednoduchá. Rozhodující je, kde poběží: stavová stránka musí zůstat dostupná, i když je vaše aplikace mimo provoz, takže nesmí sdílet hosting, databázi ani nasazovací pipeline se službou, kterou hlásí.

K čemu stavová stránka slouží

Když něco přestane fungovat, uživatelé chtějí vědět tři věci: jestli je problém jen u nich, jestli o něm víte a kdy bude opraven. Stavová stránka na všechny tři otázky odpoví bez záplavy podpůrných dotazů. Zároveň buduje důvěru, protože viditelná historie incidentů s upřímnými popisy ukazuje, jak řešíte problémy.

Nejde o changelog. Nové funkce patří na stránku s changelogem; výpadky a plánovaná údržba patří sem.

Co stránka potřebuje

Data

Stavy komponent bývají krátký pevný seznam: Funkční, Snížený výkon, Částečný výpadek, Úplný výpadek, Probíhá údržba.

Stránky

• Veřejná stavová stránka: celkový banner („Všechny systémy fungují“ nebo nejhorší aktuální stav), každá komponenta se svým stavem, případný aktivní incident s aktualizacemi, nadcházející údržba a pásek historie za 90 dní, pokud máte data z kontrol.
• Stránka incidentu: kompletní časová osa aktualizací jednoho incidentu s vlastní URL, aby na něj mohla podpora odkazovat.
• Historie: minulé incidenty po měsících.
• Odběr: přihlášení e-mailem s potvrzením a nastavením upozornění pro jednotlivé komponenty.
• Administrace: vytvoření incidentu, zveřejňování aktualizací, změna stavu komponent, plánování údržby.

Oprávnění

Veřejnost vidí vše, co je zveřejněno. Zveřejňovat může jen váš tým. Pokud to jde, nechte přihlášení do administrace odděleně od přihlašovacího systému hlavní aplikace, aby výpadek vašeho poskytovatele autentizace nezamkl přístup ke stavové stránce.

Klíčové rozhodnutí: udělejte ji nezávislou

Tady se většina domácích stavových stránek pokazí. Pokud vaše stavová stránka:

• běží na stejném serveru nebo ve stejném hostingovém účtu jako aplikace,
• čte ze stejné databáze,
• je za stejným nastavením domény nebo CDN,
• nebo ji nasazuje stejná pipeline,

pak ji při mnoha výpadcích shodí také, a to přesně ve chvíli, kdy ji lidé potřebují. Praktické kroky:

• Oddělený hosting. Jiný projekt nebo poskytovatel než u hlavní aplikace.
• Vlastní subdoména, například status.example.com, nasměrovaná zvlášť v DNS. Viz jak fungují domény a DNS.
• Vlastní data. Incidenty žijí v úložišti stavové stránky, ne v databázi vaší aplikace.
• Statická záloha. Některé týmy udělají veřejnou stránku statickou a přegenerují ji při každé aktualizaci, takže téměř nic nemůže selhat.

Ruční aktualizace, nebo automatické kontroly

Ručně (tak začněte)

Váš tým incidenty zakládá a stavy komponent mění ručně z administrace. Tak mnoho stavových stránek v praxi funguje, protože lidský úsudek („platby jsou u některých typů karet pomalé“) je užitečnější než automatická červená tečka.

Aby se o problémech dozvěděli rychle, použijte externí monitor dostupnosti, který kontroluje vaši aplikaci zhruba každou minutu a upozorní vás e-mailem, SMS nebo zprávou do chatu. Mnoho monitorovacích služeb má bezplatné verze.

Automaticky

Automatizace znamená, že něco pravidelně kontroluje každou komponentu a aktualizuje její stav. K tomu je potřeba kód běžící podle plánu, zvenku od infrastruktury vaší hlavní aplikace. Dva běžné vzory:

• Externí monitor zavolá vaši stavovou stránku přes webhook, když kontrola selže nebo se obnoví, a stavová stránka komponentu aktualizuje.
• Naplánovaná úloha v hostingu stavové stránky pinguje každou komponentu a zapisuje výsledek. Než se na to spolehnete, ověřte, jak váš hosting řeší plánované úlohy. Možnosti vysvětluje náš průvodce spouštěním úloh na pozadí.

Automatické změny mohou při pomalé síti kmitat (nahoru, dolů, nahoru). Vyžadujte dvě nebo tři neúspěšné kontroly, než se stav změní, a u velkého výpadku nechte potvrdit změnu člověkem, než ji oznámíte.

Jak psát aktualizace incidentů

• Pište brzy. „Prověřujeme hlášení o selhávajícím přihlašování“ během několika minut je lepší než dokonalá zpráva o hodinu později.
• Řekněte, čeho si uživatelé všimnou, ne co se rozbilo uvnitř.
• Slibte čas další aktualizace a dodržte ho.
• Po vyřešení uzavřete krátkým shrnutím: co se stalo, jak dlouho to trvalo, co měníte.

První prompt, který funguje

Vytvoř samostatnou stavovou stránku pro naši aplikaci Parcelio, hostovanou odděleně na status.parcelio.com. Komponenty: Web, API pro sledování, Notifikace, Platby, každá se stavem Funkční, Snížený výkon, Částečný výpadek, Úplný výpadek nebo Probíhá údržba. Veřejná stránka ukazuje celkový banner podle nejhoršího aktuálního stavu, každou komponentu se stavem, aktivní incidenty s časově označenými aktualizacemi od nejnovější, nadcházející údržbu a seznam minulých incidentů po měsících. Každý incident má vlastní stránku. Přidej administraci chráněnou heslem pro zakládání incidentů (název, dopad, postižené komponenty), zveřejňování aktualizací (zpráva a stav: Prověřujeme, Identifikováno, Sledujeme, Vyřešeno), změnu stavů komponent a plánování údržby. Přidej endpoint POST /api/check-result, který přijímá název komponenty a stav nahoru/dolů od externího monitoru, chráněný tajným tokenem, a označí komponentu jako Snížený výkon až po třech po sobě jdoucích pádech. Vše ukládej do vlastní databáze této aplikace. Jednoduchý, klidný design, který se rychle načte na telefonu.

Postup stavby

1. Veřejná stránka a administrace s ručními incidenty. Už to je funkční stavová stránka.
2. Hostujte ji odděleně a nasměrujte na ni subdoménu.
3. Stránky incidentů a historie.
4. Plánovaná údržba.
5. Odběr. Přihlášení e-mailem s dvojím potvrzením a upozornění při nových incidentech a aktualizacích. E-mail potřebuje poskytovatele; viz jak posílat e-maily z aplikace.
6. Webhook monitoru, pokud chcete automatické změny stavu.
7. Vyzkoušejte to nanečisto. Založte fiktivní incident, zveřejněte aktualizace, vyřešte ho, zkontrolujte e-maily a pak ho smažte.

Časté chyby

• Hostování spolu s aplikací. Nejčastější a nejzávažnější chyba.
• Stránka, která pořád hlásí „Všechny systémy fungují“. Pokud nikdy neukáže problémy, uživatelé jí přestanou věřit.
• Bez časových údajů nebo časového pásma. Časy vždy zobrazujte i s pásmem.
• Spoléhání na přihlášení hlavní aplikace pro administraci.
• Ticho mezi aktualizacemi. „Bez změny, stále na tom pracujeme“ je platná aktualizace.
• Kmitající automatické stavy. Před změnou vyžadujte opakované selhání.

Kdy je lepší hotová služba pro stavové stránky

Hotové služby pro stavové stránky stojí na řešení problému nezávislosti: běží na oddělené infrastruktuře, zasílají upozornění odběratelům e-mailem i SMS a často zahrnují monitoring a integrace s nástroji pro řízení incidentů. Pokud dostupnost patří k tomu, za co zákazníci platí, nebo máte smluvní povinnost incidenty hlásit, dedikovaná služba se obvykle vyplatí. Mnohé mají bezplatné nebo levné verze pro malé týmy, takže se vyplatí nejdřív zkontrolovat.

Stavovou stránku si postavte sami, když chcete plnou kontrolu nad designem a formulacemi, když jsou vaše potřeby jednoduché (pár komponent, ruční aktualizace), nebo když je stavová stránka součástí produktu, který stavíte pro ostatní.

Stavba s Mythexem

V Mythexu můžete stavovou stránku postavit jako samostatný projekt oddělený od hlavní aplikace, což jí dá vlastní hosting a vlastní databázi. Popište ji v chatu, zkontrolujte v živém náhledu, pak ji publikujte a připojte subdoménu typu status.vasedomena.cz (vlastní domény jsou v tarifu Pro). Mějte na paměti, že publikované aplikace v Mythexu a jejich databáze při nečinnosti usínají a probouzejí se při další návštěvě, takže první načtení po klidném období může být pomalejší; jednoduchá, lehká stránka tomu pomáhá.

Mythex zatím nepopisuje plánované úlohy, takže pro automatické kontroly použijte externí monitor dostupnosti, který volá webhook endpoint vaší stavové stránky (viz recept na webhooky). E-maily odběratelům odesílejte přes vlastního poskytovatele a klíč uložte jako tajemství projektu (recept na odesílání e-mailů).

Otázky