Kako napraviti stranicu statusa: komponente, incidenti i provere dostupnosti

Stranica statusa na jednom mestu pokazuje korisnicima da li vaša usluga radi. Da biste je napravili, potrebna vam je lista komponenti (sajt, API, plaćanja, slanje e-pošte), trenutni status svake, incidenti sa vremenski obeleženim ažuriranjima, istorija prošlih incidenata i, opciono, pretplate kako bi ljudi saznali za probleme bez stalnog proveravanja. Sama stranica je jednostavna. Važna odluka je gde će raditi: stranica statusa mora da ostane dostupna kad vaša aplikacija ne radi, pa ne bi smela da deli hosting, bazu podataka ni proces isporuke sa stvarima o kojima izveštava.

Čemu služi stranica statusa

Kada nešto pukne, korisnicima su važne tri stvari: da li je problem samo kod njih, da li ste svesni problema i kada će biti rešen. Stranica statusa odgovara na sve tri bez gomile upita podršci. Takođe gradi poverenje tokom vremena, jer vidljiva istorija incidenata sa iskrenim opisima pokazuje kako rešavate probleme.

Nije to dnevnik izmena. Nove funkcije idu na stranicu sa izmenama, a ispadi i održavanje ovde.

Šta stranica treba da ima

Podaci

Statusi komponenti su obično kratka fiksna lista: Radi, Smanjene performanse, Delimičan ispad, Veliki ispad, Održavanje.

Stranice

• Javna stranica statusa: opšti baner („Svi sistemi rade” ili najgori trenutni status), svaka komponenta sa statusom, aktivni incident sa ažuriranjima, najavljeno održavanje i traka istorije za poslednjih 90 dana ako imate podatke iz provera.
• Stranica incidenta: kompletna vremenska linija ažuriranja za jedan incident, sa sopstvenom adresom da podrška može da ga pošalje.
• Istorija: prošli incidenti po mesecima.
• Pretplata: prijava e-poštom sa potvrdom i podešavanjem po komponentama.
• Administracija: kreiranje incidenta, objava ažuriranja, promena statusa komponenti, zakazivanje održavanja.

Dozvole

Javnost vidi sve što je objavljeno. Samo vaš tim može da objavljuje. Ako možete, držite prijavu za administraciju odvojeno od sistema prijave vaše glavne aplikacije, da ispad vašeg provajdera za autentifikaciju ne bi zaključao i vas iz sopstvene stranice statusa.

Ključna odluka: neka bude nezavisna

Tu većina samostalno napravljenih stranica statusa pada. Ako vaša stranica statusa:

• radi na istom serveru ili hosting nalogu kao aplikacija,
• čita iz iste baze podataka,
• stoji iza istog podešavanja domena ili CDN-a,
• ili se isporučuje istim procesom,

onda će je mnogi ispadi srušiti takođe, upravo kad je ljudima najpotrebnija. Praktični koraci:

• Odvojen hosting. Drugi projekat ili provajder nego glavna aplikacija.
• Sopstveni poddomen, kao što je status.primer.com, usmeren posebno u DNS-u. Pogledajte kako rade domeni i DNS.
• Sopstveni podaci. Incidenti žive u sopstvenom skladištu stranice statusa, a ne u bazi vaše aplikacije.
• Statički rezervni plan. Neki timovi naprave javnu stranicu kao statičku i ponovo je generišu pri svakom ažuriranju, pa skoro ništa ne može da pukne.

Ručna ili automatska provera

Ručno (počnite ovde)

Vaš tim objavljuje incidente i menja statuse komponenti ručno, iz administracije. Tako većina stranica statusa zapravo radi, jer ljudska procena („plaćanja su spora za neke vrste kartica”) korisnija je od automatske crvene tačke.

Da biste brzo saznali za probleme, koristite spoljni monitor dostupnosti koji proverava aplikaciju svakih minut-dva i šalje upozorenje e-poštom, SMS-om ili u četu. Mnoge usluge za praćenje imaju besplatne planove.

Automatski

Automatizacija znači da nešto redovno proverava svaku komponentu i ažurira njen status. Za to je potreban kod koji radi po rasporedu, spolja u odnosu na infrastrukturu vaše glavne aplikacije. Dva uobičajena obrasca:

• Spoljni monitor poziva vašu stranicu statusa preko webhook-a kada provera ne uspe ili se vrati, a stranica statusa ažurira komponentu.
• Zakazani posao u hostingu stranice statusa proverava svaku komponentu i beleži rezultat. Pre oslanjanja na to proverite kako vaš hosting radi sa zakazanim zadacima. Naš vodič o pokretanju pozadinskih poslova objašnjava opcije.

Automatske promene mogu da titraju (gore, dole, gore) na sporoj mreži. Zahtevajte dva ili tri neuspešna pokušaja pre promene statusa i neka čovek potvrdi pre objave većeg ispada.

Pisanje ažuriranja o incidentu

