Slik bygger du en statusside: komponenter, hendelser og oppetidssjekker

En statusside forteller brukerne, på ett sted, om tjenesten din fungerer. For å bygge en trenger du en liste over komponenter (nettsiden, API-et, betalinger, e-postutsending), en nåværende status for hver, hendelser med tidsstemplede oppdateringer, en historikk over tidligere hendelser og eventuelt abonnement, slik at folk får vite om problemer uten å sjekke selv. Selve siden er enkel. Den viktige avgjørelsen er hvor den kjører: en statusside må være oppe når appen din er nede, så den bør ikke dele hosting, database eller deployløp med det den rapporterer om.

Hva en statusside er til for

Når noe går i stykker, vil brukerne vite tre ting: er det bare meg, er dere klar over det, og når blir det fikset. En statusside svarer på alle tre uten en flom av supporthenvendelser. Den bygger også tillit over tid, fordi en synlig hendelseshistorikk med ærlige gjennomganger viser hvordan du håndterer problemer.

Den er ikke en endringslogg. Nye funksjoner hører hjemme på en endringslogg-side; driftsstans og vedlikehold hører hjemme her.

Hva siden trenger

Data

Komponentstatuser er vanligvis en kort, fast liste: Operativ, Redusert ytelse, Delvis driftsstans, Alvorlig driftsstans, Under vedlikehold.

Sider

• Offentlig statusside: et samlet banner («Alle systemer fungerer» eller den verste nåværende statusen), hver komponent med sin status, eventuell aktiv hendelse med oppdateringene, kommende vedlikehold og en 90-dagers historikkstripe hvis du har sjekkdata.
• Hendelsesside: full tidslinje med oppdateringer for én hendelse, med egen URL slik at kundestøtten kan lenke til den.
• Historikk: tidligere hendelser sortert per måned.
• Abonner: e-postpåmelding med bekreftelse og innstillinger per komponent.
• Admin: opprett en hendelse, legg inn oppdateringer, endre komponentstatuser og planlegg vedlikehold.

Tilganger

Alle kan se det som er publisert. Bare teamet ditt kan legge inn oppdateringer. Hold admin-innloggingen atskilt fra innloggingssystemet i hovedappen hvis du kan, slik at en driftsstans hos autentiseringsleverandøren ikke låser deg ute av din egen statusside.

Den viktigste avgjørelsen: hold den uavhengig

Det er her de fleste hjemmelagde statussider feiler. Hvis statussiden din:

• kjører på samme server eller hostingkonto som appen,
• leser fra samme database,
• ligger bak samme domeoppsett eller CDN-konfigurasjon,
• eller deployes via samme løp,

da vil mange driftsstanser ta den med seg, akkurat når folk trenger den. Praktiske steg:

• Egen hosting. Et annet prosjekt eller en annen leverandør enn hovedappen.
• Eget subdomene, for eksempel status.eksempel.no, pekt separat i DNS. Se hvordan domener og DNS fungerer.
• Egne data. Hendelser lagres i statussidens egen lagring, ikke i appens database.
• En statisk reserve. Noen team gjør den offentlige siden statisk og bygger den på nytt ved hver oppdatering, slik at det nesten ikke er noe som kan gå i stykker.

Manuelle oppdateringer eller automatiske sjekker

Manuelt (start her)

Teamet ditt legger inn hendelser og endrer komponentstatuser for hånd fra admin-siden. Slik fungerer mange statussider i praksis, fordi en menneskelig vurdering («betalinger er trege for enkelte kortyper») er mer nyttig enn en automatisk rød prikk.

For å få vite raskt om problemer, bruk en ekstern oppetidsovervåker som sjekker appen din omtrent hvert minutt og varsler deg på e-post, SMS eller chat. Mange overvåkingstjenester har gratis nivåer.

Automatisk

Automatisering betyr at noe regelmessig sjekker hver komponent og oppdaterer statusen. Det krever kode som kjører etter en plan, utenfor hovedappens infrastruktur. To vanlige mønstre:

• En ekstern overvåker kaller statussiden din gjennom en webhook når en sjekk feiler eller går tilbake, og statussiden oppdaterer komponenten.
• En planlagt jobb i statussidens egen hosting pinger hver komponent og lagrer resultatet. Sjekk hvordan hostingen din håndterer planlagte oppgaver før du stoler på dette; guiden vår om bakgrunnsjobber forklarer alternativene.

Automatiske endringer kan flagre (opp, ned, opp) på et tregt nettverk. Krev to eller tre mislykkede sjekker før statusen endres, og la et menneske bekrefte før en alvorlig driftsstans kunngjøres.

