Kā izveidot statusa lapu: komponenti, incidenti un darbības pārbaudes

Statusa lapa vienuviet informē lietotājus, vai jūsu pakalpojums darbojas. Lai to izveidotu, jums vajag komponentu sarakstu (tīmekļa vietne, API, maksājumi, e-pasta piegāde), katra komponenta pašreizējo statusu, incidentus ar laika zīmogotiem atjauninājumiem, iepriekšējo incidentu vēsturi un, ja vēlaties, abonēšanu, lai cilvēki par problēmām uzzinātu, nepārbaudot lapu paši. Pati lapa ir vienkārša. Svarīgākais lēmums ir tas, kur tā darbojas: statusa lapai jāpaliek pieejamai, kad lietotne nedarbojas, tāpēc tai nevajadzētu dalīties ar to pašu mitināšanu, datubāzi vai izvietošanas procesu, kuru tā atspoguļo.

Kam paredzēta statusa lapa

Kad kaut kas noiet greizi, lietotājiem vajadzīgas trīs atbildes: vai problēma ir tikai man, vai jūs par to zināt un kad to novērsīs. Statusa lapa atbild uz visiem trim jautājumiem bez atbalsta biļešu plūsmas. Tā arī laika gaitā veido uzticību, jo redzama incidentu vēsture ar godīgiem aprakstiem parāda, kā rīkojaties ar problēmām.

Tā nav izmaiņu vēsture. Jaunas funkcijas ieliek izmaiņu lapā; traucējumus un apkopi – šeit.

Ko lapai vajag

Dati

Komponentu statusi parasti ir īss fiksēts saraksts: Darbojas, Pasliktināta veiktspēja, Daļējs traucējums, Liels traucējums, Apkopē.

Lapas

• Publiskā statusa lapa: vispārējs baneris („Visas sistēmas darbojas” vai sliktākais pašreizējais statuss), katrs komponents ar statusu, aktīvs incidents ar atjauninājumiem, tuvākā apkope un 90 dienu vēstures josla, ja ir pārbaužu dati.
• Incidenta lapa: pilna atjauninājumu hronoloģija vienam incidentam ar savu URL, lai atbalsta komanda to var nosūtīt.
• Vēsture: pagātnes incidenti pa mēnešiem.
• Abonēšana: e-pasta reģistrācija ar apstiprinājumu un iestatījumiem katram komponentam.
• Administrēšana: izveidot incidentu, publicēt atjauninājumus, mainīt komponentu statusus, plānot apkopi.

Piekļuve

Sabiedrība redz visu, kas publicēts. Publicēt var tikai jūsu komanda. Ja iespējams, turiet administratora pieteikšanos atsevišķi no lietotnes pieteikšanās sistēmas, lai autentifikācijas pakalpojumu traucējums neizslēgtu jūs no pašu statusa lapas.

Galvenais lēmums: turiet to neatkarīgu

Tieši šeit visbiežāk neizdodas pašu veidotas statusa lapas. Ja jūsu statusa lapa:

• darbojas uz tā paša servera vai mitināšanas konta kā lietotne,
• nolasa datus no tās pašas datubāzes,
• atrodas aiz tiem pašiem domēna iestatījumiem vai CDN konfigurācijas,
• vai to izvieto tas pats izvietošanas process,

tad daudzi traucējumi to izslēgs arī, tieši tad, kad cilvēkiem tā vajadzīga. Praktiski soļi:

• Atsevišķa mitināšana. Cits projekts vai pakalpojumu sniedzējs nekā galvenajai lietotnei.
• Savs apakšdomēns, piemēram, status.example.com, DNS iestatīts atsevišķi. Skatiet kā darbojas domēni un DNS.
• Savi dati. Incidenti glabājas statusa lapas pašas krātuvē, nevis jūsu lietotnes datubāzē.
• Statiska rezerves versija. Daudzas komandas publisko lapu veido kā statisku failu un to pārbūvē pie katra atjauninājuma, tāpēc gandrīz nekas nevar salūzt.

