事件的事後調查

事件的事後調查

譯自：Anatomy of an Incident。看完整篇文章，最多的感觸是一個好的SRE(或者其他角色)需要一個好的企業文化，很多時候壓力並不能成爲解決問題的動力，反而會成爲問題解決的絆腳石，甚至成爲員工換工作的動力。

簡介

毫無疑問，接下來將是個人和職業上充滿壓力的N周，有時我們會爭先恐後地趕在事態發展之前。十多年來，我們一直在爲危機做準備，我們已經做好了準備。在全世界人民比以往任何時候都更需要信息、通信和計算的時候，我們將確保谷歌能夠幫助他們。--—Benjamin Treynor Sloss, Vice President, Engineering, Google’s Site Reliability Engineering Team, March 3, 2020

失敗是不可避免的。作爲科學家和工程師，你會着眼於長期問題，並將系統設計爲最具可持續性、可擴展性、可靠性和安全性。但你設計的系統只是基於現有的知識。在實現方案時，並不會知道未來會發生什麼。你不能總是參與下一個zero-day事件、病毒式媒體、氣候災難、配置管理錯誤或技術轉換等。因此你需要準備好迎合應對這些事情，以及這些事情對系統造成的影響。

近十年來，谷歌最大的技術挑戰之一就是由COVID-19引發的。該病毒引發了一系列的緊急事件，我們需要通過處理這些事件來繼續服務客戶。爲此，我們不得不大力提高服務能力，提高在家辦公的生產力，並通過新的方式來快速恢復服務(儘管受供應鏈的約束)。正如Ben Treynor Sloss所述，在這種顛覆式的事件之下，谷歌能夠繼續服務全球的原因是我們已經爲此做好了準備。十多年前，谷歌已經前瞻性地調研了事件管理。這種準備提高了祖師對事件的彈性。準備可以增強應變能力。彈性和處理故障的能力成爲從長期(如十年)角度衡量技術成功與否的關鍵因素。除了成爲最好的工程師，你還需要做好處理故障的準備。

彈性是公司運營的主要支柱之一。在這方面事件管理是一個強制性的公司流程。事件很高昂，不僅僅是對客戶的影響，也給運維工作者帶來了沉重的負擔。事件會產生壓力，通常需要人工介入。有效的事件管理會將預防性和主動性工作優先於反應性工作。

事件管理伴隨着壓力，而且很難找到和培訓響應者。有些意外是不可避免的，故障總會發生。預期問"如果發生事件，你該如何處理？"我們更傾向於問"發生事件時你是如何處理的？"，這種方式減少了歧義，不僅可以減少人力和響應者的壓力，還可以縮短解決時間，減少對用戶的影響。

該報告作爲技術事件響應事件指導。一開始，我們會使用通用的語言來討論事件，然後討論如何激勵工程師、工程師領導以及管理人員如何考慮組織內的事件管理。我們的目的是涵蓋從事件準備、事件響應以及事件恢復到保持組織健康(使其保持戰鬥力)的方方面面。

什麼是事件

事件是一個加載項。其具體含義取決於使用它的組織。例如在ITIL，一個事件就是一個非計劃內的中斷，如問題單、bug、或告警。無論如何使用該名詞，最重要的是要根據具體的定義進行調整，以降低筒倉，確保每個人都能夠理解到相同的含義。

在谷歌，事件爲：

• 可升級的(表示無法獨立處理)
• 需要立即響應
• 需要有組織地響應

有時事件可能是由於中斷引起的，導致一段時間內服務不可用。中斷可以是計劃內的，如爲了系統升級，在一段服務維護窗口內，該系統不可用。如果中斷是計劃內的，且通知了用戶，那麼它就不是一個事件--即不需要立即且有組織地作出響應。但更多是由於非期望的故障導致的非預期的中斷。大部分非預期的中斷都是或都會成爲事件。

事件會困擾客戶，可能會導致收益損失、數據損壞、違反安全規定等等，這些事情會給你的客戶帶來影響。當用戶感受到事件的影響後，可能會影響到客戶對你(提供商)的信任。因此需要避免產生"過多"的事件或"過於嚴重"的事件，來讓客戶滿意，否則他們就會離開。

過多的事件也會影響到事件響應者(處理事件也是有壓力的)。僅僅爲了應對事件而去尋找具備多項合適技能的SRES，這種方式既困難且成本也很高。相反，你應該給他們提供機會，通過主動緩解事件來提升他們的技能。後續我們將討論這一點，通過某些方式來降低壓力並提升on-call輪換的健康度。

不是所有事情都是事件

區分事件和中斷很重要。此外還需要區分指標、告警和事件。你如何對指標和告警以及告警和事件進行分類？並不是每個指標都會成爲告警，且並不是每個告警都會成爲事件。爲了幫助你瞭解這些術語的含義，我們會討論維護系統健康的監控和告警的角色。

監控

持續觀察系統監控的最常見的方式是通過監控，Google SRE Book中將監控定義爲：採集、處理、聚合和展示系統的實時量化數據，如請求量和類型、錯誤量和類型、處理事件以及服務生命週期等。監測是一種測量。

在測量方面，我們建議採用一種以客戶爲中心的方式來設定SLOs(，見下文"降低事件的影響")以及客戶體驗。這意味着採集的指標是那些能夠反映用戶體驗的指標和各種度量值，如black box、基礎設施、客戶端以及應用指標等。由於不同的度量方法具有不同的優勢，因此可以採樣不同的方式來度量相同的值，以此保證冗餘和準確性。以客戶爲中心的儀表盤也可以作爲客戶體驗的指標，且對於故障排除和調試事件來說至關重要。

還需要注意的是，應該去關注如何衡量可靠性以及對用戶的影響，而不是已經宣佈的事件數。如果關注了後者，人們可能會因爲畏懼懲罰而不願宣佈事件。這可能會導致延遲事件宣佈，不僅僅會造成時間和數據採集上的浪費，還會影響事件管理協議的可追溯性。因此，最好的方式是宣佈並關閉某個事件，而不是進行事件追溯。

在這一點上，人們經常會混用"可靠性"和"可用性"，但可靠性的要求要遠大於可用性，特別是在複雜的分佈式系統中。可靠性是指大規模提供一致服務水平的能力，包括不同的方面，如可用性、延遲和準確性等。不同的服務中可能代表不同的含義。如YouTube和Google Search中的可靠性是否一樣？可靠性的具體含義取決於服務和用戶對服務的期望。

一般來說，具有更少、更短和更小中斷的系統的可靠性更高。因此，歸根結底，就是用戶願意忍受的停機時間。由於採用了以客戶爲中心的方式，因此用戶就定義了你的可靠性，所以需要儘可能仔細地衡量用戶體驗(後續在"降低事件的影響"中細談)。

告警

我們已經討論了使用監控來觀測系統健康。現在討論監控的關鍵組件：告警。當監控到非預期的行爲時，它會發送一個信號來表示發生了某個不正確的事情，該信號就是告警。一個告警意味着兩件事情之一：有東西壞了，需要有人修理；或有東西快壞了，需要有人看看。緊迫感--意味着當需要採取某個動作時，需要直接選擇如何應對。如果需要立即（人工）操作，則應該發送一個頁面。如果在接下來的幾個小時內需要人工操作，則應該發送一個告警。如果不需要任何動作，即需要通過拉取模式獲取需要的信息，例如用於分析或故障排除，則以度量或日誌的形式保留信息即可。

注意，根據不同的組織偏好可能會有不同的告警模式，例如，可以通過儀表盤或問題單的形式呈現。在谷歌，通常選擇後者，監控系統會在 Google Issue Tracker中打開不同優先級的"bug"。

現在我們已經瞭解了基本概念，下面深入討論一下可操作的告警(actionable alerts)。

可操作告警的重要性

正如前面提到的，當發生特定條件時會觸發一個告警，並僅針對那些關心且可操作的內容進行告警。考慮如下場景：作爲活躍的on-caller，你在凌晨2點被呼叫起來處理某個告警，原因是過去5分鐘內的QPS增加了300%。有可能這是一個突發服務，即一段時間內流量穩定，但隨後一個大客戶來了，並在很長一段時間內發出數千條查詢。

此時半夜爬起來的價值在哪裏？沒有價值。該告警並不可操作。由於此時並不會導致服務故障，因此並不需要將任何人從牀上拉起來。查看服務的歷史數據可以看到，服務能夠處理這種峯值流量，但這種流量並不會產生問題，因此也不需要生成任何告警。

現在看一個更微妙(且更常見)的可操作告警的版本。你的公司每晚需要對生成數據庫進行備份，因此你配置了一個cronJob，每4個小時進行一次備份。有可能會因爲支持備份的副本出現事務錯誤(出現硬件故障)而導致運行失敗，負載平衡器會自動將該副本移出服務模式，並完成後續的備份。

