太多的公司所用的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度量標準：

每個工程師的呼叫響應數量;

每個工程師被呼叫的時間間隔;

非工作時間接收到的(發生在正常工作時間之外的呼叫)呼叫數量。

這些度量標準，以及如何對其作出響應，對于維護一個能夠讓團隊在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現在需要完成三項工作：

為事故設置一個嚴重級別（到底有多嚴重？）

為事故設置一個標題（簡要概述出了什么問題）并設置事故當前的狀態（簡述目前進展如何）。

找到一名或多名技術負責人調試問題。如果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和事故響應流程。

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

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

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

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

組織結構：工程機構的結構如何？是否采用了現代的DevOps文化，在這種文化中，團隊負責服務的從開發到運營的完整生命周期，或者開發和運營是割裂的？您是否擁有一個集中化的SRE小組，或者SRE遍布于整個組織的工程團隊中？

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

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

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

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

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

英文原文：

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

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的高效运维最佳实践：如何做好On-call和事故响应？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。