Paano Gumawa ng Status Page: Mga Component, Incidents at Uptime Checks

Sinasabi ng status page sa users mo, sa isang lugar, kung gumagana ang serbisyo mo. Para makagawa nito, kailangan mo ng listahan ng components (website, API, payments, email), kasalukuyang status ng bawat isa, incidents na may timestamped na updates, kasaysayan ng nakaraang incidents, at opsyonal na subscriptions para malaman ng tao ang problema nang hindi na kailangang mag-check. Simple lang ang mismong page. Ang mahalagang desisyon ay kung saan ito tatakbo: dapat manatiling up ang status page kahit down ang app mo, kaya hindi dapat magbahagi ng hosting, database o deploy pipeline sa bagay na iniuulat nito.

Para saan ang status page

Kapag may sumira, gusto malaman ng users ng tatlong bagay: ako lang ba ang nakakaranas nito, alam ba ninyo ang problema, at kailan ito maaayos. Sinasagot ng status page ang tatlong ito nang hindi binabaha ng support tickets. Nakakabuo rin ito ng tiwala sa paglipas ng panahon, dahil ang nakikitang kasaysayan ng incidents na may tapat na paliwanag ay nagpapakita kung paano ninyo hinaharap ang mga problema.

Hindi ito changelog. Ang mga bagong feature ay nasa changelog page; ang outages at maintenance ay dito.

Ano ang kailangan ng page

Data

Karaniwang maikli at nakapirming listahan ang component statuses: Operational, Degraded performance, Partial outage, Major outage, Under maintenance.

Mga page

• Public status page: pangkalahatang banner ("All systems operational" o ang pinakamasamang kasalukuyang status), bawat component na may status nito, anumang aktibong incident na may mga update, paparating na maintenance, at 90-day history strip kung may check data ka.
• Incident page: buong timeline ng mga update para sa isang incident, na may sariling URL para maibahagi ito ng support.
• History: nakaraang incidents kada buwan.
• Subscribe: email sign-up na may kumpirmasyon at preference kada component.
• Admin: gumawa ng incident, mag-post ng updates, baguhin ang component statuses, mag-iskedyul ng maintenance.

Permissions

Nakikita ng publiko ang lahat ng na-publish. Ang team mo lang ang puwedeng mag-post. Kung kaya, panatilihing hiwalay ang admin login sa login system ng main app mo, para hindi ka ma-lock out sa sarili mong status page kapag bumagsak ang auth provider mo.

Ang pangunahing desisyon: panatilihing independent

Dito kadalasang pumapalpak ang mga status page na gawa sa bahay. Kapag ang status page mo:

• ay tumatakbo sa parehong server o hosting account ng app mo,
• ay bumabasa sa parehong database,
• ay nasa parehong domain setup o CDN configuration,
• o dineploy ng parehong pipeline,

maraming outage ang magpapabagsak din dito, eksaktong kapag kailangan ito ng tao. Mga praktikal na hakbang:

• Hiwalay na hosting. Ibang project o provider sa main app.
• Sariling subdomain, gaya ng status.example.com, na hiwalay na itinuro sa DNS. Tingnan ang paano gumagana ang domains at DNS.
• Sariling data. Nasa sariling storage ng status page ang incidents, hindi sa app database mo.
• Static fallback. May mga team na ginagawang static ang public page at nire-rebuild sa bawat update, kaya halos walang puwedeng masira.

Manual na update o automated checks

Manual (dito magsimula)

Isinusulat ng team mo ang incidents at binabago ang component statuses nang manual mula sa admin page. Ganito gumagana ang maraming status page sa totoong buhay, dahil mas mahalaga ang paghusga ng tao ("mabagal ang payments para sa ilang uri ng card") kaysa sa awtomatikong pulang tuldok.

Para mabilis malaman ang problema, gumamit ng external uptime monitor na sinusuri ang app mo kada minuto o halos ganoon at nag-aalerto sa iyo sa email, SMS o chat. Maraming monitoring service ang may libreng tier.

Automated

Ang automation ay nangangahulugang may regular na sumusuri sa bawat component at nag-a-update ng status nito. Kailangan dito ang code na tumatakbo sa iskedyul, mula sa labas ng infrastructure ng main app mo. Dalawang karaniwang pattern:

• Tumatawag ang external monitor sa status page mo sa pamamagitan ng webhook kapag pumalya o bumalik ang isang check, at ina-update ng status page ang component.
• Isang scheduled job sa sarili nitong hosting ng status page ang nagpi-ping sa bawat component at nagtatala ng resulta. Tingnan muna kung paano hinahawakan ng hosting mo ang scheduled tasks bago umasa dito; ipinapaliwanag ng aming guide tungkol sa pagpapatakbo ng background jobs ang mga opsyon.

Puwedeng mag-flap ang automated changes (up, down, up) sa mabagal na network. Mag-require ng dalawa o tatlong pumalyang check bago magbago ang status, at hayaang kumpirmahin muna ng tao bago i-anunsyo ang malaking outage.

