一份處理宕機的應急響應入門指南

原標題：一份處理宕機的應急響應入門指南

作者 | Lawrence Jones

譯者 | 王強

策劃 | 萬佳

本文最初發佈於 byrayray.dev 網站，經原作者授權由 InfoQ 中文站翻譯並分享。

在職業生涯中，我跟事故彷彿“結下不解之緣”。也許，這是命運使然，或者我喜歡看到事物是怎麼出問題的。也許，罪魁禍首是我？不管出於何種原因，這種經歷給我很大幫助，讓我總結出一套應對事故的方法論。

從那時起，Matthieu 就時常鼓勵我向更多人分享這些理念。於是我接受了他的建議，寫下這篇文章。

如果你搜索過應急響應（Incident Response）這個概念，會發現有很多結果是關於應急角色（incident role）的。Atlassian 上有一些優秀的文檔很好地解釋了這些概念。

簡單來說：

• 應急角色可隨着你響應團隊的成長而幫助擴展應急規模。角色有助於分離職責，確保應急工作的各個方面都有專人值守。定義這些角色可以讓每個人都清楚自己應該做的事情，以及對彼此應有的期望。
• 有兩個角色是你必須關注的：

• 應急指揮官，是針對事故所採取措施的唯一聯繫人。他們不需要親臨一線採取行動，但是在重新啓動服務器之前，請先與他們做好確認。這樣就避免了某位好心辦壞事的同事說出那句經典的“糟了，我不知道你正在將數據庫還原到這個節點上”。
• 聯絡角色。這個角色是必不可少的，也是缺少結構化應急響應流程時最容易被遺忘的角色。你當然不能重蹈覆轍，而是要儘早任命某人來管理聯絡事宜，並確保所有響應人都主動分擔與他們的聯絡工作。永遠不要要求人們同時做調試和聯絡工作，這樣會分散他們的注意力，結果兩件事情都會搞砸！

• 文獻中還定義了其他許多角色，但是隻有當你的團隊對每個角色的含義有深刻的瞭解時，這些角色才能派上用場。我認爲，指揮官和聯絡人是至關重要的——在沒有足夠培訓的前提下增加粒度會擾亂應急工作，並削弱你的響應能力。

如果你對想要使用的角色感到相當滿意，並且你的團隊在所有角色上都有良好的實踐經驗，那麼你就邁出了高效響應的第一步。可是，現在有了各種角色，你的團隊該如何解決問題呢？

第一，快速找到流血部位

首先，找出流血部位（what is bleeding）。如果你可以儘早確定應急響應的範圍，就意味着你接下來的措施就更可能解決問題。

嘗試：

• 確定是哪些系統發生了故障，然後檢查各個依賴項，判定問題是由上游組件還是下游組件引起的；
• 一定要警惕假設。對於你從第三方獲得的所有信息，一方面給予信任，另一方面請務必驗證。記錄你所做的驗證工作，例如你運行的命令和運行的時間。錯誤的假設可能會讓你的響應偏離正軌，因此請盡力避免它們。
• 找到技術上的問題源頭後，請考慮做一些影響分析。不要因爲這部分工作而影響進度，但如果有人願意，請讓他們估計影響的範圍——哪些人受影響，人數有多少。對影響的不正確理解可能會導致錯誤的決定，而清楚地瞭解受影響的對象可以幫助組織的其他部分（客戶成功、客戶支持等）做出適當的響應。

一旦團隊理解了事故的性質，就可以開始止血（stop the bleeding）。換句話說，你的目標應該是儘快阻止當前的麻煩，並將清理工作推遲到壓力更小的時間段再做。

第二，確定行動的優先級

爲此，我們需要確定行動的優先次序，以儘可能取得最佳的成果。請注意“儘可能”這一短語：應該立即採取能夠迅速實施的例行補救措施，就算你懷疑它只能解決部分問題也無所謂。

這些措施包括：

• 回滾到一個確認沒問題的版本，就算你覺得自己很快就能寫好修復程序，也可以在回滾後壓力較小的情況下再徐徐而圖之。
• 採取措施保護關鍵系統，就算犧牲其他一些不太關鍵的流程也可以。如果某個端點導致整個系統出現故障，請在這個端點恢復了關鍵服務後立刻 no-op 掉它。
• 充分調動團隊，並主動應用你認爲風險較低的修補程序，就算你懷疑它可能無法解決全部問題也不怕：縮減不必要的隊列、凍結部署、重新啓動服務器。充分調動人力就可以快速做嘗試，前提是其他響應者要繼續分析問題的根源，同時假設簡單的修補會無濟於事。

這樣你就應該大致瞭解自己的團隊應該做什麼事情了。現在的問題是，他們應該如何協作來執行這些任務呢？