沒有必要由於某個備份的錯誤而創建問題單，這樣會導致噪音(系統會在無人爲介入的情況下自動恢復)。

這類情況經常發生，且僅僅通過"在我處理時一切正常"就簡單地關閉問題單，這種方式本身是有問題的，原因如下：

• 辛苦

  需要有人花時間查看問題單，查看圖標，並確定是否需要處理該問題。

• 警惕性疲勞
  如果95%的"數據庫備份失敗"都被簡單地關閉，那麼有很大概率會忽視真正的問題。

正如前面討論的，事件是一個具有特殊特徵的問題。一個告警用於指示某個正在發生的事件。你可能接收到很多告警，但沒有產生任何事件。這種情況下並不意味着你需要執行正常的事件管理技術，這可能只是一個計劃中的維護事件(event)，且在維護過程中本來就會接收到這些告警。

有時候會產生事件，但沒有產生告警。例如可能是安全團隊向你通報，他們懷疑你的生產系統遭到破壞。這種情況下，你的團隊不會接收到觸發的告警。

更實際地說，人類對告警和事件的感知存在差異：

• 與簡單地修復警報相比，正式的事件管理的壓力要大得多。
• 相比經驗豐富的響應者，經驗少的響應者更不願意調用事件
• 事件更可能需要額外的團隊資源，因此沒有響應者可以更容易地判斷他們是否需要儘早關注活動的問題。

這不僅適用於你的團隊。事實上，它適用於整個組織。

通常你接收到的告警要遠多於事件。獲取告警的基本指標很有用(如每15分鐘接收到多少告警)，但事件值得一探究竟(如過去15分你接收到了5個主要事件，所有事件都是因爲推出了一個生產前未經過充分測試的特性造成的)。你不想用收到的所有警報污染這些報告。考慮一下相關的觀衆--指標主要用於團隊，而事件報告則可能會給提供給上級且需要確定合理的範圍。

希望這些能讓你更自信地說，"這不是一個事件"。但這句話可能會被一分爲二：如果某些事不是事件，這意味着某些事情是事件。你應該如何處理這些事件？請看下節介紹。

事件管理生命週期

理想的事件管理並不僅僅意味着快速管理事件。好的時間管理需要關注事件的整個生命週期。在本章中，我們會討論一種程序化的方法來管理事件。將事件認爲是系統中存在的持續風險。處理這類風險的過程稱爲事件管理生命週期。事件管理生命週期包括準備、響應、恢復和緩解事件的所有必要活動。這是服務運維的持續成本。

生命週期是指事件存在的每個階段，圖1-1展示了這些階段：

• 準備
  圍繞一個公司或團隊爲一個事件的發生所作的準備動作。可能包括工程安全措施(代碼監視或回滾過程)，事件管理培訓和爲識別錯誤而進行的實驗或測試，也包括配置的監控和告警。
• 響應
  當觸發的告警變成問題時，就會發生這種情況。涉及響應告警、決定該問題是否是一個事件、以及聯繫該事件影響到的人。
• 緩解和恢復
  這是系統將其恢復到正常狀態需要採取的一系列動作。包括緊急緩解措施，避免影響或影響擴大化。恢復包括問題事後調查涉及的系統分析和反思。一次分析對應一個事件報告，包含採取的動作、影響、根因和後續防止重新發生以及/或降低影響的措施。

一旦完成恢復階段，你又回到了準備階段。根據技術棧的大小，所有這些階段都可能同時發生，但可以肯定的是，至少有一個階段總是會發生。

事件響應的準備練習(準備)

上面我們討論了事件管理的階段以及事件管理生命週期。下面瞭解如何進行事件管理演練，以便爲真實事件做好準備。

災難演習和事件響應練習

可以通過測試和事件響應練習準備來提升彈性。推薦在團隊中進行災難角色扮演來訓練事件響應。在谷歌我們將此稱之爲 Wheel of Misfortune，通過重建過去在生產環境中遇到的事件來進行演練。

定期進行事件響應練習有着明顯的好處。在早期的谷歌災難恢復能力測試(DiRT)項目中，有些測試被認爲因風險太大而無法執行。這些年來，通過重點關注那些因風險太大而無法運行測試的領域，使得很多風險都得到了徹底的解決，以至於現在的測試被認爲是自動且是無趣的。

做到這一點並不容易，它需要很多團隊花費很多精力才能達成，但我們已經實現了通過"只需定期自動化運行測試"的方式大大降低了全局系統中存在的風險。

定期測試

定期進行測試可以帶來明顯的好處。多年來，谷歌通過運行DiRT測試來找出並修復生產系統中存在的問題。由於團隊一直在測試他們的服務，因此高風險測試的數目會有所減少。這是個好的跡象，即由於系統更具有彈性，因此更難發現系統的缺陷。

測試可能會由於某些原因而失敗，但這種情況也變得越來越少。即使發生了，這些系統也會按照預期的方式失敗，並很快得到修復。這樣響應者也可以更放心地激活應急程序，並在壓力下保持鎮定。通過測試結果，可以減少事後調查的過程。經過多年的付出，思維方式已經從"災難測試是我該做的事"演變爲"災難測試是我們一起做的事"。

微妙的測試和自動化

測試正在慢慢從解決純粹的技術問題(如"我們如何恢復完全崩潰的數據庫")轉變爲一系列更加微妙的"讓我們修復流程"的挑戰。

技術測試更容易討論和自動化：歸根結底就是編寫一些代碼來實現一系列命令並檢查結果是否符合預期。與之相比，找出流程問題則更加困難，例如可能出現"只有一個人可以授權這件事，但他沒有回覆電話/郵件"的情況，尤其是那些不經常執行的流程。

準備響應者

執行事件響應測試(即便只是理論上的)，也可以幫助識別這些流程，給這些流程分配概率和風險因子，並給響應者注入信心。即使是非計劃內的特定測試，也可以瞭解到你的事件響應流程中的缺陷。響應者最好也做好任何時候處理真實事件的(技術、心理和情緒上的)準備。

不能忽視情緒上的準備。正如前面提到的，事件管理可能會給開發者帶來極大的壓力。壓力可能會導致不良響應，如失察、響應慢和判斷模糊。還會引起焦慮、疲憊、高血壓和睡眠不良等健康問題。

通過事件響應測試不僅僅可以爲個人降低不良影響，更重要的是，可以通過識別這些影響，並作出正確的動作，如請求外部幫助，休息一下，甚至完全交接一件事件。管理者和其他領導崗位上的人應該持續關注響應者的壓力/疲勞/倦怠上的跡象，並儘可能給予幫助。

編寫事件響應測試

編寫一個好的事件響應測試的開端是查看最近的事件。在谷歌，我們在事後調查時會問到以下標準問題：

• 哪裏出了問題？
• 什麼是正確的？
• 哪裏做的比較好？

從觀察哪裏出了問題開始，因爲這是比較清晰的且需要提升的地方，通常是需要修復的具體問題，如你的監控發現了一個問題，但沒有通知任何人。在確定並修復該問題之後需要對此次修復進行驗證。有一點無需過分強調：僅僅修復一個問題是不夠的，有可能問題並沒有被完全修復，且修復該問題會導致其他地方出現問題。在通過一些小的、相對簡單的測試驗證了正確性之後，隨着對流程信心的增加，你可以開始關注那些更復雜的問題，包括那些不完全在技術範疇內的過程(如人力處理過程)。

在小範圍內的驗證執行一段時間之後，開始考慮"哪裏做的比較好"。通常這些問題都比較微妙，且解決它們並不那麼容易。可以將這些問題分爲更小、更易解決的項。

這些測試應該保持緩慢但穩定的節奏--你不會想讓團隊都投身到這些測試當中，當然也不想放棄這些測試。比較簡單的方式是每4個星期執行一小時的測試，而不是花費10%的運維精力去執行這些測試。隨着流程的完善以及測試價值變得更清晰，你會找到一個合理的模式來決定多久執行一次測試，以及執行的力度。

擴展時間管理(響應)

我們已經通過事件響應練習、角色扮演和常規測試討論瞭如何練習事件響應準備。這些策略可以幫助你在遇到真實事件時做好準備，並對事件進行管理(參見"建立一個事件響應流程")。但如何在組織增長的同時管理事件？本章我們將討論如何擴展事件管理。

在谷歌，我們爲所有系統提供了最優的事件管理範圍。谷歌的規模很大，爲了支持每年2萬億的請求，我們使用了很多數據中心，至少1百萬臺計算機，以及8萬多員工。所有這些活動都會經過一個龐大且高度互聯的系統體系(SoS)，嚴重依賴該技術棧進行生產活動。對該技術棧的支持意味着需要有合適且可靠的人員，以便在問題出現時能夠及時定位和修復。這些人員來自我們的SRE組織，他們爲特定範圍的系統提供了事件管理，並在發生事件時進行響應。