Skrive hendelsesoppdateringer

• Legg ut tidlig. «Vi undersøker meldinger om mislykkede innlogginger» etter få minutter slår en perfekt melding en time senere.
• Si hva brukerne merker, ikke hva som gikk i stykker internt.
• Lov tidspunktet for neste oppdatering, og hold det.
• Avslutt med en kort oppsummering når saken er løst: hva som skjedde, hvor lenge, og hva du endrer.

En første prompt som fungerer

Bygg en frittstående statusside for appen vår Parcelio, som hostes separat på status.parcelio.no. Komponenter: Nettside, Sporings-API, Varsler, Betalinger, hver med status Operativ, Redusert ytelse, Delvis driftsstans, Alvorlig driftsstans eller Under vedlikehold. Den offentlige siden viser et samlet banner basert på den verste nåværende statusen, hver komponent med status, aktive hendelser med tidsstemplede oppdateringer nyeste først, kommende vedlikehold og en liste over tidligere hendelser per måned. Hver hendelse har sin egen side. Legg til en passordbeskyttet admin-side for å opprette hendelser (tittel, påvirkning, berørte komponenter), legge inn oppdateringer (melding og status: Undersøker, Identifisert, Overvåker, Løst), endre komponentstatuser og planlegge vedlikehold. Legg til et POST /api/check-result-endepunkt som tar imot et komponentnavn og opp/ned fra en ekstern overvåker, beskyttet av en hemmelig token, og som bare markerer en komponent som Redusert ytelse etter tre påfølgende nedsjekker. Lagre alt i denne appens egen database. Enkel, rolig design som laster raskt på telefoner.

Byggesteg

1. Offentlig side og admin med manuelle hendelser. Dette alene er en fungerende statusside.
2. Host den separat og pek et subdomene til den.
3. Hendelsessider og historikk.
4. Vedlikeholdsvinduer.
5. Abonnementer. Påmelding med dobbel bekreftelse på e-post og varsler om nye hendelser og oppdateringer. E-post krever en leverandør; se hvordan sende e-post fra appen din.
6. Overvåkingswebhook hvis du vil ha automatiske statusendringer.
7. Kjør en øvelse. Opprett en falsk hendelse, legg inn oppdateringer, løs den, sjekk e-postene, og slett den deretter.

Vanlige feil

• Hosting den sammen med appen. Den vanligste og alvorligste feilen.
• En side som alltid sier «Alle systemer fungerer». Hvis den aldri viser problemer, slutter folk å stole på den.
• Ingen tidsstempler eller tidssone. Vis alltid tidspunkter med sone.
• Å stole på hovedappens innlogging for admin-siden.
• Stillhet mellom oppdateringer. «Ingen endring, vi jobber fortsatt med det» er en gyldig oppdatering.
• Flagrende automatiske statuser. Krev gjentatte feil før en endring.

Når en ferdig statusside-tjeneste er det bedre valget

Ferdige tjenester for statussider er bygget rundt uavhengighetsproblemet: de kjører på egen infrastruktur, håndterer varsler til abonnenter på e-post og SMS, og inkluderer ofte overvåking og integrasjoner med verktøy for hendelser. Hvis oppetid er en del av det kundene betaler for, eller du har avtalemessige forpliktelser til å rapportere hendelser, er en dedikert tjeneste som regel verdt pengene. Mange har gratis eller rimelige nivåer for små team, så sjekk før du bygger selv.

Bygg selv når du vil ha full kontroll over design og formuleringer, når behovene dine er enkle (noen få komponenter, manuelle oppdateringer), eller når statussiden er en del av et produkt du bygger for andre.

Bygge det med Mythex

På Mythex kan du bygge statussiden som et eget prosjekt, separat fra hovedappen, som gir egen hosting og egen database. Beskriv den i chatten, sjekk den i forhåndsvisningen, publiser den og koble til et subdomene som status.dittdomene.no (egne domener er i Pro). Husk at publiserte Mythex-apper og databasene deres går i dvale når de er inaktive og våkner ved neste besøk, så den første innlastingen etter en rolig periode kan gå litt saktere. En enkel, lett side hjelper.

Mythex dokumenterer ikke planlagte jobber, så bruk en ekstern oppetidsovervåker som kaller et webhook-endepunkt i statussiden din (se webhook-oppskriften) for automatiske sjekker. E-postvarsler til abonnenter går gjennom din egen leverandør, med nøkkelen lagret som en prosjekthemmelighet (oppskriften for å sende e-post).

Spørsmål