• Objavite rano. „Istražujemo prijave o neuspešnim prijavama” za nekoliko minuta bolje je od savršene poruke sat kasnije.
• Recite šta korisnici primećuju, a ne šta je interno pokvareno.
• Obećajte vreme sledećeg ažuriranja i ispoštujte ga.
• Zatvorite kratkim sažetkom kad se reši: šta se desilo, koliko je trajalo i šta menjate.

Prvi prompt koji radi

Napravi samostalnu stranicu statusa za našu aplikaciju Parcelio, hostovanu odvojeno na status.parcelio.com. Komponente: Sajt, API za praćenje, Obaveštenja, Plaćanja, svaka sa statusom Radi, Smanjene performanse, Delimičan ispad, Veliki ispad ili Održavanje. Javna stranica prikazuje opšti baner prema najgorem trenutnom statusu, svaku komponentu sa statusom, aktivne incidente sa vremenski obeleženim ažuriranjima, najnovije prvo, najavljeno održavanje i listu prošlih incidenata po mesecima. Svaki incident ima sopstvenu stranicu. Dodaj stranicu za administraciju zaštićenu lozinkom za kreiranje incidenata (naslov, uticaj, pogođene komponente), objavu ažuriranja (poruka i status: Istražujemo, Identifikovano, Praćenje, Rešeno), promenu statusa komponenti i zakazivanje održavanja. Dodaj krajnju tačku POST /api/check-result koja prima naziv komponente i stanje gore/dole od spoljnog monitora, zaštićenu tajnim tokenom, i označava komponentu kao Smanjene performanse tek posle tri uzastopna pada. Sve čuvaj u sopstvenoj bazi podataka ove aplikacije. Jednostavan, miran dizajn koji se brzo učitava na telefonima.

Koraci izgradnje

1. Javna stranica i administracija sa ručnim incidentima. Ovo je već radna stranica statusa.
2. Hostujte je odvojeno i usmerite poddomen na nju.
3. Stranice incidenata i istorija.
4. Periodi održavanja.
5. Pretplate. Prijava e-poštom sa dvostrukom potvrdom i obaveštenja o novim incidentima i ažuriranjima. Za e-poštu je potreban provajder; pogledajte kako slati e-poštu iz aplikacije.
6. Webhook monitora ako želite automatske promene statusa.
7. Probna vežba. Napravite lažni incident, objavite ažuriranja, rešite ga, proverite e-poruke, pa ga obrišite.

Česte greške

• Hostovanje zajedno sa aplikacijom. Najčešća i najozbiljnija greška.
• Stranica koja uvek kaže „Svi sistemi rade”. Ako nikad ne pokazuje probleme, korisnici prestaju da joj veruju.
• Nema vremena ili vremenske zone. Uvek prikazujte vreme sa zonom.
• Oslanjanje na prijavu glavne aplikacije za stranicu za administraciju.
• Tišina između ažuriranja. „Nema promena, i dalje radimo na tome” je validno ažuriranje.
• Titrajući automatski statusi. Zahtevajte ponovljene neuspehe pre promene.

Kada je bolja hostovana usluga stranice statusa

Hostovane usluge stranica statusa napravljene su upravo zbog problema nezavisnosti: rade na odvojenoj infrastrukturi, šalju obaveštenja pretplatnicima e-poštom i SMS-om, a često uključuju praćenje i integracije sa alatima za upravljanje incidentima. Ako dostupnost ulazi u ono što kupci plaćaju ili imate ugovorne obaveze da prijavljujete incidente, namenska usluga je obično vredna cene. Mnoge imaju besplatne ili jeftine planove za male timove, pa proverite pre nego što počnete da gradite.

Gradite sopstvenu kad želite punu kontrolu nad dizajnom i formulacijama, kad su vam potrebe jednostavne (nekoliko komponenti, ručna ažuriranja) ili kad je stranica statusa deo proizvoda koji pravite za druge.

Izgradnja uz Mythex

Na Mythex-u stranicu statusa možete napraviti kao sopstveni projekat, odvojen od glavne aplikacije, što joj daje odvojen hosting i sopstvenu bazu podataka. Opišite je u četu, proverite u živom pregledu, zatim je objavite i povežite poddomen kao što je status.vasdomen.com (prilagođeni domeni su u planu Pro). Imajte na umu da se objavljene Mythex aplikacije i njihove baze podataka uspavaju kad su neaktivne i bude se pri sledećoj poseti, pa prvo učitavanje posle mirnog perioda može biti sporije. Jednostavna, laka stranica pomaže.

Mythex ne dokumentuje zakazane poslove, pa za automatske provere koristite spoljni monitor dostupnosti koji poziva webhook krajnju tačku vaše stranice statusa (pogledajte recept za webhook-ove). Obaveštenja pretplatnicima šalju se preko vašeg sopstvenog provajdera, sa ključem sačuvanim kao tajna projekta (recept za slanje e-pošte).

Pitanja