Kako narediti statusno stran: komponente, incidenti in preverjanja delovanja

Statusna stran uporabnikom na enem mestu pove, ali vaša storitev deluje. Za njeno izdelavo potrebujete seznam komponent (spletna stran, API, plačila, e-pošta), trenutno stanje za vsako, incidente s časovno označenimi posodobitvami, zgodovino preteklih incidentov in po želji naročnine, da ljudje izvejo za težave, ne da bi morali preverjati. Sama stran je preprosta. Pomembna odločitev je, kje teče: statusna stran mora delovati tudi takrat, ko je vaša aplikacija nedosegljiva, zato ne sme deliti gostovanja, podatkovne baze ali cevovoda za objavo s stvarjo, o kateri poroča.

Čemu služi statusna stran

Ko nekaj odpove, uporabniki želijo vedeti tri stvari: ali gre samo zame, ali se zavedate težave in kdaj bo odpravljena. Statusna stran na vsa tri vprašanja odgovori brez poplave podpornih zahtevkov. Sčasoma tudi gradi zaupanje, saj vidna zgodovina incidentov s poštenimi opisi pokaže, kako ravnate s težavami.

Ni dnevnik sprememb. Nove funkcije sodijo na stran z dnevnikom sprememb; izpadi in vzdrževanje pa sodijo sem.

Kaj potrebuje stran

Podatki

Stanja komponent so običajno kratek nespremenljiv seznam: deluje, poslabšana zmogljivost, delni izpad, velik izpad, v vzdrževanju.

Strani

• Javna statusna stran: splošni pas ("vsi sistemi delujejo" ali najslabše trenutno stanje), vsaka komponenta s stanjem, vsak aktivni incident z njegovimi posodobitvami, prihajajoče vzdrževanje in po potrebi 90-dnevna vrstica zgodovine, če imate podatke o preverjanjih.
• Stran incidenta: celoten časovni potek posodobitev za en incident z lastnim naslovom, da ga lahko podpora pošlje naprej.
• Zgodovina: pretekli incidenti po mesecih.
• Naročnina: prijava z e-pošto s potrditvijo in nastavitvami obvestil za posamezne komponente.
• Skrbniški del: ustvarjanje incidenta, objava posodobitev, spreminjanje stanj komponent, načrtovanje vzdrževanja.

Dovoljenja

Javnost vidi vse objavljeno. Objavlja lahko samo vaša ekipa. Če je mogoče, ohranite prijavo v skrbniški del ločeno od prijavnega sistema glavne aplikacije, da vas izpad ponudnika prijave ne zaklene iz lastne statusne strani.

Ključna odločitev: ohranite neodvisnost

Tu večina domačih statusnih strani odpove. Če vaša statusna stran:

• teče na istem strežniku ali v istem računu gostovanja kot vaša aplikacija,
• bere iz iste podatkovne baze,
• stoji za isto nastavitvijo domene ali CDN,
• ali jo objavlja isti cevovod,

jo bo mnogo izpadov prav tako ugnalo, ravno takrat, ko jo ljudje potrebujejo. Praktični koraki:

• Ločeno gostovanje. Drugačen projekt ali ponudnik kot pri glavni aplikaciji.
• Lastna poddomena, na primer status.primer.si, ločeno usmerjena v DNS. Glejte kako delujeta domena in DNS.
• Lastni podatki. Incidenti so v lastni shrambi statusne strani, ne v bazi vaše aplikacije.
• Statični rezervni način. Nekatere ekipe javno stran naredijo statično in jo ob vsaki posodobitvi ponovno zgradijo, tako da skorajda ni kaj, kar bi se lahko pokvarilo.

Ročne posodobitve ali samodejna preverjanja

Ročno (tu začnite)

Vaša ekipa incidente objavlja in stanja komponent spreminja ročno iz skrbniške strani. Tako v praksi deluje veliko statusnih strani, saj je človeška presoja ("plačila so počasna za nekatere vrste kartic") koristnejša kot samodejna rdeča pika.

Da o težavah izveste hitro, uporabite zunanji nadzornik delovanja, ki vašo aplikacijo preverja vsako minuto ali približno tako in vas opozori po e-pošti, SMS-u ali klepetu. Mnoge storitve za spremljanje imajo brezplačne pakete.

Samodejno

Samodejnost pomeni, da nekaj redno preverja vsako komponento in posodablja njeno stanje. To zahteva kodo, ki teče po urniku, zunaj infrastrukture glavne aplikacije. Dva pogosta vzorca:

• Zunanji nadzornik pokliče vašo statusno stran prek webhooka, ko preverjanje ne uspe ali se povrne, statusna stran pa posodobi komponento.
• Načrtovano opravilo v gostovanju statusne strani vsako komponento preveri in rezultat zabeleži. Preden se na to zanesete, preverite, kako vaše gostovanje obravnava načrtovana opravila; naš vodnik o zagonu opravil v ozadju razloži možnosti.

Samodejne spremembe lahko na počasnem omrežju nihajo (gor, dol, gor). Preden se stanje spremeni, zahtevajte dve ali tri neuspešna preverjanja, pri večjem izpadu pa naj spremembo potrdi človek.

