太多的公司所用的 on-call 輪轉和事故響應流程讓團隊成員感到緊張、焦慮、痛苦。特別是，許多優秀的工程師只是由於這個原因而拒掉工作。

並非一定要這樣。在 New Relic，我們的開發運維實踐讓我們得以創建既能夠支持系統的快速增長又高度重視系統的可靠性，同時還能保護開發人員免受戲劇性事故和壓力的影響的 on-call 輪轉和事故響應流程。通過分享我們構建和管理 on-call 輪轉和事故響應系統的經驗和最佳實踐，希望可以幫助其他公司解決類似的挑戰，讓他們的開發人員和其他實踐者的生活能夠更輕鬆。

On-call 策略實戰

New Relic 的產品組織目前由 50 多個工程團隊組成，包含 400 多名工程師和管理人員，支持超過 200 個獨立服務。每個團隊都是獨立運行的單元；團隊自行選擇所使用的技術用於編寫和維護服務，管理部署、操作運行手冊和 on-call 輪轉。

我們的工程團隊由軟件工程師、站點可靠性工程師 (SRE，Site Reliability Engineer) 和工程經理組成。大多數團隊至少作為三個服務的主要負責人。通常在他們加入公司後的兩到三個月內開始，每一位工程師和工程經理都要加入 on-call 輪換當中。

我們這樣做的首要原因是因為這是必須的。New Relic 為全球數千名客戶的應用程序和基礎設施提供至關重要的監控、警報和商業智能。當客戶遇到問題時，不可能把問題拖到第二天解決。雖然我們在美國和歐洲都有工程師，但絕大部分團隊都在俄勒岡州的波特蘭全球工程總部工作。這就意味著我們不可能像谷歌那樣，採用“跟隨太陽”的輪轉方式，在每日工作結束時，一個地方的工程師把他們的 on-call 職責交給世界各地的其他同事。

1. 採納並擁抱 DevOps 實踐

在 DevOps 作為一種應用開發方法出現之前，on-call 職責通常是由工程師及其他 IT 人員中的一部分人員來承擔，例如集中式的 SRE 團隊或運營團隊。

這些員工——而非實際構建軟件的開發人員——對牽涉到他們所監控的服務的事故作出響應。然而，來自 SRE 團隊的反饋很少能夠到達開發人員的手中。此外，產品負責人通常會選擇開發更多新特性，而不是敦促團隊償還技術債務，使產品和服務儘可能可靠。

DevOps 出現的原因之一就是要拆除這些組織豎井。在 New Relic 所採用的這類現代應用程序體系架構中，各種服務組合在一起，形成一個大型的、互連的產品平臺，該平臺依賴於由雲服務，數據庫維護器以及錯綜的網絡層所組成的複雜系統——這僅僅是複雜系統組成部分的幾個示例。特定的事故響應可能起始於某個團隊，但是根本原因則涉及更深一層的服務。

DevOps 支持這樣一種觀點，即沒有哪個團隊是孤立的，團隊之間必須能夠保持交互，並且具有清晰的、文檔化的 on-call 流程，以保持這些複雜系統的平穩運行。此外，在一個實踐性較強的 DevOps 實踐中，如果開發人員需要對他們構建的服務提供支持，那麼開發人員在構建服務時會做出更好的決策——他們不能把自己構建的服務拋之腦後，留給其他人。

2. 在團隊自治和問責制之間保持平衡

在 New Relic 的大多數團隊都採用了一種為期一週的 on-call 的輪換方式，其中一名工程師擔任主要響應人員，另一名工程師擔任次要響應人員。這樣，如果一個團隊有 6 個工程師，那麼每個工程師每六週就會成為一次主要響應人員。

然而，一個成功的 on-call 流程更加依賴於團隊的組成、團隊所管理的服務以及對於這種服務團隊掌握的集體知識情況。這就是團隊自治發揮作用的地方——在 New Relic，每個團隊都創建了反映各自需求和能力的 on-call 系統。

讓我們來看一下這種方法在實踐中的兩個案例：

• New Relic 度量管道團隊已經構建的輪轉方式，能夠始終保證有一個“主要”和一個“非主要”的 on-call 聯繫人。通過一個 Jenkins 腳本，團隊隨機輪轉非主要的聯繫人的 on-call 順序。當事故發生時，如果無法與主要聯繫人取得聯繫或主要聯繫人未對呼叫作出響應，則按隨機順序每次呼叫一個非主要聯繫人，直到有人響應為止。
• New Relic 瀏覽器團隊則採用了一個可配置的定製化應用程序，該應用程序每分鐘將一名新團隊成員輪轉到“主要”角色。如果在呼叫某個團隊成員時，沒有得到立即響應，系統就會輪轉到下一個人，以此類推，直到有人對警報作出響應為止。這種方法實際上減輕了團隊成員的壓力：當問題出現時，如果團隊成員沒有時間或者覺得還沒有好的問題解決方案，只需兩分鐘的時間就可以輪轉到另一個團隊成員。