Atjauninājumi ar roku vai automātiskas pārbaudes

Ar roku (sāciet šeit)

Jūsu komanda incidentus publicē un komponentu statusus maina ar roku administrēšanas lapā. Tā daudzas statusa lapas darbojas praksē, jo cilvēka spriedums („maksājumi kartēm dažkārt ir lēni”) ir noderīgāks par automātisku sarkanu punktu.

Lai ātri uzzinātu par problēmām, izmantojiet ārēju darbības uzraudzības rīku, kas pārbauda jūsu lietotni ik minūti vai apmēram tik bieži un brīdina pa e-pastu, SMS vai tērzēšanas kanālu. Daudziem uzraudzības pakalpojumiem ir bezmaksas plāni.

Automātiski

Automatizācija nozīmē, ka kaut kas regulāri pārbauda katru komponentu un atjaunina tā statusu. Tam vajag kodu, kas darbojas pēc grafika, ārpus jūsu galvenās lietotnes infrastruktūras. Divi bieži sastopami veidi:

• Ārējs uzraugs izsauc jūsu statusa lapu caur webhook, kad pārbaude neizdodas vai atgriežas, un statusa lapa atjaunina komponentu.
• Ieplānots darbs statusa lapas pašas mitināšanā pārbauda katru komponentu un saglabā rezultātu. Pirms paļaušanās uz to pārbaudiet, kā jūsu mitināšana apstrādā ieplānotus uzdevumus; mūsu ceļvedis par fona darbu palaišanu izskaidro iespējas.

Automātiskas izmaiņas var svārstīties (augšā, lejā, augšā) lēnā tīklā. Pirms statusa maiņas pieprasiet divas vai trīs neizdevušās pārbaudes, un lielu traucējumu paziņo tikai pēc cilvēka apstiprinājuma.

Kā rakstīt incidentu atjauninājumus

• Publicējiet agri. „Izmeklējam ziņojumus par neizdevušām pieteikšanām” pāris minūtēs ir labāk nekā ideāls ziņojums stundu vēlāk.
• Pastāstiet, ko lietotāji pamana, nevis ko iekšēji salauzāt.
• Apsoliet nākamā atjauninājuma laiku un turiet to.
• Noslēdziet ar īsu kopsavilkumu, kad problēma atrisināta: kas notika, cik ilgi un ko mainīsiet.

Pirmais uzvedne, kas strādā

Izveido patstāvīgu statusa lapu mūsu lietotnei Parcelio, mitinātu atsevišķi adresē status.parcelio.com. Komponenti: Tīmekļa vietne, Izsekošanas API, Paziņojumi, Maksājumi; katram statuss Darbojas, Pasliktināta veiktspēja, Daļējs traucējums, Liels traucējums vai Apkopē. Publiskā lapa rāda vispārēju banneri, izmantojot sliktāko pašreizējo statusu, katru komponentu ar statusu, aktīvos incidentus ar laika zīmogotiem atjauninājumiem jaunākie augšā, tuvāko apkopi un pagātnes incidentu sarakstu pa mēnešiem. Katram incidentam ir sava lapa. Pievienojiet ar paroli aizsargātu administrēšanas lapu incidentu izveidei (nosaukums, ietekme, ietekmētie komponenti), atjauninājumu publicēšanai (ziņojums un statuss: Izmeklē, Identificēts, Uzrauga, Atrisināts), komponentu statusu maiņai un apkopes plānošanai. Pievienojiet POST /api/check-result galapunktu, kas pieņem komponenta nosaukumu un uz/uz leju no ārēja uzraudzības rīka, aizsargātu ar slepenu pilnvaru, un atzīmē komponentu kā Pasliktinātu tikai pēc trim pēc kārtas neizdevušām pārbaudēm. Glabājiet visu šīs lietotnes pašas datubāzē. Vienkāršs, mierīgs dizains, kas ātri ielādējas telefonos.