組件響應者

在SRE組織中，有一類響應者，稱爲組件響應者，用於on-call谷歌整體基礎設施中的某一個組件或系統。

組件響應者是精通問題空間的單系統專家，是專業的問題解決者，擅長在出現危機時實施緩解策略。他們會持續訪問工具/系統來執行應急響應、妥善處理壓力並在危機期間保持清醒的認知。

單個件響應者的職責範圍比較有限，這使他們能夠深入瞭解自己所在的領域以及可能影響該領域的系統。這些響應者是防止故障從一個組件串聯到整個棧的第一道防線。單個組件要遠小於整個SoS棧，通常有清晰的系統邊界。因此可以設置合適的監控和告警，這樣組件響應者可以持續瞭解到系統的故障類型。

當技術棧發展到一個人無法理解和維護的狀態時，我們會切割技術棧，這樣就可以引入多個響應者，每個響應者負責整體棧的某個組件。隨着時間的推移，這些組件也會變得越來越複雜，然後再作進一步切分。通過維護一個有限的範圍，主響應者可以在給定時間內解決更小範圍內的問題。但這種響應方式存在不瞭解跨多組件、多系統的風險，或由於問題超出了他們的專長，因此特定組件響應者無法提供足夠的支持。

例如出現了一個串聯多個技術棧組件的底層問題，且這種串聯速度要快於人員自組織的速度。在事件影響擴大的過程中，我們可以快速達這樣一種狀態：每個組件團隊都接受到通知，並分派響應者來維護其組件狀態。這些組件團隊是並行工作的，但有可能這些響應者並不知道其他響應者的存在。可能某個響應者的事件是問題根因，其他只是該問題的後果，但如何確定是哪一個？

由於技術棧足夠大且複雜，單個響應者極有可能無法緩解並維護其所有依賴關係及其依賴項的狀態。爲了緩解這種風險，我們在組件響應者之外構建了一個二級響應者結構。在谷歌，我們將這些二級響應者稱爲SoS響應者，見下一節。

系統體系(SoS)響應者

系統體系(SoS)響應者是出現跨組件系統的事件、跨系統邊界的事件或事態變糟糕時的事件響應者。SoS響應者經過適當的培訓，級別比較高，並有權領導有組織、有配合的響應。這些響應者是第二道防線，關注點也更加全面，可以在響應分佈式計算故障時體現其關鍵優勢。

我們將SoS響應者認爲是多系統事件管理者和多面手，其關注範圍也更全面。他們擅長在更廣的視角下處理一系列事件。通常這些事件會涉及多個團隊，例如某個主要的SoS故障會導致很多服務下線，這些事件會導致會已經導致了下游故障，並有可能擴散到服務邊界之外，此外，還可能是持續30分鐘或更久都沒有解決的影響到客戶體驗的事件。

SoS響應者可以很好地處理這類影響廣泛的事件，因爲他們知道如何組織其他人並在複雜情況下下達命令。他們還知道如何診斷系統行爲並確定問題根因，專注於擴大響應範圍，並就事件進行廣泛的溝通。

在谷歌，我們有兩種類型的SoS響應者，每種類型都有不同的功能，通常是互通的：

• 注重產品的事件響應團隊(IRTs)：
  用於保證特定領域的產品穩定性的事件響應團隊。例如，Ads IRT 和 YouTube IRT。不是每個產品領域都有事件響應團隊，但如果產品不斷迭代更新，且越來複雜，並且產品之間有相似的技術債，則有必要引入IRTs。這些團隊不會知道每個產品棧的技術細節，但他們瞭解產品的整體運作和依賴情況。
• 技術事件響應團隊：
  這是關注面最廣的事件響應團隊。該團隊主要關注那些跨多個產品，職責不明確，或有不清楚和普遍問題根因的事件。Tech IRT的成員是谷歌的終身員工，他們至少在兩個不同的團隊中擔任過組件響應者。他們知道系統是如何運作的，更重要的是他們擁有出色的事件管理能力。

Tech IRT的成員會持續負責他們自己的組件，但也會提供全球範圍內24*7的輪崗支持。由於練就了這種特殊技能，使得他們可以在出現重大緊急的情況下保持正常工作。

Tech IRT的成員每年會進行兩次兩週的產品培訓，涵蓋了產品的運作(故障)細節。每季度還需要展示如何使用應急工具來保證高效工作的能力。

下圖描述了谷歌的事件響應組織架構。該架構的每一層都對應一個產品(日常功能的複雜細節)的抽象層。這裏面的每個角色都同等重要--該金字塔的每個後續級別角色接收到的事件通知也會隨之減少。如果一個組件響應者無法解決該問題，且會影響到產品的穩定性，則可以升級到其他角色：關注產品的IRT。

如果一個問題威脅到了多個產品，或可以通過共享基礎設施來快速緩解該問題，此時將激活Tech IRT，並在最廣的範圍內處理該問題。Tech IRT作爲其他所有層級的升級點。
那麼如何讓這種組織架構無縫運作？答案是共同的協議、信任、尊重和透明度。接下來了解一下這些內容。

事件響應組織結構

成功的事件響應組織有四個特點：共同的協議、信任、尊重和透明。

共同的協議

在谷歌，我們內部廣泛使用了一個聯邦應急管理局事件指揮系統(ICS)的變體，它定義了事件響應者的角色，如事件指令、記錄和通信。通過一個共享且清晰的流程，我們形成了一個正向的應急響應習慣，包括維護活動狀態，清晰的指令鏈以及降低整體的壓力。每個人都需要了解交接過程，包括誰交接給誰，保證高效的知識傳承。一個棋手不能把主教丟在麻將桌上並保證每個人都知道如何使用它--在緊急情況下，重要的是讓所有玩家都參與進同一個遊戲。

信任

在一個事件過程中，事件施令者需要掌握一定的權力。他們需要引導他人，組織混亂的力量，並對適當的行動方案做出判斷。對於大部分組織，讓權力與運營職責相一致是一件具有挑戰性的事情，但我們標準的操作流程避免了這種只有上級業務領導才能夠授權改變服務的情況：我們將此權限授予具有相關背景的問題專家。

尊重

當響應者覺得有必要升級時，他應該放心地去執行升級流程。如果響應者在不斷升級的事件中受到審查、批評或不稱職的感覺，那麼他可能會在需要升級的時候不去升級。除了一般的禮貌，我們必須相信，考慮到擺在他們面前的信息，他們能夠做出最好的決定。如果事情出現錯誤，關鍵的問題不是讓某人感到難過，更重要的是如何創建更精確更可執行的信息來避免未來出現類似的事情。谷歌SRE成功的部分原因是在事後調查過程中，谷歌堅持嚴格的無過錯政策(稍後將對此進行詳細介紹)。

透明

我們沒有筒倉心態。當一個事件發生時，任何人都可以看到其細節。如果我們不讓其他人訪問事件信息，就無法進行升級和協作(在事件解決之後，我們會在自己的每週簡訊中對事件進行事後調查)。我們鼓勵通過閱讀其他團隊或產品領域產生的事件來交互學習。

管理風險

除了事件響應組織結構的特徵，還需要考慮如何管理風險。確定並解決事件的時間不應該超過3天。正如前面提到的，事件管理在時間和人員上都比較昂貴。如果你長時間處理活動時間的管理中，就會導致疲憊和倦怠，還有可能會考慮換工作。需要升級的事件需要進行及時且有組織的響應。這種及時並不是一種自然狀態--人們不應該讓延髓受到那麼長時間的刺激，也不應該讓皮質醇在體內持續那麼長時間。如果史前人類一直在打獵或被劍齒虎獵殺，卻從未感到安全或有時間休息，那麼我們的進化就會大不相同。如果你希望在戰鬥或逃跑模式下花費大量時間，那麼很自然地，這種情況最終會導致你的團隊不斷流失。

事件管理和風險管理的功能

爲了最小化花費在事件管理模式中的時間，需要識別事件管理和風險的功能。事件管理是一個短期經歷，目的是爲了快速修正一個存在的風險。一個事件的級別可以分爲幾種簡單的類型。在谷歌，我們針對我們組織的產品對這些進行了適當的量化(見下表)。

