Státuszoldal készítése: komponensek, incidensek és elérhetőség-ellenőrzés

A státuszoldal egy helyen mutatja meg a felhasználóknak, hogy a szolgáltatásod működik-e. Ehhez szükséged van a komponensek listájára (weboldal, API, fizetés, e-mail-küldés), mindegyik aktuális állapotára, időbélyeges incidensekre és frissítésekre, a korábbi incidensek előzményeire, és opcionálisan feliratkozásokra, hogy az emberek problémákról értesüljenek anélkül, hogy folyamatosan ellenőrizniük kellene. Maga az oldal egyszerű. A fontos döntés az, hogy hol fut: a státuszoldalnak akkor is elérhetőnek kell maradnia, amikor az appod nem működik, ezért nem szabad ugyanazt a tárhelyet, adatbázist vagy telepítési folyamatot használnia, mint amit figyel.

Mire való a státuszoldal

Ha valami elromlik, a felhasználók három dolgot akarnak tudni: csak nekem nem működik, tudjátok-e a problémát, és mikorra javítjátok ki. A státuszoldal mindhárom kérdésre választ ad anélkül, hogy támogatási kérések áradatot indítana el. Idővel bizalmat is épít, mert a látható incidens-előzmények, őszinte összefoglalókkal, megmutatják, hogyan kezeled a problémákat.

Nem changelog. Az új funkciók a changelog oldalra kerülnek; a leállások és karbantartások ide.

Mit kell tudnia az oldalnak

Adatok

A komponensek állapota általában egy rövid, rögzített lista: Működik, Csökkent teljesítmény, Részleges kiesés, Súlyos kiesés, Karbantartás alatt.

Oldalak

• Nyilvános státuszoldal: összesítő szalag („Minden rendszer működik”, vagy a legrosszabb aktuális állapot), minden komponens az állapotával, az aktív incidens a frissítéseivel, a közelgő karbantartások, és 90 napos előzmény-sáv, ha van ellenőrzési adatod.
• Incidens-oldal: egy incidens teljes időrendi frissítéslistája, saját URL-lel, hogy az ügyfélszolgálat hivatkozhasson rá.
• Előzmények: korábbi incidensek hónaponként.
• Feliratkozás: e-mailes regisztráció megerősítéssel és komponensenkénti beállításokkal.
• Admin: incidens létrehozása, frissítések közzététele, komponensek állapotának módosítása, karbantartás ütemezése.

Jogosultságok

A nyilvánosság mindent lát, ami közzé van téve. Csak a csapatod tehet közzé. Ha lehet, tartsd külön az admin bejelentkezést az app fő bejelentkezési rendszerétől, hogy a hitelesítési szolgáltatód kiesése ne zárjon ki a saját státuszoldaladból.

A kulcsdöntés: legyen független

Az otthon készült státuszoldalak többsége itt bukik meg. Ha a státuszoldalad:

• ugyanazon a szerveren vagy tárhelyfiókon fut, mint az appod,
• ugyanabból az adatbázisból olvas,
• ugyanazon a domain-beállításon vagy CDN-konfiguráción múlik,
• vagy ugyanaz a folyamat telepíti,

akkor sok leállás vele is végez, éppen akkor, amikor az embereknek szükségük van rá. Gyakorlati lépések:

• Külön tárhely. Másik projekt vagy szolgáltató, mint a fő app.
• Saját aldomain, például status.example.com, külön beállítva a DNS-ben. Lásd: hogyan működik a domain és a DNS.
• Saját adatok. Az incidensek a státuszoldal saját tárhelyén élnek, nem az app adatbázisában.
• Statikus tartalék. Néhány csapat statikusra építi a nyilvános oldalt, és minden frissítésnél újragenerálja, így szinte nincs mi elromoljon.

Kézi frissítés vagy automatikus ellenőrzés

Kézi (ezzel kezdd)

A csapatod kézzel teszi közzé az incidenseket és módosítja a komponensek állapotát az admin oldalon. Sok státuszoldal így működik a gyakorlatban, mert egy emberi ítélet („a kártyás fizetések néhány kártyatípusnál lassúak”) hasznosabb, mint egy automatikus piros pötty.

Hogy gyorsan megtudd, ha probléma van, használj külső elérhetőség-figyelőt, amely percenként vagy annál gyakrabban ellenőrzi az appodat, és e-mailben, SMS-ben vagy csetben riaszt. Sok figyelőszolgáltatásnak van ingyenes csomagja.

Automatikus

Az automatizálás azt jelenti, hogy valami rendszeresen ellenőrzi az egyes komponenseket, és frissíti az állapotukat. Ehhez olyan kód kell, amely ütemezetten fut, és az app fő infrastruktúráján kívül. Két gyakori minta:

• Egy külső figyelő hívja a státuszoldalt egy webhookon keresztül, amikor egy ellenőrzés hibázik vagy helyreáll, és a státuszoldal frissíti a komponenst.
• Egy ütemezett feladat a státuszoldal saját tárhelyén minden komponenst megvizsgál, és rögzíti az eredményt. Nézd meg, hogyan kezeli a tárhelyed az ütemezett feladatokat, mielőtt erre építesz; a háttérfolyamatok futtatásáról szóló útmutató ismerteti a lehetőségeket.

