如何建立狀態頁：元件、事故及正常運作檢查

狀態頁讓你的用戶在同一個地方知道你的服務是否運作正常。要建立一個狀態頁，你需要一份元件清單（網站、API、付款、電郵發送等）、每個元件的現時狀態、附有時間標記的事故更新、過往事故的紀錄，並可選擇提供訂閱功能，讓人無需主動查看也能得知問題。頁面本身很簡單，重要的決定在於它運行在哪裡：狀態頁必須在你的應用程式故障時仍然可用，所以它不應與被它報告的系統共用託管、資料庫或部署流程。

狀態頁的用途

當有東西壞了，用戶想知道三件事：是否只有自己遇到問題、你是否已知道，以及何時會修復。狀態頁能一次回答這三個問題，減少大量客服查詢。長遠來說，它也能建立信任：一份可見的事故紀錄，連同誠實的事後報告，能顯示你如何處理問題。

它不是更新日誌。新功能應該放在更新日誌頁；故障和維護則放在這裡。

狀態頁需要的內容

資料

元件狀態通常是一份固定的短清單：正常運作、效能下降、部分故障、嚴重故障、維護中。

頁面

• **公開狀態頁：**整體橫幅（「所有系統正常運作」或當前最嚴重的狀態）、每個元件及其狀態、任何進行中事故及其更新、即將進行的維護，以及（如有監察數據）過去 90 日的狀態條。
• **事故頁：**單一事故的完整更新時間線，並有獨立網址，方便客服人員分享連結。
• **歷史紀錄：**按月列出過往事故。
• **訂閱：**電郵登記，附確認步驟及按元件設定的偏好。
• **管理後台：**建立事故、發布更新、更改元件狀態、安排維護。

權限

公眾只能看到已發布的內容，只有你的團隊可以發布更新。如果可以，請將管理後台的登入與主應用程式的登入系統分開，這樣即使你的認證服務故障，你仍能進入自己的狀態頁。

關鍵決定：保持獨立

自製的狀態頁最常見的失敗原因就在這裡。如果你的狀態頁：

• 與應用程式運行在同一伺服器或託管帳戶，
• 讀取同一個資料庫，
• 位於同一套網域設定或 CDN 設定之後，
• 或由同一條部署流程發布，

那麼許多故障也會把它一併拖垮，而且偏偏是用戶最需要它的時候。實際做法如下：

• **獨立託管。**使用與主應用程式不同的專案或服務商。
• 獨立子網域，例如 status.example.com，在 DNS 中單獨指向。參閱網域與 DNS 運作原理。
• **獨立資料。**事故紀錄存放在狀態頁自己的儲存空間，不放在應用程式的資料庫。
• **靜態後備。**有些團隊將公開頁面做成靜態，並在每次更新時重新建置，這樣幾乎沒有東西會壞。

手動更新還是自動檢查

手動（建議起步使用）

團隊透過管理後台手動建立事故、更改元件狀態。許多狀態頁實際上都是這樣運作，因為人的判斷（「部分信用卡類別的付款速度較慢」）比自動化的紅色圓點更有用。

要盡快得知問題，可使用外部正常運作監察工具，每分鐘左右檢查一次你的應用程式，並透過電郵、短訊或即時通訊工具發出警示。許多監察服務都設有免費方案。

自動化

自動化是指有程式定時檢查每個元件，並自動更新其狀態。這需要一段在主應用程式基礎設施以外、按時間表運行的程式碼。常見的兩種模式如下：

• 外部監察工具在檢查失敗或恢復時，透過 webhook 呼叫你的狀態頁，狀態頁隨之更新該元件。
• 狀態頁自身託管環境中的排程工作，定時對每個元件進行檢查並記錄結果。依賴這方法之前，請先查看你的託管服務如何處理排程任務；我們的背景工作指南介紹了各種選項。

自動更新在網絡不穩時可能出現反覆跳動（正常、故障、正常）。建議要求連續兩至三次檢查失敗才更改狀態，並在宣布嚴重故障之前由人工確認。

