如何打造狀態頁面：元件、事件與可用性檢查

狀態頁面在一個地方告訴你的使用者，你的服務是否正常運作。要打造一個，你需要一份元件清單（網站、API、付款、郵件傳送），每個元件的目前狀態，附有時間戳記更新的事件，過去事件的歷史紀錄，以及可選的訂閱功能，讓人不必主動查看也能得知問題。頁面本身很簡單。真正重要的決定是它要在哪裡執行：狀態頁面必須在你的應用程式停擺時仍然上線，所以不應該與它所回報的對象共用主機、資料庫或部署流程。

狀態頁面的用途

出現問題時，使用者想知道三件事：是不是只有我遇到、你們知不知道，以及什麼時候會修好。狀態頁面不用大量客服工單就能回答這三件事。它也會隨著時間建立信任，因為公開的事件歷史與誠實的說明，顯示你如何處理問題。

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

頁面需要什麼

資料

元件狀態通常是一組簡短、固定的選項：正常運作、效能降低、部分中斷、重大中斷、維護中。

頁面

• 公開狀態頁面： 整體橫幅（「所有系統正常運作」或目前最嚴重的狀態）、每個元件及其狀態、任何進行中的事件及其更新、即將到來的維護，以及如果你有檢查資料，還有 90 天的歷史長條圖。
• 事件頁面： 單一事件的完整更新時間線，並有自己的網址，讓客服可以直接連結。
• 歷史紀錄： 依月份列出過去的事件。
• 訂閱： 電子郵件註冊，附確認流程與每個元件的偏好設定。
• 管理後台： 建立事件、發布更新、變更元件狀態、排定維護。

權限

公眾可以看到所有已發布的內容。只有你的團隊可以發布。如果做得到，管理後台的登入要與主應用程式的登入系統分開，這樣你的驗證服務故障時，才不會把你自己鎖在狀態頁面之外。

關鍵決定：保持獨立

自製的狀態頁面最常在這裡失敗。如果你的狀態頁面：

• 與你的應用程式跑在同一台伺服器或同一個主機帳號上，
• 從同一個資料庫讀取資料，
• 位於相同的網域設定或 CDN 設定之後，
• 或是由同一條部署流程發布，

那麼許多故障也會把它一起拖垮，而且正好是人們最需要它的時候。實用的做法如下：

• 獨立託管。 使用與主應用程式不同的專案或供應商。
• 自己的子網域，例如 status.example.com，在 DNS 中單獨指向。參見網域與 DNS 運作方式。
• 自己的資料。 事件存放在狀態頁面自己的儲存空間中，而不是你的應用程式資料庫。
• 靜態備援。 有些團隊把公開頁面做成靜態，每次更新時重新產生，這樣幾乎沒有東西會壞掉。

手動更新或自動檢查

手動（建議從這裡開始）

你的團隊在管理後台手動發布事件並更改元件狀態。實際上許多狀態頁面就是這樣運作的，因為人的判斷（「部分信用卡類型的付款速度變慢」）比自動化的紅點更有用。

若要盡快得知問題，可以使用外部監控工具，每隔一分鐘左右檢查你的應用程式，並透過電子郵件、簡訊或聊天工具通知你。許多監控服務有免費方案。

自動化

自動化是指有東西定期檢查每個元件，並更新其狀態。這需要在排程中執行的程式，而且是從你主應用程式的基礎設施之外執行。兩種常見模式：

• 外部監控工具在檢查失敗或恢復時，透過 Webhook 呼叫你的狀態頁面，由狀態頁面更新元件。
• 狀態頁面自己的主機上有一個排程任務，定期 ping 每個元件並記錄結果。在依賴它之前，請先確認你的主機如何處理排程任務；我們的執行背景任務指南說明了各種選項。

在網路緩慢時，自動化的狀態變更可能會反覆跳動（正常、故障、正常）。因此要求連續兩到三次失敗才改變狀態，而且在宣布重大中斷之前，由人工確認。

撰寫事件更新

• 盡早發布。 在幾分鐘內寫下「我們正在調查登入失敗的回報」，比一小時後寫出完美的訊息更好。
• 說明使用者會注意到什麼，而不是內部壞了什麼。
• 承諾下一次更新的時間，並且確實做到。
• 解決後附上簡短摘要：發生了什麼、持續多久、你正在改進什麼。

一個有效的首次提示

為我們的應用程式 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 指南）。寄給訂閱者的電子郵件通知則透過你自己的供應商發送，金鑰以專案祕密的方式儲存（寄送郵件指南）。

常見問題