Az automatikus változások ingadozhatnak (fel, le, fel), lassú hálózaton. Két-három sikertelen ellenőrzést kérj, mielőtt állapotot váltasz, és hagyj, hogy egy ember erősítse meg, mielőtt egy súlyos kiesést bejelentesz.

Incidens-frissítések írása

• Korán közölj. Az „Vizsgáljuk a sikertelen bejelentkezések jeleit” üzenet percekkel a probléma után jobb, mint egy tökéletes üzenet egy óra múlva.
• Mondd meg, mit látnak a felhasználók, ne azt, hogy belül mi romlott el.
• Ígérj következő frissítési időpontot, és tartsd is be.
• Zárd rövid összefoglalóval, amint megoldódott: mi történt, mennyi ideig tartott, és mit változtatsz.

Egy működő első prompt

Építs egy önálló státuszoldalt a Parcelio appunkhoz, külön hosztolva a status.parcelio.com címen. Komponensek: Weboldal, Követési API, Értesítések, Fizetések, mindegyik állapota: Működik, Csökkent teljesítmény, Részleges kiesés, Súlyos kiesés vagy Karbantartás alatt. A nyilvános oldal összesítő szalagot mutat a legrosszabb aktuális állapot alapján, minden komponenst az állapotával, az aktív incidenseket időbélyeges frissítésekkel, legfrissebbel elöl, a közelgő karbantartásokat, és a korábbi incidensek listáját hónapokra bontva. Minden incidensnek saját oldala van. Adj egy jelszóval védett admin oldalt incidensek létrehozásához (cím, hatás, érintett komponensek), frissítések közzétételéhez (üzenet és állapot: Vizsgálat alatt, Azonosítva, Figyelés, Megoldva), komponensek állapotának módosításához és karbantartás ütemezéséhez. Adj egy POST /api/check-result végpontot, amely egy külső figyelőtől komponensnévet és fel/le értéket fogad, titkos tokennel védve, és csak három egymást követő hiba után jelöli a komponenst Csökkent teljesítményűnek. Mindent az app saját adatbázisában tárolj. Egyszerű, nyugodt dizájn, amely telefonon is gyorsan tölt be.

Építési lépések

1. Nyilvános oldal és admin kézi incidensekkel. Ez önmagában már működő státuszoldal.
2. Külön hosztolás és aldomain beállítása rá.
3. Incidens-oldalak és előzmények.
4. Karbantartási ablakok.
5. Feliratkozások. Dupla megerősítéses e-mailes regisztráció, és értesítés új incidensekről és frissítésekről. Az e-mailhez szolgáltató kell; lásd: hogyan küldj e-mailt az appodból.
6. Figyelő webhook, ha automatikus állapotváltásokat szeretnél.
7. Próbagyakorlat. Hozz létre egy kitalált incidenst, tegyél közzé frissítéseket, oldd meg, ellenőrizd az e-maileket, majd töröld.

Gyakori hibák

• Az app mellett hosztolni. A leggyakoribb és legsúlyosabb hiba.
• Olyan oldal, amely mindig azt mondja: „Minden rendszer működik”. Ha sosem mutat problémát, a felhasználók megszűnnek bízni benne.
• Hiányzó időbélyeg vagy időzóna. Mindig az időzónával együtt jelenítsd meg az időt.
• Az app fő bejelentkezésére támaszkodni az admin oldalon.
• Csend a frissítések között. A „Nincs változás, még dolgozunk rajta” is érvényes frissítés.
• Ingadozó automatikus állapotok. Ismétlődő hibákat kérj, mielőtt változtatsz.

Mikor jobb egy hosztolt státuszoldal-szolgáltatás

A hosztolt státuszoldal-szolgáltatások a függetlenségi problémára épülnek: külön infrastruktúrán futnak, e-mailes és SMS-es értesítéseket kezelnek, gyakran tartalmaznak figyelést, és integrálhatók incidenskezelő eszközökkel. Ha a rendelkezésre állás része annak, amit az ügyfeleid fizetnek, vagy szerződéses kötelezettséged van az incidensek jelentésére, a dedikált szolgáltatás általában megéri. Sokuknak van ingyenes vagy olcsó csomagja kisebb csapatoknak, ezért érdemes megnézni, mielőtt építesz.

Saját építs, ha teljes kontrollt akarsz a dizájn és a szövegezés felett, ha az igényeid egyszerűek (néhány komponens, kézi frissítés), vagy ha a státuszoldal része egy másoknak készített terméknek.

Építés a Mythexszel

A Mythexen a státuszoldalt külön projektként építheted, a fő appodtól elkülönítve, ami külön tárhelyet és saját adatbázist ad. Írd le chatben, nézd meg az élő előnézetben, majd publikáld, és kösd hozzá egy aldomaint, például status.yourdomain.com-ot (az egyedi domainek a Pro csomagban érhetők el). Vedd figyelembe, hogy a publikált Mythex appok és adatbázisaik üresjáratban elalszanak, és a következő látogatásra ébrednek, így egy csendes időszak után az első betöltés lassabb lehet; egy egyszerű, könnyű oldal ezen segít.

A Mythex nem dokumentálja az ütemezett feladatokat, ezért automatikus ellenőrzéshez használj külső elérhetőség-figyelőt, amely a státuszoldal egy webhook végpontját hívja (lásd: webhook recept). Az előfizetőknek küldött riasztó e-maileket a saját szolgáltatódon keresztül küldöd, a kulcsot projekttitokként tárolva (e-mail küldési recept).

Kérdések