風險	定義	litmus test
Huge	重要的面向用戶的故障，可能會給谷歌的收益或谷歌的客戶帶來不良新聞或重大影響。當出現一個內部產品故障時，只有當它導致可見的外部後果時纔會被認爲是Huge的，如負面新聞。	它是否損害了Alphabet/Google b的品牌或業務。
Major	對用戶可見，但最終沒有損害到谷歌的服務或客戶，或沒有對谷歌或其客戶造成重大損失，或沒有影響到50%或更多的谷歌內部人員。	如果未來反覆發生可能會損害Alphabet/Google的品牌和業務
Medium	差點導致huge/major故障的事件。影響到內部大量用戶。但存在解決辦法，且用戶知道如何降低影響度。	這種反覆發生的、未緩解的事件可能隨着時間的推移導致不穩定性增加，並增加生產維護成本。
Minor	內部用戶可能不會注意到該故障。可能會給內部用戶造成不便。結果會導致實體(網絡、數據中心、實例)之間的流量波動	這種反覆發生的、未緩解的事件不太可能會隨着時間的推移導致不穩定性增加，但代表正常運行條件。
Negligible, Trivial	這種事件對用戶不可見，且對產品的影響度很小。但可以吸取寶貴的經驗教訓，後續動作需要以低優先級進行跟蹤。	這種反覆發生的、未緩解的事件不應該認爲是進程崩潰
Test, Ignored	可能並不是一個事件	不產生告警

事件的規模大致對應評估的"風險"(根因/觸發/影響)。事件管理可以短期緩解其造成的影響，併爲組織中的當權者爭取一定時間來決定下一步應該做什麼。由於事件被定義爲"X是一個問題"，且"應該由某人去處理"，事件響應傾向於通過緩解短期影響來做出長期決定。 但這並不意味着在消除短期和長期影響之前應該繼續進行事故管理。根據技術棧的規模或技術債的量，可能會花費數月甚至數年來完全矯正產生問題的根因。只有在事件處於"開啓"狀態時纔會激活事件管理，直持續到短期影響被緩解。在醫院中，類似的方法是評估出血患者當下存在的風險，然後及時止血。

那麼下一步是什麼？在醫院中，下一步是找出什麼原因導致了出血，以及如何防止再次出血，這可能涉及幫助病人構建一個長期計劃來避免再次收到傷害，或僅僅涉及治療導致傷口的皮膚病。無論哪種方式，一旦避免了當下的危險，就需要做長期計劃，包括短期的全天候支持，如果需要，還需要落實到位，確保病人安全，並防止再次出血。類似地，在你的技術棧中，一旦避免了當前的風險，則需要轉向長期動作。

在事件管理中，你可以經常爲事件創建以分鐘計數的時間線。如果你正在處理一個活動且緊急的問題時，每分鐘都會反映到受影響的用戶或遭受的經濟損失。由於每分鐘都很關鍵，因此事件管理會給事件管理者帶來很多壓力，因此，正如本章開頭講的，它並不是一個長期的正向體驗。當你在處理事件的長期後遺症時(解決問題根因或誘發原因)，理想況下，不會立即對用戶造成傷害或造成重大經濟損失。這就給你留下了一些高優先級的工作，這些工作仍需立即執行，但不需要使用與事件管理相同的方式執行。此時的時間線最好以天或周爲單位，且不需要在推薦的事件時間內完成(3天)。不要讓自己保持在"戰鬥或逃跑"模式中，關閉你的事件，然後繼續恢復這些事件。

緩解和恢復

我們已經討論瞭如何擴展事件管理，以及如何使用組件響應者和SoS響應者來幫助在公司規模擴展時管理事件。此外還涵蓋了一個成功的事件管理組織的特性，並討論了管理防線以及如何避免on-call疲憊。這裏，我們將討論如何在事件發生後進行恢復。首先關注緊急緩解措施。

緊急緩解措施

前面我們已經鼓勵如何在一個服務事件中"止血"，我們建立了恢復措施，包括緊急緩解措施來避免影響或避免影響升級。下面讓我們來談談這意味着什麼以及緊急情況下的一些提前緩解措施。想象一下你的服務很糟糕，故障已經產生，並探測到該故障正在影響用戶，而你正是事件的負責人。此時第一優先的總是降低或減少用戶影響，而不是弄清楚什麼導致了問題。假設你在一個屋子裏，而屋頂開始漏水。你做的第一件事可能就是在滴水出放一個桶，防止水患。(我們後面會看到，如果屋頂問題是根因，雨就是觸發因素)。在屋頂修復以及天氣變晴朗之前，桶可以降低漏水帶來的影響。爲了在服務故障下停止或降低對用戶的影響，你需要準備一些桶。我們將這些比喻的桶稱爲通用緩解策略。

一個通用緩解策略是一個在你弄清楚需要修復什麼之前，爲降低故障影響級別所採取的動作。

適用於服務的緩解策略各不相同，具體取決於對用戶的影響途徑。一些基本的策略如回滾二進制文件、清除或重定向流量或增加容量。這些"創可貼"的目的旨在爲你和你的服務時間買單，以便能夠找到一個有意義的修復方案，從而完全解決潛在問題。換句話說，你修復了故障的症狀，而非產生症狀的原因。在使用通用緩解策略之前，你不需要完全理解故障本身。

可以考慮做一些研究並調研部署一些快速修復按鈕(比喻的桶)。記住，桶這是個簡單的工具，可能會被誤用。因此，爲了正確使用通用緩解策略，需要在定期的彈性測試中練習使用這些策略。

降低事件影響

除了一般的緩解策略(即第一優先緩解一個緊急情況或事件)，從長遠來看，還需要考慮如何降低事故的影響。事件是一個內部術語。事實上，你的客戶並不關心事件或事件的數目，他們真正關心的是可靠性。爲了滿足用戶的期望並達到期望的穩定性級別，你需要設計並運行可靠的系統。爲了達成這個目標，你需要將你的動作對齊到前面提到的事件管理生命週期：準備、響應和恢復。考慮在事件前、中、後應該做哪些事來提高系統的穩定性。

雖然很難衡量用戶的信任度，但有一些策略可以用來衡量你提供的用戶體驗的可靠程度。我們SLI來衡量用戶體驗。SLI會告訴你任何時間下的服務質量。那麼如何衡量服務的表現好壞呢？

在一些場景下，用戶可以是一個終端用戶、一個人或系統(如API)，或其他內部服務(如服務其他內部服務的核心服務)。在這種情況下，你需要像你的關鍵依賴項(即硬依賴或無法執行緩解策略的依賴--如果它出現故障，你也會出現故障)一樣可靠。這意味着，如果面向客戶的服務依賴內部服務，那麼這些內部服務需要提供一個更高的可靠性來爲客戶提供其需要的可靠性等級。

SLI的可靠性目標稱爲SLO。一個SLO會隨時間聚合目標：在特定時間段內，這是你的服務目標，用於衡量服務的表現(通常使用百分比)。

SLA定義了你對你的客戶做出的承諾，即，如果你無法滿足目標，則需要付出什麼代價(如退錢)。爲了達成SLA，你需要保證SLO比SLA更嚴格。

我們用來校驗和衡量用戶滿意度的工具稱爲"用戶旅程"(user journey)。用戶旅程是一個用戶視角下的文本表述。用戶旅程用於考察你的用戶是如何通過與你的服務進行交互來達成一系列目標的。最重要的用戶旅程稱爲關鍵用戶旅程(CUJ)。

一旦給你和你的用戶或客戶制定了目標，接下來就需要考慮當無法滿足這些目標時會發生什麼。

計算事件的影響

事件會影響穩定性目標。穩定性目標受故障數、波及長度和範圍以及故障的級別的影響。因此，爲了降低事件影響，首先需要了解如何降低影響。下面看下如何對事件的影響定質定量。

下圖展示了爲了測量影響，如何計算服務不可靠的時間，即發現影響的時間加上恢復(緩解)的時間，然後乘以事件數目(受事件頻率的影響)。

主要的指標是探測時間、修復時間和故障間隔時間：

• 探測時間(TTD): 從故障發生到有人觀測到或收到產生問題的告警之間的時間
• 修復時間(TTR)：從當有人收到問題警報時開始，到問題得到緩解之間的時間。這裏的關鍵是緩解，並不意味着你需要提交代碼來修復問題，它只是響應者緩解對用戶的影響所花費的時間，如將流量切換到其他域。
• 故障間隔時間(TBF)是一個事件到下一個相同類型的事件之間的時間。

降低用戶影響意味着降低下面等式中的四個方面：探測時間、恢復時間、故障間隔時間和影響。

爲了降低事件影響，並讓系統恢復到一個已知狀態，你需要結合技術和"人"這兩個方面，如流程和支持。在谷歌，我們發現一旦人力介入，故障至少會持續20到30分鐘。通常，使用自動化和自恢復系統是個不錯的策略，這些方式可以幫助降低探測時間和恢復時間。

\[Unreliability \sum\frac{TTD+TTR}{TBF}\times Impact \]

你需要注意你使用的方法。簡單地降低告警閾值可能會導致反效果並增加噪音，而過多地使用自動化進行快速恢復可能會降低恢復時間，但可能會導致忽略底層問題。在下一章中，我們會分享一些策略來幫助降低探測時間、恢復時間和事件發生的頻率。

