雲端服務的狀態頁，上線前應該確認哪些事情？
要確認五件事：公開哪些元件、每一種狀態用什麼字、多久更新一次、誰有權限發布、以及歷史紀錄留多久。服務狀態頁是軟體公司對外公開系統目前是否正常運作的網頁。它的作用是在客戶發現異常的時候，讓他不必寫信或打電話，就能知道你們已經知道了。
這份清單來自一家做排班與打卡的雲端軟體公司，團隊二十多人，客戶以連鎖門市為主。他們過去發生異常時，靠客服在通訊群組裡逐一回覆。某一次早班打卡尖峰出狀況，客服信箱在一小時內被塞滿。事後總經理決定做狀態頁，並指定行銷主責，因為這是一張對外的頁面。
清單共二十項，分五組。每一組前面先說明會議上吵過的點。使用方式是逐項打勾，不能打勾的項目要寫下原因與預計補上的日期。
第一組：狀態頁要公開哪些元件，哪些不放？
工程主管原本想把內部監控的三十幾個服務全部列出來，理由是透明。客服主管反對，她說客戶看不懂訊息佇列是什麼，只會打電話來問那個紅燈是不是代表我的資料不見了。
取捨的原則是用客戶的動作來命名，不用系統架構來命名。客戶每天做的事情是登入、打卡、排班、匯出薪資報表、收到通知。元件就照這個列。
- 元件名稱使用客戶看得懂的動作，例如員工打卡、主管排班、報表匯出、通知推播、登入驗證
- 元件數量控制在五到八個，超過就合併
- 每個元件對應到內部哪些服務，另寫一份對照表，只供內部使用
- 第三方依賴，例如簡訊發送與地圖定位，獨立列為一個元件，並註明由外部供應商提供
- 行動應用程式與網頁版若可能各自出狀況，要分開列
第四項是事後補的。有一次簡訊供應商延遲，客戶收不到驗證碼，狀態頁卻顯示全部正常。客戶的感受是你們的頁面不準。把外部依賴列出來，並不是推卸責任，客戶需要知道問題出在哪一段。
第二組：每一種狀態用什麼字，才不會被誤讀？
這一組由行銷主導。工程習慣用降級、部分中斷、重大中斷。客服說客戶看到降級會問是不是我的方案被降級了。
- 狀態只分四級：正常運作、速度變慢、部分功能無法使用、無法使用
- 每一級寫一句固定的白話說明，例如速度變慢代表功能可用但回應時間較長
- 事件公告的第一句永遠回答客戶受到什麼影響，第二句才寫我們正在做什麼
- 不寫原因的猜測，確認之前只寫正在調查
- 不使用不便之處敬請見諒這類句子開頭，道歉放在事件結束的說明裡，並且要具體
第九項在會議上爭論最久。工程想把技術原因寫在前面，因為那是他們最清楚的資訊。我們請客服念了三封客戶來信，每一封的第一個問題都是我的員工現在能不能打卡。客戶要先知道影響，再知道原因。
公告範本寫成四個欄位，值班的人只要填空：受影響的功能、受影響的對象、目前的狀態、下一次更新的時間。四個欄位填完，一則公告就能發。
第三組：多久更新一次，沒有進展也要更新嗎？
沒有進展也要更新。這是整份清單裡最重要的一條。客戶看到一則四十分鐘前的公告，會判斷這個頁面沒有人在管，然後開始寫信。
- 確認異常後，在團隊自訂的時限內發出第一則公告，時限寫進值班手冊
- 事件進行中，每隔固定時間更新一次，即使內容只有仍在處理中，下次更新時間為幾點幾分
- 每一則更新都標示時間與時區
- 事件解決後發一則恢復公告，並說明是否需要客戶做任何動作，例如重新登入或重新匯出
固定間隔要訂多久，由團隊依人力決定，文中不代訂。原則是訂一個半夜只有一個人值班也做得到的數字。訂得太密做不到，比訂得寬鬆更傷信任。
還有一個常被忽略的問題：監控系統自動偵測到的異常，要不要自動顯示在狀態頁上。工程希望自動，行銷與客服希望人工確認後才發布。最後的做法是自動偵測只通知值班人員，對外公告一律由人發。理由是自動偵測會有誤報，一次誤報的紅燈就會引來一批來信。
第四組：誰可以發公告，半夜出事找誰？
這一組沒有人想負責，所以最容易留白。行銷認為技術事件應該由工程發，工程認為對外文字應該由行銷發。
- 發布權限給值班工程師與客服主管，兩者皆可獨立發布，不需互相簽核
- 行銷不在發布流程中，但負責事前寫好範本與用語表，並在事件後審閱公告文字
- 事件結束後的檢討說明，由工程撰寫原因與改善措施，行銷改寫成客戶讀得懂的版本，總經理核可後發布
- 客服的自動回覆信與通訊軟體的歡迎訊息，在事件期間加上狀態頁的說明，事件結束後移除，這個動作指定一位負責人
第十八項是行銷真正的工作。事件發生的當下，文字好不好看不重要，重要的是快。行銷的價值在事前，把範本寫到值班的人不需要思考措辭。
檢討說明是另一份文件。它的結構固定為四段：發生了什麼、影響了誰與多久、原因是什麼、我們改了什麼。第四段只寫已經完成的改善，還在計畫中的事項要標明是計畫。客戶會回來對照你說過的話。
第五組：狀態頁放在哪裡、歷史要留多久、要不要被搜尋到？
業務主管擔心歷史紀錄會被競爭對手拿去當攻擊素材，希望只顯示最近七天。
我們的看法是相反的。採購方在評估雲端服務時，常會主動找狀態頁。一個只有七天紀錄的頁面，看起來像剛做的，或是在藏東西。一份有紀錄、每一筆都有清楚結案說明的歷史，本身就是可靠度的證明。
- 狀態頁使用獨立的網址，並盡量託管在與主服務不同的基礎設施上，主服務掛掉時頁面仍能開啟
- 官網頁尾、登入頁、客服中心首頁、應用程式的錯誤畫面，四個位置都放狀態頁的入口
歷史保留的長度，最後決定保留至少一年，並允許搜尋引擎收錄。業務主管的擔心用另一種方式處理：每一筆歷史事件都必須有結案說明，不能只留下一個紅色的標記。有說明的紀錄，被拿去比較時也站得住。
搜尋呈現的部分，我們用 Google Search Console 這個免費工具確認，品牌名稱加上當機、連不上、狀態等查詢，第一個結果是不是狀態頁。如果不是，客戶在出事時搜尋到的可能是舊的論壇貼文。頁面標題要直接寫品牌名稱加服務狀態，描述寫明此頁即時顯示各功能的運作情形。
清單做完之後，怎麼驗收狀態頁真的有用？
驗收靠一次演練與三個紀錄。
演練在上線前做。由工程在測試環境模擬一次打卡功能異常，值班人員照手冊發公告，客服照流程改自動回覆。全程計時，並請一位不知情的同事扮演客戶，看他能不能在不問任何人的情況下，知道現在怎麼了、什麼時候會有下一次消息。
演練中發現了兩個問題。值班工程師找不到狀態頁後台的登入方式。客服的自動回覆信有三個版本，沒有人知道該改哪一個。這兩件事在真實事件中都會耗掉關鍵的時間。
- 每次事件記錄：從確認異常到第一則公告的時間
- 每次事件記錄：更新是否照固定間隔發出，漏了幾次
- 每次事件記錄：事件期間客服收到的相關來信與來電件數
第三項要跟過去的事件比，但比較時要小心。每次事件的影響範圍與發生時段不同，件數不能直接相除得出一個百分比來宣稱成效。我們只在內部檢討時並列參考，不對外引用。
哪些團隊不適合照這份清單建置狀態頁？
沒有值班制度的團隊先不要做。狀態頁最怕的是出事時沒有人更新。一個永遠顯示正常的頁面，在客戶明明連不上的時候，會讓信任一次歸零。先建立值班與通報流程，再做對外頁面。
客戶數很少、每一家都有專屬窗口的專案型軟體公司，也不一定需要。直接由窗口通知，比公開頁面更快也更貼近客戶習慣。
與客戶簽有服務水準協議的公司要多一道確認。服務水準協議是合約中對可用時間與回應時間的承諾。狀態頁上的用語、事件起迄時間的認定，可能被拿來對照合約條款計算補償。這部分的文字與紀錄方式，上線前應請法務或執業律師審閱，本文的清單不能取代這項審閱。
常見問題
服務狀態頁是什麼？
服務狀態頁是軟體公司公開顯示各項功能目前是否正常運作的網頁。發生異常時，客戶可以在上面看到影響範圍、處理進度與下一次更新的時間。
狀態頁的歷史事件要公開多久？
建議至少保留一年，並為每一筆事件寫下結案說明。有完整說明的歷史紀錄能證明團隊的處理能力，只顯示幾天反而容易讓採購方起疑。
系統異常時沒有新進展，還要更新公告嗎？
要。即使只寫仍在處理中與下一次更新時間，也要照固定間隔發出。客戶看到久未更新的公告，會認為沒有人在處理，並轉向客服詢問。
狀態頁應該由行銷還是工程負責？
事件當下由值班工程師或客服主管直接發布，行銷負責事前寫好範本與用語，並在事後協助把檢討說明改寫成客戶讀得懂的版本。