Pisanje posodobitev incidentov

• Objavite zgodaj. "Preiskujemo poročila o neuspešnih prijavah" v nekaj minutah je boljše kot popolno sporočilo čez uro.
• Povejte, kaj uporabniki opazijo, ne kaj je znotraj narobe.
• Obljubite čas naslednje posodobitve in se ga držite.
• Ob reševanju zaključite s kratkim povzetkom: kaj se je zgodilo, koliko časa je trajalo in kaj spreminjate.

Prvi poziv, ki deluje

Naredi samostojno statusno stran za našo aplikacijo Parcelio, gostovano ločeno na status.parcelio.com. Komponente: Spletna stran, API za sledenje, Obvestila, Plačila; vsaka ima stanje Deluje, Poslabšana zmogljivost, Delni izpad, Velik izpad ali V vzdrževanju. Javna stran prikaže splošni pas po najslabšem trenutnem stanju, vsako komponento s stanjem, aktivne incidente s časovno označenimi posodobitvami od najnovejše, prihajajoče vzdrževanje in seznam preteklih incidentov po mesecih. Vsak incident ima svojo stran. Dodaj skrbniško stran, zaščiteno z geslom, za ustvarjanje incidentov (naslov, vpliv, prizadete komponente), objavo posodobitev (sporočilo in stanje: Preiskujemo, Določeno, Spremljamo, Rešeno), spreminjanje stanj komponent in načrtovanje vzdrževanja. Dodaj končno točko POST /api/check-result, ki sprejme ime komponente in gor/dol iz zunanjega nadzornika, zaščiteno s skrivnim žetonom, ter komponento označi kot poslabšano šele po treh zaporednih neuspehih. Vse shrani v lastno podatkovno bazo te aplikacije. Preprosta, mirna zasnova, ki se hitro naloži na telefonih.

Koraki gradnje

1. Javna stran in skrbniški del z ročnimi incidenti. To samo po sebi že je delujoča statusna stran.
2. Gostite jo ločeno in usmerite poddomeno nanjo.
3. Strani incidentov in zgodovina.
4. Časovna okna vzdrževanja.
5. Naročnine. Prijava z e-pošto z dvojno potrditvijo ter obvestila o novih incidentih in posodobitvah. E-pošta potrebuje ponudnika; glejte kako pošiljati e-pošto iz aplikacije.
6. Webhook nadzornika, če želite samodejne spremembe stanja.
7. Preizkusna vaja. Ustvarite lažni incident, objavite posodobitve, ga zaprite, preverite e-pošto in nato incident izbrišite.

Pogoste napake

• Gostovanje skupaj z aplikacijo. Najpogostejša in najresnejša napaka.
• Stran, ki vedno pravi "vsi sistemi delujejo". Če nikoli ne pokaže težav, ji uporabniki nehajo zaupati.
• Brez časovnih oznak ali časovnega pasu. Čas vedno prikažite s časovnim pasom.
• Prijava v glavno aplikacijo za skrbniško stran.
• Tišina med posodobitvami. „Brez sprememb, še vedno delamo na tem“ je veljavna posodobitev.
• Nihajoča samodejna stanja. Pred spremembo zahtevajte ponovljene neuspehe.

Kdaj je boljša gotova storitev statusnih strani

Storitve gotovih statusnih strani so zgrajene okoli problema neodvisnosti: delujejo na ločeni infrastrukturi, obvestila naročnikom pošiljajo po e-pošti in SMS-u ter pogosto vključujejo spremljanje in povezave z orodji za incidente. Če je zanesljivost del tega, za kar stranke plačujejo, ali imate pogodbene obveznosti glede poročanja o incidentih, je namenska storitev običajno vredna svoje cene. Mnoge imajo brezplačne ali poceni pakete za majhne ekipe, zato jih preverite, preden začnete graditi.

Svojo rešitev naredite, kadar želite popoln nadzor nad zasnovo in besedili, kadar so vaše potrebe preproste (peščica komponent, ročne posodobitve) ali kadar je statusna stran del izdelka, ki ga gradite za druge.

Gradnja s Mythexom

V Mythexu lahko statusno stran zgradite kot lasten projekt, ločen od glavne aplikacije, s tem pa dobite ločeno gostovanje in lastno podatkovno bazo. Opišite jo v klepetu, preverite v živem predogledu, nato jo objavite in povežite poddomeno, na primer status.vasadomena.si (domene po meri so na voljo v paketu Pro). Upoštevajte, da objavljene aplikacije in njihove podatkovne baze v Mythexu med mirovanjem zaspijo in se zbudijo ob naslednjem obisku, zato je prvo nalaganje po tihem obdobju lahko počasnejše; preprosta, lahka stran to ublaži.

Mythex pošiljanja po urniku ne dokumentira, zato za samodejna preverjanja uporabite zunanji nadzornik delovanja, ki kliče končno točko webhooka na vaši statusni strani (glejte recept za webhooke). Opozorila naročnikom gredo prek vašega lastnega ponudnika, ključ pa je shranjen kot skrivnost projekta (recept za pošiljanje e-pošte).

Vprašanja