降低探測時間

一種降低事件影響的方式是降低探測事件的時間(見下圖)。作爲起草SLO的一部分，你需要進行風險分析，制定優先級，並確定哪些事情會導致無法達成SLO。這些準備也可以幫助你降低事件探測的時間，此外還可以通過如下方式最小化探測時間：

• 對齊SLIs，使你的客戶滿意度指標儘可能貼近用戶的期望，用戶可以是真人或其他服務。再進一步，將你的告警對齊到SLOs，通過週期性地回顧這些告警來確保它們能夠代表用戶的期望。

• 使用最新的信號數據。這意味着你需要使用不同的測量策略來衡量告警質量。選擇最適合的獲取數據的方式很重要：流、日誌或批處理。此外還需要平衡告警的頻率，過於頻繁的告警可能會造成噪音，而過慢的告警則可能會影響到用戶(噪音告警也是Ops團隊經常抱怨的問題之一，他們通常是傳統的運維開發或SRE)。

• 使用有效告警來避免告警倦怠。當需要立即採取行動時才需要進行通知，且只會通知特定的響應者(特定的團隊或所有者)。注意另一種經常抱怨的情況是，告警不可操作。

  但新的問題來了:"如果只通知那些需要立即行動的內容，那麼剩餘的問題該怎麼處理？"。一種解決方式是對不同原因的告警採用不同的工具和平臺。可能"最佳的平臺"是一個問題單系統或儀表盤，或只是在"拉取"模式下通過指標進行故障排除和調試。

降低修復時間

我們已經討論了降低事件影響的一種方式是降低探測事件。另一種降低影響的方式是降低恢復時間。降低恢復時間更多是降低"人工側"的時間。使用事件管理協議並組織一個事件管理響應來降低事件管理中的歧義以及緩解對用戶造成的影響所需的時間。除此之外，你還需要培訓響應者，制定清晰的程序和內容，並降低on-call的壓力。下面看下這些策略的細節。

培訓響應者

未準備的on-caller會造成更長的恢復時間。可以考慮執行如災難恢復測試或我們先前提到的"厄運之輪"測試等訓練主題。另一種技術是提高對on-call的指導。讓on-caller結對工作(“結對待命”)，或讓學員在輪班期間引入經驗豐富的on-caller進行學徒訓練（“跟蹤”），進而增加新團隊成員的信心。記住on-call是有壓力的。清晰的事件管理流程可以通過消除歧義並明確必要的動作來降低壓力。

建立組織事件響應流程

事件管理中存在一些常見的問題。例如，缺少責任性、缺少溝通、缺少層級關係，而自由職業者/"英雄"可能會導致更長的解決時間，這些問題會給no-caller和響應者增加額外的壓力，並影響到你的客戶。爲了解決這些問題，我們建議通過清晰的角色建立一個層級響應組織架構。這可以幫助維護清晰的指令線並分配清晰的角色。

在谷歌，我們使用IMAG (Incident Management at Google)，這是一個靈活的基於消防員和醫務人員使用的事故指揮系統(ICS)框架。IMAG可以教你如何通過清晰的角色、任務和通信渠道建立一個層級結構。它建立了一個標準的、一致的方式來解決緊急情況並組織有效的響應。

IMAG協議爲那些致力於解決事件的人提供了一個框架，保證能夠自組織應急響應團隊並通過與響應者和相關人進行有效溝通，控制整個事件響應，並幫助協調響應工作。它聲稱，事件指揮者(IC)負責協調響應和委派責任，而其他人則向IC報告。每個人都有一個特定的角色，如運維領導負責修復問題，而溝通領導則負責處理溝通。

通過這種協議，你可以降低歧義，理清楚團隊的工作，並降低修復的時間。

建立清晰的on-call策略和流程

我們建議對事件響應on-call策略以及應急響應流程(包括故障中和故障後)進行歸檔。它包括一個清晰的故障升級路線以及責任劃分。它可以降低歧義處理故障的相應壓力。

編寫用的運行手冊/playbooks

歸檔非常重要，它可以將經驗轉化爲所有隊友都能獲得的知識。通過對文件進行優先級排序並預留出一定的時間來爲事件過程創建playbooks和策略，這樣你的團隊成員就可以知道事件是如何呈現的。一開始的playbooks不需要非常具體，可以從一個簡單的點開始，然後逐步迭代。一個好的例子是谷歌的"看見問題，修復問題"(即在發現問題的時候修復問題)，並讓新團隊成員更新這些playbooks，作爲新員工培訓的一部分。

將ploybooks開發作爲一個主要的事後項目，並將該團隊貢獻作爲績效管理的一部分。這通常需要領導層確定優先級並分配必要的資源，將其作爲開發衝刺的一部分。

降低響應疲勞

第二章討論了響應者的疲勞成本，進一步講，如果你的響應者已經筋疲力盡，這將會影響他們解決問題的能力。你需要確保班次平衡，否則就需要使用數據幫助你瞭解不平衡的原因並減少工作量。

研究數據採集和可觀測性

你希望基於數據來做決定，如果你看不到這些數據，就無法瞭解事態的發展。因此我們鼓勵在組織中使用度量文化，採集那些與用戶體驗有關的指標，並度量你目標的完成度以及錯誤預算消耗速度，並以此做出反饋，調整優先級等。此外，還可以度量團隊的辛苦程度並週期性地審視SLIs和SLOs。

你會希望儘可能多地收集高質量數據，特別是那些與用戶體驗有關的數據，這可以幫你進行故障排查和問題調試。採集應用和業務指標，並將其繪製成關注用戶體驗和關鍵用戶旅程的儀表盤和可視化界面。

可以看到，可以通過一些方式來降低恢復時間，並最小化事件影響。現在讓我們看下通過增加故障事件的間隔時間來降低事件影響。

增加故障之間的時間

爲了增加故障之間的時間，並降低故障的個數，你可以重構架構，並解決在風險分析和流程改進過程中發現的故障點。還可以通過其他事情來增加TBF。

避免反模式

本文中我們提出了一些反模式，包括缺少可觀測性和正反饋，這些模式可能會導致系統過載並引發級聯事故，如崩潰。你需要避免這些反模式。

分散風險

可以通過冗餘和職責解耦、避免單點故障和全局變更，以及採納高級的部署策略來分散風險。考慮在數小時、數天或數週內進行漸進式和金絲雀式的發佈，這樣可以在所有用戶受到影響之前降低風險並識別問題。類似地，可以通過自動化測試，逐步發佈和自動化回滾來及早發現問題。通過參與混沌工程並引入故障注入和自動化災難恢復測試(如DiRT)來達到及早發現故障的目的。

採用開發實踐

你可以採納開發實踐來培養質量文化，創建代碼監視流程以及可以集成到CICD流水線中的健壯性測試。CICD可以節省工程時間並降低用戶影響，提高服務部署的信心。

考慮可靠性設計

在SRE中，我們有一句話："希望並不是一個策略"。在討論故障時，問題不在於是否是故障，而在於何時發送故障。因此，一開始就需要考慮到可靠性設計，以及可以適應故障的健壯性架構。通過如下問題來了解你是如何處理故障的：

• 我的系統能夠抵禦哪種類型的故障？
• 它是否能夠容忍非預期的單點故障或重啓？
• 它是否能夠處理分區或區域故障？

在你瞭解到存在的風險以及風險的影響範圍，就可以進行風險緩解措施。例如，爲了緩解單點問題，你應該使用持久化磁盤，並提高自動化數據備份功能。爲了緩解區域和分區故障，你可以使用多種跨分區和區域的資源來實現負載均衡。另一種方式是水平縮放。例如，如果將一體式架構分解爲微服務，就可以獨立地縮放這些服務。水平縮放也可以意味着地理上的縮放，如通過多個數據中心來提高彈性。我們建議儘可能避免使用人工配置和特殊硬件。

優雅降級

架構中另一個重要的方面是實現優雅降級方案。降級是一種策略，類似限流和減載。可以考慮一下這個問題，如果我不能給所有用戶提供所有功能，那麼是否可以給所有用戶提供最小集合的功能？是否可以限制用戶流量並丟棄佔比過高的請求？當然，可接受的降級程度取決於服務和用戶旅程。如，返回x產品和返回未更新的支票賬戶餘額之間存在差異，但根據經驗，降級服務總比沒有服務好。

縱深防禦

縱深防禦是另一種處理故障的方式，更精確地說是容忍故障。如果你依賴一個系統進行配置或其他運行時信息，則需要確保有一個可回退或緩存的版本來在依賴不可用時保證系統的正常運作。

N+2資源