Būvēšanas soļi

1. Publiskā lapa un administrēšana ar manuāliem incidentiem. Tas jau ir darbojoša statusa lapa.
2. Mitiniet to atsevišķi un norādiet apakšdomēnu uz to.
3. Incidentu lapas un vēsture.
4. Apkopes logi.
5. Abonēšana. E-pasta reģistrācija ar divkāršu apstiprinājumu un paziņojumi par jauniem incidentiem un atjauninājumiem. E-pastam vajag pakalpojumu sniedzēju; skatiet kā sūtīt e-pastus no lietotnes.
6. Uzraudzības webhook, ja vēlaties automātiskas statusa izmaiņas.
7. Veiciet mēģinājumu. Izveidojiet fiktīvu incidentu, publicējiet atjauninājumus, atrisiniet to, pārbaudiet e-pastus un pēc tam izdzēsiet.

Biežākās kļūdas

• Mitināšana kopā ar lietotni. Visbiežākā un vissmagākā kļūda.
• Lapa, kas vienmēr saka „Visas sistēmas darbojas”. Ja tā nekad neparāda problēmas, lietotāji tai pārtrauc uzticēties.
• Nav laika zīmogu vai laika joslas. Vienmēr rādiet laiku ar joslu.
• Paļaušanās uz galvenās lietotnes pieteikšanos administrēšanas lapai.
• Klusums starp atjauninājumiem. „Nav izmaiņu, joprojām strādājam” ir derīgs atjauninājums.
• Svārstīgas automātiskas izmaiņas. Pirms izmaiņas vajag atkārtotas neveiksmes.

Kad labāka izvēle ir hostēts statusa lapas pakalpojums

Hostētie statusa lapu pakalpojumi ir veidoti tieši neatkarības problēmai: tie darbojas atsevišķā infrastruktūrā, apstrādā abonentu paziņojumus pa e-pastu un SMS un bieži ietver uzraudzību un integrācijas ar incidentu rīkiem. Ja darbspēja ir daļa no tā, ko klienti maksā, vai jums ir līgumsaistības ziņot par incidentiem, specializēts pakalpojums parasti ir tā vērts. Daudziem ir bezmaksas vai lēti plāni mazām komandām, tāpēc pirms būvēšanas pārbaudiet.

Veidojiet pats, ja vēlaties pilnu kontroli pār dizainu un formulējumu, ja jūsu vajadzības ir vienkāršas (dažas komponentes, manuāli atjauninājumi) vai ja statusa lapa ir daļa no produkta, ko veidojat citiem.

Būvēšana ar Mythex

Mythex ietvaros statusa lapu varat veidot kā atsevišķu projektu, nodalītu no galvenās lietotnes, kas nodrošina atsevišķu mitināšanu un savu datubāzi. Aprakstiet to tērzēšanā, pārbaudiet tiešraides priekšskatījumā, pēc tam publicējiet un pieslēdziet apakšdomēnu, piemēram, status.jusudomens.lv (pielāgotie domēni ir Pro plānā). Ņemiet vērā, ka publicētas Mythex lietotnes un to datubāzes miegā, kad nav aktīvas, un pamostas nākamajā apmeklējumā, tāpēc pirmā ielāde pēc klusa laika var būt lēnāka; vienkārša, viegla lapa to palīdz mazināt.

Mythex nedokumentē ieplānotus darbus, tāpēc automātiskām pārbaudēm izmantojiet ārēju darbības uzraudzības rīku, kas izsauc webhook galapunktu jūsu statusa lapā (skatiet webhook receptes). Paziņojumus abonentiem pa e-pastu sūtiet caur savu pakalpojumu sniedzēju, ar atslēgu, kas glabājas projekta noslēpumos (e-pasta sūtīšanas recepte).

Jautājumi