Vissza a bloghoz

Hogyan néz ki egy jó nyilvános állapotoldal

· 6 perc olvasás

A nyilvános állapotoldal az a hely, ahová az ügyfelek fordulnak egy kiesés idején. Egy jó állapotoldal csökkenti a support ticketek számát és bizalmat épít. Miből áll össze.

Hogyan néz ki egy jó nyilvános állapotoldal

Mit kell tartalmaznia egy jó állapotoldalnak

  1. Minden kulcsfontosságú szolgáltatás aktuális állapota. Nem csak "minden OK", hanem komponensekre bontva (API, web, dashboard, emailing, payment processing).
  2. Incidenstörténet az elmúlt 90 napra. Anélkül, hogy bármit is megpróbálnánk elrejteni - az átlátható történet bizalmat épít.
  3. Uptime metrika (jellemzően 30 napra) minden komponensre, átlátható százalékként kifejezve.
  4. Tervezett karbantartás. Banner a dátummal és annak leírásával, hogy mi lesz elérhetetlen.
  5. Aktív incidens a frissítések idővonalával. Investigating → Identified → Monitoring → Resolved.
  6. Feliratkozási űrlap. Az ügyfelek e-mailt kapnak az állapot változásakor, és nem kell ismételten ellenőrizniük az oldalt.

Tiszta komponenshierarchia

Egyetlen "monitor" bejegyzés helyett bontsd a szolgáltatást olyan komponensekre, amelyeknek az ügyfél szempontjából van értelmük:

  • Web App - frontend (a látogatók használják)
  • API - backend a programozott integrációkhoz
  • Auth / Login - bejelentkezés
  • Email delivery - tranzakciós e-mailek
  • Background jobs - sync, számlázás, exportok
  • Status page - meta komponens: maga az állapotoldal is kieshet (ezért más infrastruktúrán kellene futnia, mint a termék)

Incident communication: egy jó frissítés anatómiája

Valódi kiesés esetén tartsd be ezeket a fázisokat:

  1. Investigating - "Azonosítottunk egy problémát a [komponens] kapcsán. A csapat vizsgálja az okot." (az észleléstől számított 5 percen belül)
  2. Identified - "Az ok [röviden]. Dolgozunk a javításon. ETA [idő]." (amikor tudod, mi okozza a problémát)
  3. Monitoring - "Telepítettük a javítást. Figyeljük, hogy a probléma nem ismétlődik-e meg." (a megoldás telepítése után)
  4. Resolved - "Az incidens megoldódott. Időtartam X perc. Postmortem következik." (megerősített helyreállás után)

Minden fázis kap egy timestampet és saját frissítést. Az incidens után tegyél közzé egy post-mortemet (root cause, timeline és az ismétlődést megakadályozó intézkedések).

Szabály: Soha ne használj homályos kifejezéseket, mint "experiencing some issues". Az ügyfelek konkrétumokat akarnak: "A bejelentkezés a próbálkozások ~30 %-ánál sikertelen. Az API normálisan működik. A web csak read-only módban érhető el."

Hosting: a független infrastruktúra elve

Az állapotoldalnak más infrastruktúrán kell futnia, mint a monitorozott szolgáltatás. Ha kiesik az AWS régiód, az ugyanabban a régióban hostolt állapotoldal vele együtt esik ki - pontosan akkor, amikor az ügyfeleknek a legnagyobb szükségük van rá.

Gyakorlati megoldások:

  • Hosting külső SaaS-on keresztül (ePulz.io, Better Stack, Atlassian Statuspage)
  • Saját statikus oldal egy CDN-en (Cloudflare Pages, Netlify), az API endpoint máshol
  • Végső esetben egy minimális statikus oldal Cloudflare-en, kézzel frissített szöveggel

Subscribers: e-mail és webhook

Az ügyfelek nem akarják folyamatosan frissíteni az állapotoldalt. Egy jó oldal ezért támogatja:

  • Email subscribers - az ePulz.io-ban bejelentkezett, fizetős csomaggal rendelkező felhasználók számára elérhető (feliratkozásokat csak ellenőrzött fiókoktól gyűjtünk, nem anonim látogatóktól)
  • Webhook - olyan csapatoknak, akik az állapotot a saját Slackjükbe vagy PagerDutyjukba akarják integrálni

Anti-pattern: a problémák elrejtése

A kísértés, hogy egy kiesést "degraded"-nek jelölj "down" helyett (vagy egyáltalán ne mutasd meg), nagy, de rövidlátó:

  • Az ügyfelek úgyis észreveszik a kiesést (saját monitoringon, support ticketeken vagy közösségi médián keresztül)
  • Elveszíted a bizalmat, amikor kiderül, hogy a status "OK"-t jelez egy nyilvánvaló kiesés alatt
  • Elveszíted az uptime trend valós képét, amelyre a belső döntéshozatalhoz van szükséged

A legjobb stratégia a radikális átláthatóság. A GitLab, a Cloudflare és a Stripe is részletes post-mortemeket tesz közzé még a kínos hibák esetén is, és a közösség ezt értékeli.

SEO és brand

Egy állapotoldalnak:

  • Stabil és könnyen megjegyezhető URL-en kell lennie a szolgáltatás állapotához
  • Saját brandingje legyen (logó, színek) - az ügyfélnek látnia kell, hogy még mindig a te oldaladon van
  • Indexelve legyen a Google-ben (jobb láthatóság a "[brand] down" keresésnél)
  • Linkelve legyen a főoldalról (footer "Szolgáltatás állapota")

Összegzés

Az állapotoldal nem dekoráció. Operatív eszköz, amely egy incidens alatt csökkenti a support terhelését és hosszú távú bizalmat épít. A helyes konfigurációba fektetett néhány óra már az első nagyobb kiesésnél megtérül.

Hozz létre állapotoldalt 5 perc alatt

ePulz.io állapotoldalak saját brandinggel, email subscribers funkcióval és incident timeline-nal. 7 nap ingyen.

ePulz.io kipróbálása →

Kapcsolódó

Megosztás: Link másolva

Próbálja ki az ePulz.io-t ingyen - 7 nap bankkártya nélkül.

Fiók létrehozása