N+2資源是實現分佈式系統可用性的最小原則。N+2意味着你需要有N的容量來處理峯值請求，+2實例來容忍一個實例因爲故障不可用，另一個實例因爲(計劃中的)升級不可用。我們前面提到過，你的服務要像關鍵依賴項一樣可靠，因此需要合理地設計架構。當在雲端進行構建時，需要確保使用服務的可靠性等級，將其與應用目標關聯起來，並注意它們的適用範圍(例如，在谷歌雲平臺的構建塊[區域、區域、全球])。通過在架構設計中解決可靠性問題來降低後續的糾正成本。沒有一勞永逸的方式，需要根據需求來作出相應的策略。

NALSD：非抽象大型系統設計

在討論可靠性和SRE時不能不涉及非抽象的大小系統設計。在谷歌，我們發現可以通過在設計階段解決可靠性問題來降低未來的成本，如果你使用了一個可迭代的系統設計風格，就可以通過一種低成本的方式開發出健壯且可擴展的系統。我們將這種方式稱之爲非抽象大小系統設計，或NALSD，它描述了谷歌產品系統的系統設計迭代過程。可以參考谷歌的 SRE Classroom。

從故障中獲得的經驗

最後，通過從失敗中吸取教訓來讓明天更好。當中使用的工具就是事後調查。確保問題修復、緩解和文檔升級都使用一致的事後調查流程。與跟蹤其他問題一樣跟蹤事後調查項，並將事後調查優先於"一般"工作。下一章節我將詳細討論事後調查。

事後調查及其他

在上一章中我們涵蓋了降低用戶影響的一些方式，包括技術和人兩方面的，因爲二者都會影響到探測時間、緩解/恢復時間以及故障間隔時間。在本章，我們將討論事件結束之後的事：編寫事後調查並使用它作爲一種工具來幫助分析問題根因以及吸取經驗。

在事件完成之後，你如何知道做什麼事情來降低未來的事件？爲了瞭解需要關注那些內容，我們推薦使用一種事件驅動方式。數據可以是風險分析過程的結果，或前面提到的度量。重要的是要依賴事後調查中採集到 的數據並從影響到用戶的事件中吸取經驗。

一旦有了大量事後調查，就可以確定出事件的產生模式。讓事後調查指引你解決問題。爲此，我們推薦創建一個共享倉庫並在團隊內部共享事件調查。

心理安全感

在討論事後調查的時候不得不提到心理安全。因此，在開始編寫事後調查前，首先討論事件管理文化中固有的心理安全，並討論及早升級的價值。

如果你的客戶受到影響，你應該及早解決問題。但如果組織中的成員對事件升級或事件擴大感到不安，則可能會影響事件的及時解決。如果一個公司不鼓勵問問題，或者事件升級會帶來影響，那麼響應者可能會不確定是否應該問問題。如果發生了這種情況，會讓事件在好轉之前變得更糟。

故障總會發生，你需要接受這個事實，這就是爲什麼實施SRE原則需要一種支持和授權的文化。隨着不斷使用新功能和新系統來增強服務，一個關鍵點是需要理解事件和故障是不可避免的。因此，如果不從事件中吸取經驗，那就錯失了一個提升的機會。Aikidoe的創始人Morihei Ueshiba曾說過"失敗是成功的關鍵，每個錯誤都會教會我們一些東西"。

如果你將操作看作是一個軟件工程問題，那麼當出現問題時，需要查看系統中存在的導致這些問題發生的缺陷，然後採取一些措施來避免人爲導致的錯誤。

人永遠不會導致故障，但系統和流程會允許這些故障發生

如果發生了故障，那麼就應該是系統的缺陷，而不應該是人的問題。因爲人爲錯誤是一個既定的事實。事件管理的最終目的不是消除人爲錯誤。

構建心理安全氛圍的一些點子

實施事件管理實踐是一項組織變革，需要文化方面的支持，能夠讓你進行創新並從錯誤中吸取經驗。關鍵是要有心理安全和無指責的流程。

心理安全是一種信念，即一個人不會因爲說出想法、問題、擔憂或錯誤而受到懲罰或羞辱。

---Dr. Amy Edmondson, Novartis Professor，哈佛商學院領導與管理

心理安全促進了績效導向組織的一些主要特點；特別是將故障作爲一個學習機會，並採納一些新的點子。例如Westrum的組織文件模型基於心理安全來預測軟件交付能力：與其他兩種類型相比，生成型組織更有可能成爲表現最佳的組織。

心理安全性較高的團隊更有可能採納來自隊友的不同想法，比銷售目標高出17%(不安全團隊則低於銷售目標19%)，並且被高管評爲有效團隊的概率是後者的兩倍。

處理事件時的心理安全

在風險管理中，重要的是要讓人們知道他們可以發出自己的觀點並確定問題產生的原因，而不用擔心被懲罰或被嘲笑。當發生一個事件時，必須報告併產生一個事件。在處理事件的過程中，你可能需要共享之前發生的事件的信息，即使這麼做會暴露之前的錯誤(但這與指責無關)。你可能還需要將事件交接給下一個on-call工程師，並建議改進內部流程、工具和功能。

如果沒有心理安全和無指責文化，人們可能會避免提出一些可能可以確定事件問題根因的正確問題。結果是團隊無法得到成長並進行創新，原因是他們看重印象管理且害怕承擔後果。

爲了在團隊中培養心理安全和無指責文化，需要關注學習機會：將每個事件都視爲每個人都可以從中學習的機會，通過邀請每個人(特別是有不同意見的人)發出他們各自的觀點來鼓勵不同的想法。作爲一個領導，你也應該承認自己的錯誤，通過提問來激發好奇心。

不推卸責任

無指責和心理安全是一起的，其中一個可能是另一個的天然結果。假設出現了一個故障，如果經理的第一個問題是"誰導致的？"，那麼這可能會創造一種指責文化，導致無法創新和提升。相反，你應該提倡無指責：

無指責是一種觀念，即將人的責任轉移到系統和流程。

指責文化會 阻礙人們快速解決問題並從中學習的能力，因爲爲了避免遭受懲罰，他們可能會傾向於隱藏信息並避免聲張事件。另一方面，無指責文化可以讓你更關注提升。你應該假設個體是出於善意而執行的動作，並根據可用的最佳信息做決定的。相比指責，對組織來說，調查失實信息的根源更有用。因此，當出現問題時。需要支持團隊的設計並鼓勵創新和學習。

從錯誤中吸取經驗

只有在正確識別錯誤的程序性和系統性原因時，錯誤纔是學習和提升的最佳機會。在谷歌，Ben Treynor Sloss每個季度都會發送一封工程報告--"谷歌最大的成功與失敗"，以此來鼓勵從錯誤中進行學習。

實施事件管理實踐時的心理安全

事件響應者需要有一定的信息才能成爲一個高效的響應者，即使是在壓力環境中。響應者在處理事件時必須感到心理安全。

心理安全可以延申到多個層面：

來自團隊成員

• 響應者不應感受到自己的行爲受到同行的評判，尤其是在他們犯錯時
• 說“我需要幫助”應該得到獎勵，而不是質疑或譴責

來自夥伴團隊

• 一些團隊可能會覺得團隊X的成員因居高臨下而名聲不佳，所以我們不要跟他們進行交流。更甚者，有些團隊會採取這種文化，或使用這種方式來避免與其他團隊進行交互。這種態度是不能容忍的，它會造成額外的緊張並降低事件響應的速度。

來自管理者

• 管理者需要負責團隊的心理安全，在一個事件中，管理者通常不會做技術性的工作，相反，他們會專注於確保團隊的健康，尋找壓力/倦怠的跡象，如可能在團隊處理事件的時候訂披薩，也可能只是告訴事件響應者"休息5分鐘"。
• 管理者還可以幫助從組織其他部門獲得更多幫助
• 管理者爲團隊爭取他們需要的來自組織其他部分的緩衝，並在衝突發生時介入來解決衝突。

來自組織

• 只有組織將心理安全融入其文化，心理安全才能蓬勃發展。組織中應該有一個無責任的文化，其關注點是修復導致事件的流程。
• 行業中充斥着諸如"三次罷工政策"等政策，該政策要求終止或嚴厲譴責涉及影響生產的三個錯誤的個人。儘管這種政策的目的是鼓勵響應者在事件發生時格外小心，但它會導致響應降級("我不想成爲打壞電話的人")、推卸責任("我們沒有打破它，另一個團隊打破了它")，或隱藏有價值的信息("不要泄露我們已經知道這個問題的事實")。
• 如果領導希望他的團隊和組織能夠蓬勃發展，就必須培養一種尊重、信任和合作的文化。這種文化需要源自上層組織。

早先提到過，心理安全環境的一個好處是可以降低升級時間。如果一個組織擁抱合作文化，響應者會更傾向於徵求外部幫助---無論是來自本團隊還是公司的其他團隊。