3. 跟蹤並度量 on-call 績效

New Relic 在工程師、團隊和群組層面追蹤幾個維度的 on-call 度量標準：

1. 每個工程師的呼叫響應數量 ;
2. 每個工程師被呼叫的時間間隔 ;
3. 非工作時間接收到的 (發生在正常工作時間之外的呼叫) 呼叫數量。

這些度量標準，以及如何對其作出響應，對於維護一個能夠讓團隊在 on-call 實踐中茁壯成長的組織架構至關重要。舉例來說，在 New Relic，從 PagerDuty 獲取到的警報數據可以讓經理和高管們瞭解到一個團隊在給定的時間段內被呼叫了多少次，以及這些警報中有多少是在非工作時間發出的。

跟蹤非工作時間的呼叫有助於將注意力放在那些在不可控的 on-call 負荷中苦苦掙扎的團隊上。什麼是不可控的負荷？在 New Relic，如果一個團隊平均每週有多於一個的非工作時間呼叫，那麼就認為這個團隊有很重的 on-call 負荷。

如果團隊的負擔過重，就需要考慮讓團隊將精力集中到償還技術債務或將工作自動化之上，直到 on-call 的負荷降低為止。或者，像 New Relic 一樣，以高級 SRE 的形式為團隊提供支持，以幫助團隊改進服務。

選擇 on-call 模式時需要考慮的問題

On-call 模式不必過於複雜，但它必須確保指定的工程師隨時能夠對呼叫做出響應，並處理在其職責範圍內的事故。On-call 模式應該解決的問題包括：

• 如何為每次 on-call 輪轉選擇團隊成員？
• 每次輪轉會持續多久？
• 如果某個 on-call 工程師未能響應呼叫會發生什麼？
• 如果一名工程師無法勝任處理 on-call 呼叫的任務，有哪些可供選擇的選項？
• 同一時間有多少工程師處於 on-call 狀態？
• 多名 on-call 的工程師如何分工？
• 團隊如何處理計劃外的輪轉和其他不可預見的事故？

對於包含多個團隊的大型組織，這些問題的答案也取決於團隊自治的程度。DevOps 組織通常都更偏愛更高程度的團隊自治，不過有些組織比其他組織更加重視這個概念。

事故響應：當尋呼機響起時發生了什麼

一個組織的 on-call 流程是該組織軟件質量和可靠性實踐的一個關鍵的方面。另一個密切相關的方面則是其事故響應程序。

事故響應涵蓋了各種各樣的事件，從普通的到可怕的；如果沒有專門的監控工具的幫助，有些事故極有可能會被忽略，而另一些事故則可能會對數百萬用戶造成影響，成為全國性的頭條新聞。

New Relic 將“事故”定義為任何可能對客戶造成負面影響的系統的意外行為。

和許多軟件公司一樣，New Relic 不可能等到事故發生後再製定計劃。我們需要迅速有效地採取行動。我們必須有一個清晰的計劃，並且時刻做好準備。

1. 在客戶之前發現事故

一個成功的事故響應系統的目標很簡單：在客戶受到影響之前發現事故，最理想的情況是發現並修復它。

作為一個組織，我們的目標是確保我們永遠不會等到憤怒的客戶在 twitter 上談論的時候，才發現事故——沒有什麼比這更糟糕了。我們也希望不會有憤怒的客戶給支持人員致電，這也不是我們所希望的。

在 New Relic，我們喜歡說我們“喝自己的香檳”(這比“吃自己的狗糧”要好)。工程團隊可以自由選擇他們用來構建服務的技術，但有一個條件：服務必須能夠被儀表化。這意味著必須有監控和警報。（絕大多數情況下，我們都會使用自己的產品，只有極少數情況例外。）

當然，如前所述，工程團隊針對各自管理的服務都有相應的 on-call 輪轉機制。良好的監控設置和主動的事故報告，意味著一旦發現問題，就會立刻呼叫工程師——最好是在客戶注意到問題之前。

2. 開發一個用於評估事故嚴重性的系統

有效的事故響應始於一個能夠根據事故的嚴重程度對事故進行排名的系統——通常用對客戶造成的影響作為衡量標準。New Relic 的內部事故嚴重程度量表為組織構建自己的事故響應流程提供了一個很好的起點；它基於 1-5 級的排行，每個級別都有明確的標準：

