Com crear una pàgina d'estat: components, incidents i comprovacions d'uptime

Una pàgina d'estat indica als teus usuaris, en un sol lloc, si el servei funciona. Per crear-ne una necessites una llista de components (web, API, pagaments, enviament de correu), l'estat actual de cadascun, incidents amb actualitzacions datades, un historial d'incidents passats i, opcionalment, subscripcions perquè la gent s'enteri dels problemes sense haver de comprovar-ho. La pàgina en si és senzilla. La decisió important és on s'executa: una pàgina d'estat ha de continuar disponible quan la teva app no ho està, de manera que no ha de compartir allotjament, base de dades ni pipeline de desplegament amb allò que informa.

Per a què serveix una pàgina d'estat

Quan alguna cosa falla, els usuaris volen saber tres coses: si és només cosa seva, si ja ho sabeu i quan es resoldrà. Una pàgina d'estat respon a les tres sense generar un allau de tiquets de suport. A més, genera confiança amb el temps, perquè un historial visible d'incidents amb explicacions honestes demostra com gestiones els problemes.

No és un registre de canvis. Les novetats van a una pàgina de canvis; les caigudes i les tasques de manteniment, aquí.

Què necessita la pàgina

Dades

L'estat dels components sol ser una llista curta i fixa: Operatiu, Rendiment degradat, Interrupció parcial, Interrupció greu, En manteniment.

Pàgines

• Pàgina d'estat pública: un bàner general («Tots els sistemes operatius» o l'estat més greu actual), cada component amb el seu estat, qualsevol incident actiu amb les seves actualitzacions, el manteniment previst i una franja d'historial dels últims 90 dies si tens dades de comprovació.
• Pàgina d'incident: la cronologia completa d'actualitzacions d'un incident, amb URL pròpia perquè el suport la pugui enllaçar.
• Historial: incidents passats per mes.
• Subscripció: registre per correu amb confirmació i preferències per component.
• Administració: crear un incident, publicar actualitzacions, canviar l'estat dels components i programar manteniments.

Permisos

El públic veu tot el que es publica. Només el vostre equip pot publicar. Si pots, mantén l'accés d'administració separat del sistema d'inici de sessió de la teva app principal, perquè una caiguda del proveïdor d'autenticació no et tanqui fora de la teva pròpia pàgina d'estat.

La decisió clau: que sigui independent

Aquí és on fallen la majoria de pàgines d'estat fetes a casa. Si la teva pàgina d'estat:

• s'executa al mateix servidor o compte d'allotjament que la teva app,
• llegeix de la mateixa base de dades,
• depèn de la mateixa configuració de domini o de la mateixa CDN,
• o es despliega amb el mateix pipeline,

moltes caigudes també la tombaran, justament quan la gent més la necessiti. Passos pràctics:

• Allotjament separat. Un projecte o proveïdor diferent del de l'app principal.
• Subdomini propi, com status.exemple.com, apuntat per separat al DNS. Consulta com funcionen els dominis i el DNS.
• Dades pròpies. Els incidents viuen a l'emmagatzematge de la pàgina d'estat, no a la base de dades de la teva app.
• Una alternativa estàtica. Alguns equips fan la pàgina pública estàtica i la reconstrueixen a cada actualització, de manera que gairebé no hi ha res que es pugui trencar.

Actualitzacions manuals o comprovacions automàtiques

Manual (per començar aquí)

El teu equip publica els incidents i canvia l'estat dels components a mà des de la pàgina d'administració. Així funcionen moltes pàgines d'estat a la pràctica, perquè un criteri humà («els pagaments van lents per a alguns tipus de targeta») és més útil que un punt vermell automàtic.

Per assabentar-te ràpidament dels problemes, fes servir un monitor d'uptime extern que comprovi la teva app cada minut més o menys i t'avisi per correu, SMS o xat. Molts serveis de monitoratge tenen plans gratuïts.

Automàtic

L'automatització vol dir que alguna cosa comprova regularment cada component i actualitza el seu estat. Això requereix codi que s'executi programat, des de fora de la infraestructura principal de la teva app. Hi ha dos patrons habituals:

• Un monitor extern crida la teva pàgina d'estat a través d'un webhook quan una comprovació falla o es recupera, i la pàgina d'estat actualitza el component.
• Una tasca programada a l'allotjament de la pròpia pàgina d'estat fa ping a cada component i en registra el resultat. Abans de confiar-hi, comprova com el teu allotjament gestiona les tasques programades; la nostra guia sobre executar tasques en segon pla explica les opcions.

Els canvis automàtics poden fer oscil·lacions (funciona, cau, funciona) en una xarxa lenta. Exigeix dues o tres comprovacions fallides abans de canviar un estat, i deixa que una persona confirmi abans d'anunciar una caiguda greu.