在回顧事件時，一個反覆出現的主題始終是"如果我們早點升級，我們本可以節省XXX美元的收入損失"，即使在擁有健康、心理安全環境的團隊/組織中也是如此。讓一個響應者提問題其實是一件很困難的事情--以免被認爲是能力不足或缺乏準備的表現。我們被訓練成隱藏不安全感(甚至是感知到的不安全感)，並被教導成爲英雄，爲團隊做出110%的貢獻。這些行爲實際上是累贅，特別是在事件響應期間--反應過度或疲憊的人更容易出錯。升級應該是簡單快速的，並且不附帶任何條件。應該認爲假設升級的意圖是好的。如果發現無需升級，找出升級的原因(可能是因爲缺乏/丟失文檔)並糾正流程即可。

事件響應者不應該對試圖自己做的每件事保持高度警惕，相反，應該儘早升級。在谷歌，事件響應團隊有一個俗語：我們會告訴其他團隊我們不介意經常收到通知，且我們也沒有收到過多的通知。

編寫事後調查

現在我們已經深入討論了心理安全，下面看下如何編寫事後調查。當出現問題時，這是一個可以從中學習並提升自我的機會。而一個"糟糕的工程師"則會認爲"期望不會看到那樣"，一個好的工程師則會注意到發生了某些事情，並認爲"有意思，讓我們告訴其他人"，這也是事後調查介入的地方。

編寫事後調查是一種系統分析形式：它是深究導致事件的缺陷並確定提升工程和工程流程領域的過程。事後調查並不是多餘的，而是在服務上實踐系統工程的核心方法，用於推動改進。

在編寫事後調查時，需要持有一種無指責的文化，並假設事件終究會發生。正如前面提到的，預防失敗很重要，但是要認識到日常故障是不可避免的，尤其是在涉及到規模時。事件給你和你的團隊帶來了從中學習的機會。事後調查是確保你能夠從錯誤中吸取經驗的一種系統解決方案，還能幫助共享從錯誤中獲得的知識(如給其他人閱讀事後調查)。

事後調查提供了一種從事件中學習的正式流程，以及防止和降低事件、影響和複雜度的機制。例如，你可能會從中學習到避免將補丁作爲一個一勞永逸的方案。事後調查可以展示趨勢，併爲你的工作排出優先級。事後調查應該是無指責的，這可以避免私底下對問題進行反覆討論，即誰導致的問題，是誰的過錯等等。事後調查應該關注從事件中學習到了什麼以及對未來的改進。

有些信息是每個事後調查都應該涉及的。如，好的事後調查會包含清晰的行動項(AIs)，以及這些行動項的責任人和截止時間。注意，這裏沒有指責誰，而是爲了提升責任意識，消除歧義，並確保能夠跟蹤所有的動作。此外，還應該包含一個清晰的事件時間線，即事故的發生時間、檢查時間、升級時間(如果有的話)和緩解時間(如果有的話)、故障影響和故障的截止時間。如果發生了升級，則需要說明爲何以及如何產生的。爲了避免困惑，需要明確術語事件和故障，以及事件開始和事件檢測。我們推薦在事件過程中使用在線文檔來記錄調試和緩解過程，後續在事後調查時可以參考這些文檔。文檔可以幫助正確捕獲時間線，並確保沒有錯過關鍵的AIs。

在事後調查中應該避免責備性語言，並踐行心理安全。可以舉例並詢問問題，但不能指責。事後調查是關於瞭解事件的本質，採取的動作以及如何防止未來發生相同的問題。

谷歌的一個最佳做法是與儘可能多的受衆分享事後調查的經驗教訓。通過分享可以幫助其他人獲得事後調查並從中獲得知識。

我們已經發現，建立一個無指責的事後調查文化可以獲得更可靠的系統，成就一個成功的SRE組織。

系統分析和組織提升

我們已經討論了無指責的事後調查，並將事後調查作爲一種系統分析的形式。但你是否深入你的系統來完全瞭解到到底發生了什麼以及如何發生的？爲了得出最終結論，需要對事件進行分析，而不是簡單的描述。事件發生之後或在事後調查中需要對其進行深入分析，爲了暴露並解釋最終結論，是否對事件和系統方面進行了分析。這一點很重要，因爲它增加了你的團隊在事件發生後正確修復事件的可能性。

在編寫事後調查時，你應該以最完整和最準確的系統運作細節爲目標，這樣才能確保修復是正確的。在圖5-2中，帶有"你認爲的問題是什麼"的圓圈反映了你對事件中的系統的理解，這是你可以控制的部分。帶有"實際的問題是什麼"的圓圈反映了事件中的系統的真實狀態，涉及複雜的、由很多活動部件組成的複雜技術生態系統，以及與管理事件有關的所有的(人)交互過程，要真正理解所有這些細微差別是極其困難的。但對事件的理解越深入，圓圈的重疊部分也就越大，越接近潛在的問題。

如果事件已經被緩解，系統再次穩定，那麼還有必要理解真正的問題？當然，原因是它涉及可行動性，或一個事件之後修復或改進的能力。這些事後的增量系統改進有助於逐步建立系統的恢復能力。第三個重要的圓圈表示你實現的系統修復的部分(圖5-4)。

這個圓圈也不能移動，因爲總會有一些超出你控制的東西影響系統的健康(天氣、地球大小、光速)。

中間最小的交集(1 ∩ 2 ∩ 3)就是事件之後你的團隊可以實施的最佳部分。而"你認爲的問題"和"你可以修復的地方"的重疊部分((1 ∩ 3) – 2)一個危險區域：你認爲有些方式可以長期起作用，但實際並不會解決真正的問題。你可能會解決一些主要問題周邊的問題，或解決了另一個隱藏問題暴露出來的症狀。假設你已經解決了一個尚未真正解決的問題，可能會導致無法瞭解到日益上升的風險。如果再次發生了一個特定的事件，你的客戶信任度會降低，並錯失本可以更有效利用的時間。

如果對系統進行了深入研究，就可以在其他兩個圓圈不動的情況下，最大化中心部分(1 ∩ 2 ∩ 3)。即提高了有效修復的可能性。如果你希望確保目標是正確的，則需要花時間來研究如何移動圓圈，其關鍵是需要對系統進行足夠的調查分析，然後選擇可以更大概率提升系統彈性的工程項目。但這裏面存在一個回報遞減的問題，例如，花費一個月時間來調查每個故障，這並不是一種謹慎使用資源的方式。在下面章節中，我們會推薦一些方式來幫助(思考以)移動圓圈。

根因VS觸發因素

讓我們從兩個關鍵術語開始，根因和觸發因素：

根因：

系統的危險，或系統如何容易到受攻擊。系統中的一個危險可能會存在一段不確定的時間--需要通過某種系統環境變更來將其轉化爲故障。需要明確一點：在複雜系統中，很少只有一個事件根因。熟練的從業者會認爲事件的底層根因是一個導致危險狀態的各種相互作用的因素網絡。

觸發因素：

即讓根因換變爲事件的環境。它是一個相關、但獨立的東西。爲了防止重複產生故障，有時候需要定位根因。有時，則圍繞這些觸發因素建立預防措施更爲合理。

根因和觸發因素一起會導致事件。當然，這樣描述有一些過於簡化。根因/觸發因素和事件類型並沒有一對一的映射關係，系統的複雜性可能會導致各種後果。下面看幾個例子：

房屋着火：

• 根因：燃氣泄漏
• 觸發因素：泄漏的爐子附近的一個火花塞點燃了泄漏的氣體。
• 事件：房租着火(但這裏的根因可能會導致其他事件)

螞蟻侵擾：

• 根因：溫暖的季節適合自然環境中的昆蟲和害蟲繁衍生息
• 觸發因素：邋遢的飲食習慣會留下很多面包屑
• 事件：螞蟻侵擾

內存不足(OOM):

• 根因：配置文件導致內存泄漏
• 觸發因素：突然發生大量請求
• 事件：OOM

第三個場景中，在觸發現有的條件之前，根因可能已經存在了多年(這是技術債務最終比預期更昂貴的方式之一)。該根因可能並不是一個缺陷，它可能是限制系統行爲的任何因素。在系統將限制轉化爲危險的環境條件之前，限制本身並不危險。此外還要澄清一點，觸發因素可能並不是簡單的二元狀態(即是或否)，觸發條件可能存在於一個動態範圍內，只有在系統的環境和根因相互作用時纔會成爲事件。這兩個因子可以被視爲創建事件生命週期的關鍵組件。

事後剖析的根因部分應詳細說明一些根本原因和當前事件的觸發因素。爲了防止再次發生停機，有時解決根本原因很重要。有時，圍繞觸發因素建立預防措施則更爲合理。