第三，使用高效率工具、創建應急文檔

鑑於溝通交流在應急響應工作中的重要性，你需要一款高效率工具來傳遞即時消息並記錄操作日誌。

可以使用 Slack（或其他有着相同功能的軟件）：

• 在任何事故中，第一項操作就應該是創建一個消息頻道。有很多工具（monzo/response、Netflix 的 Dispatch）可以爲你自動創建它（還有很多其他東西），但就算你得自己手動完成這一步，也一定不能跳過它。爲了準備好這個通道，多花費一分鐘的停機時間也是值得的。
• 我堅決反對私有應急響應頻道。公司內部使用的公共通道可以提升信息訪問的便捷性，從而加強你的響應能力。這樣可以避免很多會讓你頭痛的協調（有一次，我見過兩支彼此獨立的應急團隊在處理同一個事故，但他們之間根本不知道對方的存在……）
• 每當你要執行破壞性操作（例如運行一條命令或重新啓動某些資源）時，請向頻道發送告知消息。這不僅可以讓整個團隊提高警覺性，而且爲善後階段編寫事故日誌提供了寶貴的記錄。

即時消息非常適合用來傳遞帶有時間戳且不應更改的信息。對於你希望隨着應急工作的進展而調整的內容，請在你喜歡的協作編輯器中創建一個應急文檔（Google 文檔、Dropbox Paper、Notion 等）：

• 你的組織可以草擬一些包含所需結構的應急文檔模板：也許你有報告職責，或者有特定的溝通流程？全都放在這裏，這樣只需點擊一下即可從這些模板創建文檔。
• 特別是針對大規模事故的應急工作中，應急團隊會有人員輪換，這時候這些文檔可以充當人員進入應急團隊的切入點。讓管理通訊的人員來管理這些文檔、維護一份重要事件的時間表，甚至在事故特別複雜時起草一份執行摘要。
• 讓你的技術團隊將代碼段或相關日誌行貼到文檔附錄中，這樣每個人都可以對齊同一份應急工作的中心視圖。

聊天記錄和應急文檔結合在一起能成爲強大的工具組合，可以幫助協調響應團隊，同時爲視察工作的投資者提供透明度。還有一點好處是，等到塵埃落定，可以很容易地將這些內容重塑成一份善後報告。

第四，注意人爲因素

最後，也是最重要的是人爲因素。人們在承受壓力時會做出錯誤決定，而沉浸在應急工作中會讓你完全忘記照顧自己。在這方面，你應該以身作則，並強硬地要求你的團隊成員照顧好自己的身體狀況。

這裏要考慮的一些事情：

• 減輕壓力的一種有效方法是休息，遠離屏幕，然後深呼吸。主動帶領你的團隊和你一起停下來，這樣就會減少匆忙之間搞砸事情的潛在風險。
• 一般來說，只要出現以下情況就暫停一下：

• 有人呼你。不必太長；僅僅十秒的呼吸就能提醒你的身體一切盡在掌握，並降低腎上腺素水平。
• 當生產故障停止時。警報平息並且情況看起來穩定後，請讓整個團隊休息一下。大多數事故都需要很多後續工作：在開始這些流程前，請讓自己休息至少 15 分鐘。
• 跟蹤過程中，在開始執行任何類型的流程之前，例如“X 羣集的恢復”。讓大家在開始做任務列表前先呼吸些新鮮空氣，讓每個人都能回點血，避免流程出錯或超時。

• 一定要對應急指揮官做好培訓，讓指揮官及時撤出精疲力盡的響應人員。一項重要的工作是在人們飢腸轆轆之前訂好外賣。也許應急響應團隊會大聲抗議，說他們根本用不着喫飯，可是等外賣上桌了，你就會看到他們狼吞虎嚥的樣子了。

這份列表缺失的內容還有很多，但你可以把它當作一個入門包，也可以作爲經驗豐富的人員在制定應急響應流程中關鍵環節時的一個參考。

只要記住：深吸一口氣、關照好同事、批判系統而非人員、不要着急。祝大家好運！

這篇文章中缺少對善後分析、事故發生前的準備工作，以及在安全性、數據完整性、可用性之間如何權衡的內容。如果你有興趣聽取我對這些觀點的意見，請在 Twitter 上聯繫我，我很高興與你分享。

原文鏈接：

https://blog.lawrencejones.dev/incident-response/index.html

微軟、思科等企業源代碼被黑客在線售賣，打包價100萬美元

海外IT老兵談996：人才不是加班加出來的，期待有企業能站出來破局

InfoQ 寫作平臺歡迎所有熱愛技術、熱愛創作、熱愛分享的內容創作者入駐！

還有更多 超值活動等你來！

填寫申請，成爲作者

開啓你的創作之路吧~

點個在看少個 bug👇