撰寫事故更新

• 及早發布。「我們正在調查部分用戶無法登入的報告」在幾分鐘內發布，比一小時後才發布一則完美的訊息更有價值。
• 說明用戶會注意到什麼，而非內部哪裡出了問題。
• 承諾下一次更新的時間，並且準時兌現。
• **問題解決後附上簡短總結：**發生了什麼、持續多久、你正在作出哪些改變。

一個有效的首個提示

為我們的應用程式 Parcelio 建立一個獨立運作的狀態頁，並獨立託管於 status.parcelio.com。元件包括：網站、追蹤 API、通知、付款，每個元件的狀態可為正常運作、效能下降、部分故障、嚴重故障或維護中。公開頁面顯示以當前最嚴重狀態計算的整體橫幅、每個元件的狀態、進行中的事故及附有時間標記的更新（最新的排在最前）、即將進行的維護，以及按月列出的過往事故。每宗事故都有獨立頁面。新增一個受密碼保護的管理頁面，用來建立事故（標題、影響程度、受影響元件）、發布更新（訊息及狀態：調查中、已確定原因、監察中、已解決）、更改元件狀態及安排維護。新增一個 POST /api/check-result 端點，接受外部監察工具傳來的元件名稱及正常／故障結果，並以秘密權杖保護；只有在連續三次故障後，才將元件標記為效能下降。所有資料都存放在此應用程式自己的資料庫。設計簡潔、平靜，在手機上載入迅速。

建置步驟

1. **公開頁面及附有手動事故功能的管理後台。**單靠這部分，你已有一個可用的狀態頁。
2. 獨立託管，並將子網域指向它。
3. 事故頁面及歷史紀錄。
4. 維護時段。
5. **訂閱功能。**雙重確認的電郵登記，並在有新事故及更新時發出通知。電郵需要服務商；參閱如何在應用程式中發送電郵。
6. 監察 webhook，如果你想要自動更改狀態。
7. **進行演練。**建立一宗假事故，發布更新，將其解決，檢查電郵，然後刪除。

常見錯誤

• **與應用程式一起託管。**這是最常見，也是最嚴重的錯誤。
• **頁面永遠顯示「所有系統正常運作」。**如果它從不顯示問題，用戶便會失去信任。
• **沒有時間標記或時區。**時間一律要連同時區顯示。
• 管理後台依賴主應用程式的登入。
• 更新之間長時間沉默。「沒有變化，仍在處理中」也是有效的更新。
• **自動狀態反覆跳動。**在更改狀態前，要求多次連續失敗。

何時改用現成的狀態頁服務較好

託管式狀態頁服務正是為解決獨立性的問題而設：它們在獨立的基礎設施上運行，透過電郵及短訊處理訂閱者通知，通常還包括監察功能，並與事故管理工具整合。如果正常運作時間是你向客戶提供的服務的一部分，或你有合約義務要匯報事故，專用服務通常值得使用。許多服務都為小團隊提供免費或低收費方案，所以動手建置前先比較一下。

在以下情況，自行建置會更合適：你希望完全掌控設計與措辭；需求簡單（只有少數元件、手動更新）；或狀態頁本身是你為他人開發的產品的一部分。

用 Mythex 建置

在 Mythex 中，你可以將狀態頁建為獨立於主應用程式的專案，因此它擁有獨立的託管及自己的資料庫。用對話描述需求，在即時預覽中檢查，然後發布並連接 status.yourdomain.com 這類子網域（自訂網域為 Pro 功能）。請注意，已發布的 Mythex 應用程式及其資料庫在閒置時會休眠，並於下一次訪問時喚醒，因此長時間無人使用後的首次載入可能較慢；一個簡單、輕量的頁面有助改善這點。

Mythex 尚未說明排程任務的功能，所以如需自動檢查，可使用外部正常運作監察工具呼叫狀態頁中的 webhook 端點（參閱 webhook 教學）。發送給訂閱者的電郵警示，透過你自己的服務商發出，金鑰則存放為專案秘密（參閱發送電郵教學）。

常見問題