Cum construiești o pagină de status: componente, incidente și verificări de disponibilitate

O pagină de status le arată utilizatorilor, într-un singur loc, dacă serviciul tău funcționează. Ca să construiești una, ai nevoie de o listă de componente (site-ul web, API-ul, plățile, livrarea e-mailurilor), de un status curent pentru fiecare, de incidente cu actualizări datate, de un istoric al incidentelor trecute și, opțional, de abonări, ca oamenii să afle despre probleme fără să verifice singuri. Pagina în sine este simplă. Decizia importantă este unde rulează: o pagină de status trebuie să rămână online când aplicația ta este căzută, deci nu ar trebui să împartă găzduirea, baza de date sau pipeline-ul de deploy cu lucrul despre care raportează.

La ce servește o pagină de status

Când ceva se strică, utilizatorii vor să afle trei lucruri: sunt doar eu afectat, știți voi despre problemă și când va fi rezolvată. O pagină de status răspunde la toate trei fără să primești un val de tichete de suport. Ea și construiește încredere în timp, pentru că un istoric vizibil al incidentelor, cu descrieri oneste, arată cum tratezi problemele.

Nu este un jurnal de modificări. Funcționalitățile noi merg pe o pagină de changelog; pene și lucrări programate merg aici.

Ce are nevoie pagina

Date

Statusurile componentelor sunt de obicei o listă scurtă și fixă: Operațional, Performanță degradată, Pană parțială, Pană majoră, În mentenanță.

Pagini

• Pagina publică de status: un banner general („Toate sistemele funcționează” sau cel mai grav status curent), fiecare componentă cu statusul ei, orice incident activ cu actualizările lui, mentenanța programată și o bandă cu istoricul ultimelor 90 de zile, dacă ai date de verificare.
• Pagina de incident: cronologia completă a actualizărilor pentru un singur incident, cu propriul URL, ca echipa de suport să-l poată trimite.
• Istoric: incidentele trecute, pe luni.
• Abonare: înscriere prin e-mail cu confirmare și preferințe pe componente.
• Administrare: creezi un incident, publici actualizări, schimbi statusul componentelor, programezi mentenanța.

Permisiuni

Publicul vede tot ce este publicat. Doar echipa ta poate publica. Dacă poți, păstrează autentificarea pentru administrare separată de sistemul de login al aplicației principale, ca o pană la furnizorul tău de autentificare să nu te blocheze afară din propria pagină de status.

Decizia cheie: ține-o independentă

Aici cad de obicei paginile de status făcute acasă. Dacă pagina ta de status:

• rulează pe același server sau în același cont de găzduire ca aplicația,
• citește din aceeași bază de date,
• stă în spatele aceleiași configurații de domeniu sau CDN,
• sau este publicată de același pipeline,

atunci multe pene o vor doborî și pe ea, exact când oamenii au nevoie de ea. Pași practici:

• Găzduire separată. Un proiect sau un furnizor diferit de aplicația principală.
• Propriul subdomeniu, de exemplu status.exemplu.com, indicat separat în DNS. Vezi cum funcționează domeniile și DNS-ul.
• Datele proprii. Incidentele trăiesc în spațiul de stocare al paginii de status, nu în baza de date a aplicației.
• O variantă statică de rezervă. Unele echipe fac pagina publică statică și o reconstruiesc la fiecare actualizare, deci aproape nimic nu se poate strica.

Actualizări manuale sau verificări automate

Manual (aici începi)

Echipa ta publică incidentele și schimbă manual statusul componentelor din pagina de administrare. Așa funcționează multe pagini de status în practică, pentru că o judecată umană („plățile sunt lente pentru unele tipuri de carduri”) este mai utilă decât un punct roșu automat.

Ca să afli repede de probleme, folosește un monitor extern de disponibilitate care verifică aplicația la un minut sau două și te alertează prin e-mail, SMS sau chat. Multe servicii de monitorizare au planuri gratuite.

Automat

Automatizarea înseamnă că ceva verifică periodic fiecare componentă și îi actualizează statusul. Asta cere cod care rulează programat, din afara infrastructurii principale a aplicației. Două modele frecvente:

• Un monitor extern apelează pagina de status printr-un webhook când o verificare eșuează sau își revine, iar pagina de status actualizează componenta.
• Un job programat în găzduirea paginii de status pingează fiecare componentă și salvează rezultatul. Verifică ce oferă găzduirea ta pentru sarcini programate înainte să te bazezi pe asta; ghidul nostru despre rularea joburilor în fundal explică opțiunile.

Schimbările automate pot oscila (sus, jos, sus) pe o conexiune lentă. Cere două sau trei verificări eșuate înainte să schimbi un status și lasă un om să confirme înainte să anunți o pană majoră.