Pagsulat ng incident updates

• Mag-post nang maaga. Ang "Iniimbestigahan namin ang mga ulat ng hindi pagpasok sa login" sa loob ng ilang minuto ay mas mabuti kaysa perpektong mensahe makalipas ang isang oras.
• Sabihin ang napapansin ng users, hindi ang panloob na nasira.
• Mangako ng oras ng susunod na update, at tuparin ito.
• Magsara ng maikling buod kapag na-resolve na: ano ang nangyari, gaano katagal, at ano ang babaguhin ninyo.

Unang prompt na gumagana

Gumawa ng standalone na status page para sa app naming Parcelio, na hiwalay na i-host sa status.parcelio.com. Mga component: Website, Tracking API, Notifications, Payments, bawat isa may status na Operational, Degraded performance, Partial outage, Major outage o Under maintenance. Ipinapakita ng public page ang pangkalahatang banner gamit ang pinakamasamang kasalukuyang status, bawat component na may status nito, anumang aktibong incident na may timestamped na updates (pinakabago sa itaas), paparating na maintenance, at listahan ng nakaraang incidents kada buwan. May sariling page ang bawat incident. Magdagdag ng admin page na may password para gumawa ng incidents (title, impact, apektadong components), mag-post ng updates (mensahe at status: Investigating, Identified, Monitoring, Resolved), baguhin ang component statuses, at mag-iskedyul ng maintenance. Magdagdag ng POST /api/check-result endpoint na tumatanggap ng pangalan ng component at up/down mula sa external monitor, protektado ng secret token, at minamarkahan lang na Degraded ang component pagkatapos ng tatlong sunod-sunod na down. Itago ang lahat sa sariling database ng app na ito. Simple at kalmadong disenyo na mabilis mag-load sa telepono.

Mga hakbang sa paggawa

1. Public page at admin na may manual na incidents. Working status page na ito kahit mag-isa.
2. I-host ito nang hiwalay at ituro dito ang subdomain.
3. Incident pages at history.
4. Maintenance windows.
5. Subscriptions. Double opt-in na email sign-up at notifications sa bagong incidents at updates. Kailangan ng email provider; tingnan ang paano magpadala ng email mula sa app mo.
6. Monitor webhook kung gusto mo ng automated status changes.
7. Mag-drill. Gumawa ng pekeng incident, mag-post ng updates, i-resolve ito, tingnan ang mga email, at burahin ito.

Karaniwang pagkakamali

• Pag-host nito kasama ng app. Ang pinakakaraniwan at pinakamalubhang pagkakamali.
• Page na laging nagsasabing "All systems operational". Kapag hindi kailanman nagpakita ng problema, humihinto ang tao sa pagtitiwala.
• Walang timestamp o time zone. Laging ipakita ang oras kasama ang zone.
• Pag-asa sa login ng main app para sa admin page.
• Katahimikan sa pagitan ng updates. Ang "Walang bagong balita, tuloy pa rin ang pag-aayos" ay balidong update.
• Flapping na automated statuses. Mag-require ng paulit-ulit na pagkabigo bago magbago.

Kailan mas mabuting hosted status page service

Ang hosted status page services ay ginawa para sa problema ng independence: tumatakbo sila sa hiwalay na infrastructure, humahawak ng subscriber notifications sa email at SMS, at kadalasang may kasamang monitoring at integrations sa incident tools. Kung bahagi ng binabayaran ng customers ang uptime, o may kontraktwal kayong obligasyon na mag-ulat ng incidents, karaniwang sulit ang dedicated na service. Maraming may libre o mababang-presyong tier para sa maliliit na team, kaya tingnan muna bago gumawa.

Gumawa ng sarili kapag gusto mo ng buong kontrol sa disenyo at pananalita, kapag simple lang ang pangangailangan mo (ilang components, manual na updates), o kapag bahagi ng produktong ginagawa mo para sa iba ang status page.

Paggawa nito gamit ang Mythex

Sa Mythex, puwede mong gawin ang status page bilang sarili nitong project, hiwalay sa main app, kaya hiwalay ang hosting nito at may sarili itong database. Ilarawan ito sa chat, tingnan sa live preview, saka i-publish at ikonekta ang subdomain gaya ng status.yourdomain.com (ang custom domains ay para sa Pro). Tandaan na ang na-publish na Mythex apps at ang kanilang databases ay natutulog kapag walang gumagamit at nagigising sa susunod na bisita, kaya maaaring mas mabagal ang unang load pagkatapos ng tahimik na panahon; nakakatulong ang simple at magaang page.

Hindi dokumentado ng Mythex ang scheduled jobs, kaya para sa automated checks, gumamit ng external uptime monitor na tumatawag sa webhook endpoint ng status page mo (tingnan ang webhooks recipe). Ang email alerts sa subscribers ay dumadaan sa sarili mong provider, na may key na nakatago bilang project secret (send email recipe).

Mga tanong