• 級別為 5 的事故永遠不應該產生客戶影響，可以簡單地把它定義為提高對有風險的服務部署等問題的認識。
• 級別為 4 的事故則包括對客戶造成影響不大的小錯誤或數據延遲。
• 級別為 3 的事故包括較大的數據延遲或不可用的特性。
• 級別 1 和級別 2 的事故是為產品短暫的、完全的中斷或對業務造成直接威脅的事故預留的。幾年前 New Relic 發生的“Kafkapocalypse”事件就是這種級別事故的一個例子。

每個事故級別都對應一個特定的約定，以此調用內部資源、管理響應、決定是否與客戶溝通、如何溝通，以及其他一些任務。New Relic 將突發事故視為最嚴重的事故；這些事故通常需要更高層級的響應，某些情況下，甚至需要法律、支持和領導層團隊的直接參與。

研究事故會如何影響客戶並對客戶體驗造成影響；思考響應團隊用於診斷、控制和解決問題所需的資源都是非常重要的。

在 New Relic，在事故發生時我們通過為事故分配一個嚴重級別以確定我們需要多少支持。然後，在事故發生後，會根據客戶的實際影響重新評估該事故的嚴重級別。這反映了 New Relic 的一個關鍵的事故響應原則：我們鼓勵工程師在事故發生時迅速提升事故的嚴重級別，這樣就可以得到所需要的支持以解決問題。事故結束後，我們會對事故的實際影響做出評估，如果事實證明影響並沒有最初所擔心的那麼嚴重，就會下調事故的嚴重級別。

3. 為響應團隊定義和分配角色

下表概述了 New Relic 配備事故響應團隊成員所使用的角色。這其中的許多角只有在特定的嚴重級別才會出現。在其他情況下，分配給角色的職責取決於事故的嚴重程度：

4. 設置事故響應場景

絕大多數組織都無法完全模擬實際的事故響應——尤其是嚴重級別較高的事故。不過，即便是有限的模擬也可以讓您瞭解在事故發生時會出現什麼情況，如何設置優先級和升級流程，如何協調團隊中的角色，以及其他關鍵洞見。

讓我們來看一下 New Relic 的一個假想事故的案例：

事故的模擬從一個 New Relic 產品團隊的 on-call 工程師收到呼叫開始。監控該工程師所負責的一項服務的 New Relic Synthetics 健康檢查小黃人通知工程師健康檢查出現失敗。工程師在 New Relic Insights 儀表板上查看了這項服務，發現健康檢查確實失敗了——吞吐量在下降，她擔心客戶會因此受到影響。這是怎麼回事？她該怎麼辦？

首先，她在我們指定的 Slack 通道發佈一起事故。機器人 Nrrdbot(GitHub 機器人 Hubot 的克隆版本) 將會指導她完成這個過程。因為她決定擔當事故指揮員的角色，她輸入了“911 ic me”。Slack 管道的報頭會隨之更新，並在 Upboard（公司內部自建的事故跟蹤器）中創建一個新的處於打開狀態的事故；Nrrdbot 直接通知她後續的步驟。

IC 現在需要完成三項工作：

1. 為事故設置一個嚴重級別（到底有多嚴重？）
2. 為事故設置一個標題（簡要概述出了什麼問題）並設置事故當前的狀態（簡述目前進展如何）。
3. 找到一名或多名技術負責人調試問題。如果 IC 是 TL 的最佳人選，那麼就讓其他人選接管 IC 的角色，因為 IC 不應該承擔對事故做技術分析的職責。

IC 設置的嚴重級別將決定誰會在這次響應中提供幫助。對於嚴重級別至少在 3 級以上的事故，支持部門會自動指派一名團隊成員作為溝通負責人（CL）參與這一事故。CL 的工作是協調與客戶的溝通；他們會轉發所有與事故相關的客戶投訴，並根據工程師最新的發現主動與客戶進行溝通。

此時，IC 會打開一個眾包協作文檔，與參與響應的所有人共享。IC 負責管理所有參與響應的各方之間的溝通流程。她還會在需要的時候提供支持，更新狀態 (每 10 分鐘更新一次，或者在 Nrrdbot 提醒她的時候)，並在情況發生變化（好轉或惡化）時更新嚴重級別。

如果問題在 60-90 分鐘內仍未得到解決，她會將 IC 的角色轉交他人，因為這是一項相當耗費精力的職責，尤其是當凌晨 3 點從熟睡中醒來的時候。

一旦問題完全解決，所有負責人都確認滿意度後，IC 會在 Slack 通道中輸入“911 over”。這一操作會將事故置為關閉狀態。

