事件回應的重要性

根據此學習路徑另一個課程模組中所討論的監視原則和做法，您現在將瞭解監視顯示問題時該怎麼做。 若收到可採取動作的警示，通知您系統並未如預期般運作，便是進行回應以處理問題的時機。

什麼是事件？

事件回應是關於事件發生時所採取的動作，但究竟是什麼構成事件？ 答案可能是主觀的;即使是所有工程師也不同意事件是什麼。 如果您詢問不同產業和組織的問題，您會得到許多不同的答案。

有些會將所有中斷標示為事件，無論客戶是否受到影響。 在此課程模組的內容中，我們可以同意事件定義為服務中斷：發生或狀況會影響使用者使用所依賴之服務的能力。 範例包括當系統宕機或故障影響客戶時。

什麼是事件回應？

防止所有問題都是值得稱讚但不可能的目標。 事情 會 出錯，因此我們需要一個計劃來限制對終端用戶的影響，並儘快將作業回復為正常。

關鍵是 緊急回應 ，而不是反應。 反應往往更衝動，基於目前時刻，而不考慮長期影響。 回應已妥善考慮、組織及以資訊為基礎。

您的事件回應策略決定了您的成效：

• 了解當前情況（問題診斷）
• 分級 (判斷急迫性) 並列出問題的優先順序。
• 吸引適當的資源來減輕問題。
• 與利益相關者溝通有關問題。

補救問題之後，您就可以透過事件後檢閱程式從事件中學習。 這是一個重要的主題，需要另設一個獨立的模組來討論。

測量事件回應效能

您可能熟悉縮寫 TTR，其被定義為「復原時間」、「補救時間」或「還原時間」。所有這些變體都是指相同的內容：您把服務帶回一個可以回到符合客戶期望的地方所花費的總時間。

此計量是測量小組在回應事件時表現良好的方式之一。 復原/補救/還原服務越快，中斷或降級服務的影響就越小。

請務必瞭解貴組織處理事件回應的方式。 DevOps Research and Assessment 組織每年都會發佈 DevOps 狀態 報告。 2019 年報告中的一些重要發現著重於事件回應效能。

• 報告將能在不到一小時內偵測、回應和補救服務中斷的工程小組分類為「精英或高效能者」。
• 那些在24小時內能夠從事件中恢復的人被歸類為“中型表演者”。
• “低效能者”是那些需要一周到一個月的時間才能從服務中斷中恢復的人。

這些層級之間的差異相當顯著。 研究發現，精英/高效能團隊從事件中恢復的速度比他們的“低表現”同行快2,604倍。 菁英/績效優異者部署到生產的頻率也高了 208 倍。

為什麼精英表演者的反應和恢復速度比其餘的要快得多？ 這至少部分是因為他們明白，在事情不可避免地出錯時，已經備妥良好的基礎響應計劃的重要性。

當您完成本課程模組時，您將瞭解事件的特性和生命週期，以及如何使用該知識來建立您自己的基礎計劃。