然而，僅僅將根因和觸發因素分開討論並不能從本質上提高團隊事後分析的質量。本文的所有章節中都包含一定數量的最低要求，但同樣重要的是，事後分析應該包括可以被團隊以外的工程師理解並採取行動的分析內容。這是一個反覆出現的問題嗎？是否注意到緩解步驟，或者是否需要確定缺陷？事後剖析是否適當地解釋或量化了系統的正常功能，並展示出故障的規模比較和影響？如果說89%的產品用戶羣受到了影響…這意味着什麼？

隔離系統VS整個堆棧

不幸的是，存在一種反模式，即在不考慮系統上下文(系統環境中與系統功能相關的部分)的情況下，將系統分析的範圍限制在可能被破壞的部分。以下是一些可以拓寬系統分析深度的問題：

• (如適用)該事件是否作爲單個事件進行審查，或是否討論了關聯/相關/子事件？
• 你或任何主要內部客戶是否瞭解到以前未知的依賴關係？
• 端到端的溝通情況如何？

雖然事件可能只發生在整個堆棧的一個子部分中，但這並不意味着事件是孤立發生的。查看事件是否以及如何影響整個堆棧和公司成員，可能會發現事情是如何產生的。這可能包括你的事件是否會導致其他事件或級聯故障，或者你的公司作爲一個整體是否能夠在事件期間進行有效溝通。

時間點VS軌跡

在研究中，元分析是一種將多個研究串聯成更大的結論的技術。如果你認爲每一次事後剖析都是一項傳達系統時間點視圖的研究，那麼將這些工作視爲一個整體可以幫助識別新出現的模式和見解。我們建議將每次事後剖析作爲一次檢查系統隨時間變化的行爲的機會。考慮以下問題：

• 是否根據系統隨時間的軌跡對該事件進行了審查？
• 是否發生了相同的故障類型？
• 是否存在長期的強化或調節迴路？

整體系統思維的一部分是隨着時間的推移來考慮你的系統。總的來說，不要讓同一個事件發生兩次。

我們已經研究了系統分析組織上的改進，以及它如何使你和你的團隊受益。現在讓我們來看一個真實的例子。

Mayan Apocalypse：一個真實世界的例子

爲了實際理解我們討論過的原則，下面我們將深入瞭解一下谷歌發生過的一個重大故障。我們會覆盤整個過程，瞭解可縮放的組織是如何解決該故障的，以及我們可以從中學習到哪些內容。

對谷歌而言，Mayan Apocalypse並不是導致2012年故障的新玩意。相反，Mayan Apocalypse發生在2019年6月2日，使用了名爲Maya的網絡自動化工具，它用來管理標籤並在我們的一個骨幹網上進行流量定向，但一個很小的代碼移位導致整個實體被錯誤標記。

中午左右，我們正在進行計劃內的維護工作，並最終確定了要在一組服務器上運行的操作和配置變更列表(包括在Maya上)。但當該錯誤標記與我們的作業調度邏輯衝突時，我們“發現”了一種新的故障模式，在這種模式下，與流量方向相關的作業被整體取消調度。然後，進出這些區域的網絡流量試圖將取消調度的作業與流量方向仍然有效的剩餘網絡容量相匹配，但沒有成功。網絡開始變得擁塞，我們的系統正確地對流量過載進行了分類，並自動排出更大且延遲敏感度更低的流量，保留較小且延遲敏感的流量。

流量開始變得擁塞。因此，監控啓動了事件管理流程的第一步：告警。組件響應者會接收到來自監控系統的告警，表示他們負責的系統可能出現了故障。我們的監控系統會自動給響應者發送網絡組件超過錯誤閾值的通知，然後由響應者介入調查。

同時，受到網絡容量降低影響的區域產生了外溢，該網絡擁塞導致在我們的網絡和計算基礎設施出現了級聯故障。通常，我們的網絡會優先處理用戶(包括員工)流量(而非內部流量)。這種做法是好的，我們對99.9%的員工流量進行了重定向，因爲這部分人並不參與問題解決，以此來最大保障用戶的正常工作。而剩餘的參與事件的0.1%的員工通常知道如何處理並避開這一限制。但此次級聯故障影響到了我們的內部工具，導致大量告警中斷，並導致大量呼機關閉。當每個on-caller轉換爲事件響應模式時，他們發現服務因爲網絡問題而不可用。網絡組件響應者快速確定了網絡擁塞的根因，但由於相同的網絡擁塞仍然在導致服務降級，因爲減緩了恢復配置的能力。

由於每個人都希望更好地支持用戶並瞭解期望的服務恢復軌跡，因此原始網絡組件響應者突然就有了很多同伴。

在谷歌，我們有如下三種級別的組件：

• 基礎設施組件，如網絡流水線或存儲服務
• 產品服務組件，如網絡YouTube流或Google Search的前端
• 內部服務組件，如監控，零信任遠程訪問，MaYa等。此時這一部分功能出現了故障。

廣泛依賴意味着，在網絡組件解決問題之前，任何人都無法進行下一步動作。但如此多且職責不同的響應者的介入並沒有加速問題的解決。根因和二階效應開始模糊；一個團隊的原因是另一個團隊產生的影響，每個人都在努力貢獻自己的知識。雖然每個人都是其系統棧的專家，但都沒有完整的系統視角來說明哪些工具路徑變得不可用。

爲什麼？從未接觸過擁擠網絡的路徑都很好。而有些路徑即使接觸到了擁塞網絡的路徑，其也是正常的，因爲我們爲其分配了優先級。因此針對外部用戶的服務是可用的，如視頻通話或文檔編輯。但如果路徑本質上是內部的，例如作業或標誌控制或Maya配置，則它將被取消優先級並被卡住。

我們看到一座火山噴發，20分鐘後，我們得出結論，我們的問題“可能與熔岩有關”。

在介入故障一小時之後，一個組件響應者指出，影響我們基礎設施的系統間問題過於嚴重，圍繞事件的協調溝通正在變得混亂且不和諧。此時已經有超過40個團隊加入了事件響應溝通頻道，都想提供幫助。在對事件進行衡量之後，我們發現Google Cloud, Gmail, Google Calendar, Google Play和其他服務都受到了影響，導致業務服務無法運作，員工無法進行工作以及人員之間無法進行溝通。一些員工嘗試使用不需要用到受影響網絡的服務，但最後他們放棄了。

在40個人參與的情況下，我們的網絡問題解決人員缺乏足夠的心理空間來實施合適的緩解措施、協調實施這些緩解措施，與所有利益相關者進行溝通，以及管理預期效果等。

因此，他們進行了升級，我們的網絡組件on-caller通知了一些在合理時區內的Tech IRT成員，這些Tech IRT成員能夠在事件影響到可用性時介入工作。由於事件影響深遠，很多Tech IRT成員其實已經介入了該事件。我們的一些Tech IRT響應者並不作爲事件施令者，因爲他們是網絡團隊的成員或管理者，可以幫助確定主要根因，因此他們選擇協助運維。

成爲事件施令者的Tech IRT的成員之前並沒有在受故障影響的網絡組件團隊中工作過，但他們能夠評估我們的"求救信號"以及響應故障的人員狀態。通過他們接受過的訓練，事件施令者能夠使用某種機制來訪問我們的生產系統，該機制會立即將他們的行爲識別爲“事件響應”，並能夠破壞“降級內部流量”標記。一旦內部流量有了一點餘量，他們就會引導網絡on-caller加入進來解決問題。

在這一過程中，他們很快組織正在溝通以及試圖“參與”的每個人。一旦這種混亂的工程能量被組織起來，每個人就可以發揮作用。他們可以更清楚地跟蹤不同系統的持續狀態，並瞭解緩解措施的實施進度。隨着管理不再給我們的網絡組件響應者帶來負擔，他們和他們的團隊(已經出現在幫助中)就有了實施適當緩解計劃的空間。包括通過大量減少負載來爲重啓和一些緊急強制配置更改騰出系統餘量.

一旦啓動了緩解事件，技術IRT成員就會專注於推動事件走向結束。他們設定了一些退出標準，用來確定我們何時可以結束事件，確保其他系統能夠在執行恢復操作中得到支持，最後確保相關的響應團隊的交接和分離。

在事件結束並恢復正常服務後，需要深入進行事後分析，分析事件並瞭解其根因以及通過這些故障模式暴露出來的緊急特性。此後，相關的網絡團隊一直致力於一些非常酷的舉措，重構了Maya並防止再次這種故障模式，以及防止之前沒有考慮過的故障模式再次困擾我們的系統。

最後，我們用內部簡介徽章、榮譽模因和獎金獎勵參與的人員。對大多數人來說，真正嚴重的事件是他們職業生涯中最糟糕的一天。提供一些小的東西給每個人提供了一種微妙的激勵，讓他們爲事後分析做出貢獻，幫助我們學習，並不斷地變得更有適應力。