5. 抱最好的希望，做最壞的打算

上面的例子模擬了 New Relic 的一個重大事故，但是它並未上升到真正的緊急狀態。緊急事故極為罕見 (至少應該如此)，但它們對企業構成的威脅要大得多。事實上，在真正最糟糕的情況下，如果事故升級到無法控制的程度，它可能會變成生死存亡的威脅。

在 New Relic，嚴重級別為 1 或 2 的事故集會自動觸發一個後臺進程，該進程將呼叫 New Relic 緊急響應部隊 (NERF) 中的一名成員和一名 on-call 的工程高管。NERF 的團隊成員都是 New Relic 經驗最豐富的員工，他們對我們的系統和架構以及事故管理流程都有深入的瞭解。他們擅長處理嚴重事故，特別是當這類事故需要協調多個團隊時。

高管與 NERF 成員共同加入事故響應團隊，承擔三個關鍵職責：通知高級管理人員；協調法律、支持和安全團隊；做出艱難的決定。

6. 通過事故學習、改進和成長

作為從事故中獲取知識和學習的第一步，示例中的 New Relic IC 在事故結束後還將執行幾項任務：

• 將最終細節彙總到協作文檔中，包括:
• 事故持續時間 ;
• 對客戶的影響 ;
• 所有需要回滾的緊急修復 ;
• 在事故中出現的重要情況 ;
• 關於誰應該參與事後回顧的說明 ;
• 確認應該參加無指責回顧的人選 ;
• 選擇一個團隊作為該事故的負責人 (例如上述案例中的 Synthetics 團隊)，以便團隊的工程經理可以安排事後回顧。

我們還要求團隊在事故發生後的一到兩個工作日內進行回顧。New Relic 組織了“無指責”的回顧，旨在發現問題的根源，而不是尋找替罪羊。在這裡瞭解更多關於 New Relic 如何構建和使用無指責回顧作為其對 DevOps 最佳實踐的更廣泛的承諾的一部分。

7. 實現“不重複事故”（DRI）的策略

在 New Relic，如果服務事故對客戶造成影響，我們有一個“不重複事故”(DRI) 的策略，該策略強迫我們停止對該服務的任何新工作，直到我們修復導致該事故發生的根本原因或提出相應的減緩措施。DRI 流程在 New Relic 工程團隊的成功中扮演了重要的角色——能夠確保他們識別並償還技術債務，通過其他手段，技術債務通常無法得到更優先的安排。

重要的是要記住，我們的目標不是完全消除偶然事故——這是不現實的。相反，New Relic 希望其團隊能夠更有效地應對將來確定會發生的事故。

現在輪到你了：能夠為事故響應計劃提供指導的問題列表

我們已經討論了很多關於 New Relic 如何處理 on-call 和事故響應流程的內容，並提供了一系列最佳實踐。我們鼓勵你制定清晰的指導方針，以便你的團隊能夠清楚地理解期望；識別並減少在事故響應和解決過程中出現最嚴重的摩擦；並決定如何正確地組織您的 on-call 和事故響應流程。

回答以下問題可以幫助你更有效地執行上述這些工作。

規模：你所在的工程機構有多大規模？每個團隊有多大規模？團隊能處理什麼類型的輪轉？

增長：工程機構的增長有多快？週轉率是多少？

地理：您的組織機構在地理上是集於一處的還是分佈廣泛的？您是否有足夠的規模和分佈來採取“跟隨太陽”的輪轉方式，或者工程師是否需要處理非工作時間的呼叫？

組織結構

複雜性：您的應用程序是如何構造的？您的工程師所支持的是嵌入到更大的系統體系結構中的定義良好的插件式服務，或者您的產品是由不同團隊支持的單一應用程序？

依賴關係：有多少客戶 (內部或外部) 依賴於您的服務？如果服務失效，破壞範圍有多大？

工具：您的事故響應流程和工具複雜性如何？團隊的運行記錄和監控的全面度和及時度如何？工程師做出呼叫響應時是否有足夠的工具和組織支持？工程師能否自動收到可操作的問題通知？

期望：在你們的工程文化中，On-call 是否正在成為規範？它是否被視為工作中有價值和必要的一部分，還是額外的負擔？

文化：你的公司是否擁有無指責的文化，專注於真正的根源並解決系統性的問題，或者你們的公司文化是“責備和羞恥”的文化，出錯時人們會因此受到懲罰？

https://blog.newrelic.com/engineering/on-call-and-incident-response-new-relic-best-practices/

閱讀更多 InfoQ 的文章

關鍵字: Google 運維 事故