Com escriure actualitzacions d'incidents

• Publica aviat. «Estem investigant informes de fallades en els inicis de sessió» als pocs minuts és millor que un missatge perfecte una hora després.
• Digues què notaran els usuaris, no què s'ha trencat internament.
• Promet l'hora de la següent actualització i compleix-la.
• Tanca amb un resum breu un cop resolt: què ha passat, quant ha durat i què canviaràs.

Un primer prompt que funciona

Construeix una pàgina d'estat independent per a la nostra app Parcelio, que s'allotjarà per separat a status.parcelio.com. Components: Web, API de seguiment, Notificacions, Pagaments, cadascun amb un estat entre Operatiu, Rendiment degradat, Interrupció parcial, Interrupció greu o En manteniment. La pàgina pública mostra un bàner general amb l'estat més greu actual, cada component amb el seu estat, els incidents actius amb actualitzacions datades de la més recent a la més antiga, el manteniment previst i una llista d'incidents passats per mes. Cada incident té la seva pròpia pàgina. Afegeix una pàgina d'administració protegida amb contrasenya per crear incidents (títol, impacte, components afectats), publicar actualitzacions (missatge i estat: Investigant, Identificat, Monitoritzant, Resolt), canviar l'estat dels components i programar manteniments. Afegeix un endpoint POST /api/check-result que accepti el nom d'un component i up/down d'un monitor extern, protegit per un token secret, i que marqui un component com a Degradat només després de tres caigudes consecutives. Emmagatzema-ho tot a la base de dades pròpia d'aquesta app. Disseny simple i tranquil que carregui ràpid als mòbils.

Passos de construcció

1. Pàgina pública i administració amb incidents manuals. Només això ja és una pàgina d'estat que funciona.
2. Allotja-la per separat i apunta-hi un subdomini.
3. Pàgines d'incident i historial.
4. Finestres de manteniment.
5. Subscripcions. Registre per correu amb doble confirmació i notificacions en publicar nous incidents i actualitzacions. El correu necessita un proveïdor; consulta com enviar correus des de la teva app.
6. Webhook del monitor si vols canvis d'estat automàtics.
7. Fes un simulacre. Crea un incident fictici, publica actualitzacions, resol-lo, comprova els correus i després esborra'l.

Errors habituals

• Allotjar-la amb l'app. El més habitual i també el més greu.
• Una pàgina que sempre diu «Tots els sistemes operatius». Si mai no mostra problemes, els usuaris deixen de confiar-hi.
• Sense marques de temps ni zona horària. Mostra sempre les hores amb la zona.
• Dependre de l'inici de sessió de l'app principal per a la pàgina d'administració.
• Silenci entre actualitzacions. «Sense canvis, encara hi estem treballant» és una actualització vàlida.
• Estats automàtics que oscil·len. Exigeix comprovacions fallides repetides abans de canviar res.

Quan és millor un servei de pàgina d'estat allotjat

Els serveis de pàgina d'estat allotjats estan pensats per resoldre el problema de la independència: funcionen en una infraestructura separada, gestionen les notificacions als subscriptors per correu i SMS, i sovint inclouen monitoratge i integracions amb eines de gestió d'incidents. Si l'uptime és part del que paguen els clients, o tens obligacions contractuals d'informar de les incidències, un servei dedicat normalment val la pena. Molts tenen plans gratuïts o de baix cost per a equips petits, així que revisa-ho abans de construir-ne una.

Construeix-ne una pròpia quan vulguis el control total del disseny i la redacció, quan les necessitats siguin senzilles (un grapat de components, actualitzacions manuals) o quan una pàgina d'estat formi part d'un producte que construeixes per a d'altres.

Construir-la amb Mythex

A Mythex pots construir la pàgina d'estat com un projecte propi, separat de l'app principal, cosa que li dona un allotjament independent i la seva pròpia base de dades. Descriu-la al xat, revisa-la a la vista prèvia en directe, després publica-la i connecta un subdomini com status.elteudomini.com (els dominis personalitzats són al Pro). Ten en compte que les apps publicades a Mythex i les seves bases de dades es posen en repòs quan estan inactives i es reactiven amb la següent visita, de manera que la primera càrrega després d'un període de calma pot trigar més; una pàgina simple i lleugera ajuda.

Mythex no documenta les tasques programades, així que per a les comprovacions automàtiques fes servir un monitor d'uptime extern que cridi un endpoint de webhook de la teva pàgina d'estat (consulta la guia de webhooks). Els avisos per correu als subscriptors passen pel teu propi proveïdor, amb la clau guardada com a secret del projecte (recepta d'enviament de correu).

Preguntes