Cum scrii actualizările despre incidente

• Publică devreme. „Investigăm raportările despre autentificări eșuate” în câteva minute bate un mesaj perfect o oră mai târziu.
• Spune ce observă utilizatorii, nu ce s-a stricat intern.
• Anunță ora următoarei actualizări și respect-o.
• Încheie cu un rezumat scurt după rezolvare: ce s-a întâmplat, cât a durat, ce schimbi.

Un prompt de start care funcționează

Construiește o pagină de status independentă pentru aplicația noastră Parcelio, găzduită separat la status.parcelio.com. Componente: Site-ul web, API-ul de urmărire, Notificări, Plăți, fiecare cu statusul Operațional, Performanță degradată, Pană parțială, Pană majoră sau În mentenanță. Pagina publică afișează un banner general cu cel mai grav status curent, fiecare componentă cu statusul ei, incidentele active cu actualizări datate, cele mai noi primele, mentenanța viitoare și o listă a incidentelor trecute pe luni. Fiecare incident are propria pagină. Adaugă o pagină de administrare protejată cu parolă pentru a crea incidente (titlu, impact, componente afectate), a publica actualizări (mesaj și status: Investigating, Identified, Monitoring, Resolved), a schimba statusul componentelor și a programa mentenanța. Adaugă un endpoint POST /api/check-result care primește de la un monitor extern numele unei componente și up/down, protejat printr-un token secret, și marchează o componentă ca Degradată doar după trei eșecuri consecutive. Stochează totul în propria bază de date a acestei aplicații. Design simplu și calm, care se încarcă repede pe telefon.

Pași de construire

1. Pagina publică și administrarea cu incidente manuale. Asta singură este deja o pagină de status funcțională.
2. Găzduiește-o separat și indică un subdomeniu spre ea.
3. Paginile de incident și istoricul.
4. Ferestrele de mentenanță.
5. Abonările. Înscriere prin e-mail cu confirmare dublă și notificări la incidente noi și actualizări. E-mailul cere un furnizor; vezi cum trimiți e-mailuri din aplicația ta.
6. Webhook de monitorizare, dacă vrei schimbări automate de status.
7. Fă un exercițiu. Creează un incident fictiv, publică actualizări, rezolvă-l, verifică e-mailurile, apoi șterge-l.

Greșeli frecvente

• Găzduirea împreună cu aplicația. Cea mai comună și cea mai gravă greșeală.
• O pagină care spune mereu „Toate sistemele funcționează”. Dacă nu arată niciodată probleme, utilizatorii încetează să mai aibă încredere în ea.
• Fără ore sau fus orar. Afișează mereu orele cu fusul orar.
• Să te bazezi pe login-ul aplicației principale pentru pagina de administrare.
• Tăcere între actualizări. „Fără schimbări, lucrăm în continuare” este o actualizare validă.
• Statusuri automate care oscilează. Cere eșecuri repetate înainte de o schimbare.

Când un serviciu gata făcut de pagini de status este varianta mai bună

Serviciile dedicate de pagini de status sunt construite pe ideea independenței: rulează pe o infrastructură separată, trimit notificările abonaților prin e-mail și SMS, iar de multe ori includ monitorizare și integrări cu instrumentele de gestionare a incidentelor. Dacă disponibilitatea face parte din ce plătesc clienții tăi sau ai obligații contractuale de a raporta incidentele, un serviciu dedicat merită de obicei costul. Multe au planuri gratuite sau ieftine pentru echipe mici, deci verifică înainte să construiești.

Construiește-o pe a ta când vrei control total asupra designului și a formulărilor, când nevoile tale sunt simple (câteva componente, actualizări manuale) sau când pagina de status face parte dintr-un produs pe care îl construiești pentru alții.

Cum o construiești cu Mythex

În Mythex poți construi pagina de status ca proiect separat de aplicația principală, ceea ce îi dă găzduire separată și propria bază de date. Descrie-o în chat, verific-o în previzualizarea live, apoi publică-o și conectează un subdomeniu precum status.domeniultau.ro (domeniile personalizate sunt disponibile în planul Pro). Ține minte că aplicațiile publicate în Mythex și bazele lor de date intră în repaus când nu sunt folosite și se trezesc la următoarea vizită, deci prima încărcare după o perioadă de liniște poate fi mai lentă; o pagină simplă și ușoară ajută.

Mythex nu documentează joburi programate, deci pentru verificări automate folosește un monitor extern de disponibilitate care apelează un endpoint webhook din pagina ta de status (vezi rețeta pentru webhook-uri). Alertele prin e-mail către abonați merg prin furnizorul tău, cu cheia salvată ca secret al proiectului (rețeta pentru trimiterea e-mailurilor).

Întrebări