當你的服務商停機時
最後更新:
服務商狀態頁是雲、託管、程式碼或付款服務商為宣示自身健康狀況而維護的公開儀表板：一個總體指示值、一份元件清單，以及一條由服務商本人在事件進行中親手寫下的事件時間軸。讀懂它是一種維運技能，因為標題只是摘要，真相住在它下面——哪個元件受影響、在哪個地區、宣布的影響有多大、事件在服務商自己的流程中已經走到了哪一步。本文就教你這種讀法，並以你所依賴的服務商出事時最初十分鐘該做什麼收尾。從服務商狀態看板開始，它把主要服務商的頁面匯集成一份快照，並始終記住是它停機了，還是只有你？這個問題：這兩個工具回答的是同一份疑慮的相反兩半。
兩件不同的事：指示值與事件狀態
每個成熟的狀態頁都帶有讀者不斷混淆的兩個獨立訊號。第一個是總體指示值：整個服務的一個彙總狀態，在頁面背後的機器可讀饋送中通常是 none、minor、major、critical 或 maintenance 之一——這個模型記錄在 Statuspage 開發者文件中，大多數大型服務商要麼直接使用它，要麼緊密地模仿它。指示值刻意粗糙。它的存在是為了讓忙碌的讀者——或者像我們的狀態看板這樣的機器——能在一秒內回答“那邊有什麼不對嗎？”，它由受影響最嚴重的元件、服務商自己的判斷，或兩者共同計算得出。
第二個訊號是事件本身，它有指示值抹平了的自身生命週期。一起事件以名稱、宣布的影響和一個取自流程的狀態開啟：調查中（我們看到了症狀，還不知道原因）、已定位（我們知道原因並正在處理）、監控中（修復已上線，我們正在觀察它是否站得住）和已解決（我們相信它結束了，以覆盤為準）。這些狀態攜帶指示值無法攜帶的資訊。一起已在監控中停留兩小時的危急事件通常正在結束；一起四分鐘前剛進入調查中的 minor 事件則可能變成任何樣子。
按這個順序把兩者都讀完，並讀它們之間的更新。事件下方的簡短更新時間軸，是服務商告訴你標題永遠不會說的事情的地方：哪個子系統壞了、有什麼變通辦法、受影響的是資料還是僅僅可用性，以及下一次更新承諾在二十分鐘還是兩小時後。一場更新停止到來的事件本身就是一種訊號——要麼團隊已經不堪重負，這與更長的故障相關，要麼這起事件已悄悄被併入一場更大的事件。只截圖標題就停下閱讀的維運者，例行地按照頁面上資訊量最少的那句話行事。
為什麼“所有系統運作正常”仍可能意味著你停機了
指示值總結的是整個服務，而現代服務不是一個東西。一個服務商可以全球誠實地全綠，同時你部署的地區、你呼叫的那一個產品介面、你被釘住的遺留 API 版本，或者你部署所需的控制平面，正在對每個碰到它的客戶失效。元件清單正是為此而存在：像 GitHub 的狀態頁這樣的頁面把服務分解為 Git 操作、API 請求、Actions、Pages 等等，其中任何一個都可以在總體橫幅保持安慰人心的同時降級——反之亦然，橫幅為一個你從未用過的元件變紅。
還有三個更安靜的缺口。第一，宣布滯後：服務商在確認一起事件後才宣布它，而不是在第一個錯誤發生時，因此許多故障的最初幾分鐘裡，看到的是一張綠色的頁面和一條燃燒的社交饋送；頁面沒有撒謊，它只是落後了。第二，閾值：服務商可能把某一層級上百分之二的錯誤率當作正常背景而從不宣布任何事，而這百分之二恰恰集中在你的流量模式上。第三，範圍：狀態頁描述的是電線在服務商那一側的情況。你的使用者與一個健康的服務商之間的 DNS 故障、路由問題或被阻斷的路徑，會在綠色指示值之下為你製造一場全盤故障——這正是為什麼那個伴隨的問題“是它停機了，還是只有你”必須從獨立的觀察點回答，而不是從服務商自己的頁面回答。
工作規則是把綠色當作“沒有宣布的事件”，永遠不要當作“已證明健康”。當你自己的監控說使用者在失敗、而服務商說運作正常時，就你的使用者而言相信你的監控，並把狀態頁用於另一件工作：檢查之後是否出現一份宣布——它會追溯地確認原因——以及你依賴的元件是否有與你正在經歷的這場形狀相同的事件歷史。
訂閱到元件，而不是頁面
大多數維運者訂閱狀態頁的方式和訂閱簡報一樣：一個訂閱、每起事件、永遠如此——然後可想而知地開始忽略這些郵件，因為一個大型服務商的全球饋送會穩定地滴下他們不用的元件、他們不服務的地區的事件。告警疲勞不是性格缺陷；它是對訊號範圍劃錯的正確反應。修復是機械的，幾乎每個成熟的狀態頁都有：在元件級別訂閱。定義這些指示值的同一個 Statuspage 模型也允許訂閱者按元件過濾，而運行自己系統的服務商，如 Cloudflare 的狀態頁，也透過自己的訂閱流程提供同樣的選擇。
把每個訂閱的範圍劃到在凌晨三點確實會改變你行為的東西上。你的生產流量呼叫的元件屬於響亮的渠道——那個會呼叫、發訊息或至少標記你幾分鐘內會看到的東西的渠道。你只用於建置、分析或內部工具的元件屬於一個你在工作時間審閱的安靜渠道。你根本不用的元件不屬於任何地方：你正確地忽略的每一條通知，都讓下一條更容易被忽略，包括那條重要的。技術堆疊變化時重新審視這份清單，因為訂閱會向兩個方向腐爛——沒人訂閱的新相依性，和還在呼叫一個沒人看的渠道的死相依性。
盡可能偏好機器可讀的饋送。電子郵件是狀態頁提供的最慢、最容易忽略的渠道；而 webhook 和饋送可以驅動你自己的儀表板、打開一張內部工單，或在第一條使用者投訴到來之前翻起你支援團隊準備好的佔位頁。即使是輕量版也有回報：我們的服務商狀態看板上的快照正是從這些公開饋送建置的，這證明這些資料就在那裡，可供程式化地消費，而不是被供在一個你得記得打開的瀏覽器分頁裡欣賞。
建立你自己的相依性清單
沒有一份清單，上述建議都行不通，而大多數團隊都是在故障中才發現自己沒有。一份相依性清單只是一個聽起來簡單其實不然的問題的書面答案：哪些外部服務，如果今晚停了，會讓我們停下——哪些只會讓我們難堪？在天氣平靜時建它。逐個介面走過你的架構——託管、DNS、程式碼託管與 CI、資料庫與儲存服務商、付款處理商、郵件與簡訊發送方、身分服務商、錯誤追蹤器、分析標籤、你的頁面從別人 CDN 載入的字型與腳本——並為每一個寫下：服務商、你實際消費的元件、它的狀態頁在哪裡，以及它失敗時你的使用者會經歷什麼。
按每個條目失敗的形狀而不是你多喜歡這個供應商來給它排名。有些相依性是硬的：它們停，你就停，唯一可做的工作是溝通和等待。有些是軟的：沒有它們網站也能運行，只是降級——沒有分析、沒有聊天小工具、沒有個人化——對這些，清單應寫明誰有權把它們關掉、如何關。還有些是隱藏的：你沒有選擇的遞移性相依性，比如你的 SaaS 資料庫本身運行其上的雲地區的狀態，或一切之下的憑證與 DNS 基礎設施。隱藏相依性正是製造“一切都停機了、而我們付費的東西一個都沒被列出”那種故障的那些，你透過向每個供應商問一次他們依賴什麼來找到它們。
把清單放在一場事件能夠到它的地方：在運行手冊裡、升級名單旁邊，而不是在一個當身分服務商正是停機的那個東西時沒人能打開的 wiki 頁面裡。一頁就夠了。它在故障中的工作是把“出了點問題”變成一份清單——對每個硬相依性，三十秒內，上或下——它之後的工作是被糾正，因為每一場真實事件都會教你一個你排錯了的相依性。一份從未被糾正的清單是一份歷史文件，不是維運文件。
服務商故障的最初十分鐘
第零到二分鐘：確認並定位。檢查你自己的監控，確信這場失敗是真實的、且歸你宣布，然後打開狀態看板和可疑服務商的頁面。你在回答一個問題：有沒有一份宣布的事件與你使用的東西重疊——元件、地區、產品？如果有，你就有了原因和第一條訊息。如果沒有，把檢查範圍擴大：你清單中的另一個服務商、你自己最近的一次部署、你的 DNS。大多數虛假的戲劇死在這兩分鐘裡，大多數真實的事件也在這裡成形。
第二到五分鐘：溝通，直白且盡早。在你的使用者真正在讀的渠道裡告訴他們：一家被點名的上游服務商正在發生事件，這在實際層面意味著什麼——什麼不能用、什麼還能用、他們的資料是否安全——以及你下一次更新的時間。在第四分鐘發出的一條誠實佔位訊息，勝過在第四十分鐘發出的一份精確解釋，因為沉默正是使用者用他們最壞的猜測和你競爭對手的名字來填充的東西。在內部，開一條事件線，指定一個人發言，並給一切打上時間戳；你在覆盤時會感謝自己，服務商的支援團隊在你需要他們時也會。
第五到十分鐘：停止讓它變糟，並準備軟著陸。凍結部署——在一場活躍的上游事件中做出的變更無法評估，甚至可能無法回滾。關掉對失敗服務商猛烈重試的激進重試和非必要任務；當一萬個用戶端步調一致地重試時，復原可測量地變慢，而且有些服務商會把你限流到第二場自找的故障裡。關掉或降級你的清單標記為可捨棄的軟相依性，有佔位頁就貼出佔位頁，然後沉下心來進入事件決定的節奏：監控服務商的更新、無論有沒有新聞都在承諾的時間更新你的使用者，並且除非事實變化否則不再改變任何東西。故障會在服務商的日程上結束，不在你的上面；你的十分鐘決定的是，你的使用者會把這件事記作他們服務商的倒霉日，還是你的。