Google SRE最佳實踐之On-Call

本系列文章將詳細介紹如何從0到1快速構建SRE團隊具體實戰內容，敬請關注。

"On-call"言下之意就是"隨叫隨到，待命"。on-call意味著在一定時間內隨叫隨到，並做好生產環境出現緊急情況的應對準備。SRE工程師經常被要求要輪值on-call，在on-call期間，SRE會根據需要對緊急情況進行診斷、環境、修復或升級事件;此外,SRE還要定期負責非緊急性生產任務

在Google，On-call是SRE的特點之一。SRE團隊可以緩解事故、修復生產問題並自動執行運維任務。由於我們的大多數SRE團隊尚未完全自動化所有運維任務，因此升級扔需要人工聯繫On-call工程師進行處理。根據所支持系統的重要程度或系統所處的開發狀態，並非所有SRE團隊都可能需要被on-call；根據我們的經驗，大多數SRE團隊都會進行輪值

On-call是一個大而複雜的話題,承載著許多限制因素和有限的試錯率

在《Site Reliability Engineering》一書11章節已討論過該話題，這裡列舉下對蓋該章節的一些反饋:1."我們不是Google，我們小的多，並且我們沒有那麼多人進行輪值和沒有不同時區的網站，《Site Reliability Engineering》描述的跟我們無關"

"我們有開發和DevOps人員混合進行輪值，如何組織他們有最佳實踐嗎？劃分職責？"

"我們的On-call工程師在典型的24小時輪班中，被呼叫了一百多次。很多頁面都被忽略掉了，而真正的問題卻被埋沒，我們應該從何入手？"

"我們的On-call輪轉很快，如何解決團隊內部的知識差距？"

"我們想把DevOps團隊重組為SRE。SRE On-call、DevOps On-call、開發人員On-call三者之間有什麼區別？DevOps團隊也非常關心這個問題"

Google為這些情況提供了一些實用建議，下面以Google和Evernote的兩個例子進行說明:

Google: 組建新團隊最初的場景

幾年前，在Google總部山景城的SRE sara開始組建新的SRE團隊，並在三個月內開始輪值On-call。從這個角度看,Google的大多數SRE團隊並不希望新員工在3-9月前準備On-call。新的山景城SRE團隊將支持三個Google App服務，這些服務以前是由華盛頓柯克蘭(距離到山景城2個小時航班)的SRE團隊負責。柯克蘭還有一個在倫敦的姊妹團隊，將繼續和新的山景城的SRE團隊以及分散式產品開發團隊一起負責支持這些服務。山景城的SRE團隊很快組建，成員結構:

Sara SRE團隊負責人

Mike 其他SRE團隊的有經驗的SRE

一個從產品開發團隊轉崗為SRE

4位新僱員工

即使一個成熟的SRE團隊，在為新業務服務時也總是具有挑戰性的，尤其對於山景城SRE這樣年輕的SRE團隊來說。儘管如此，新團隊能夠在不犧牲服務質量和項目進度的情況下提供服務。他們很快對服務進行改進，包括降低40%的機器成本，並且完全自動化灰度發布及其他安全檢查。新SRE團隊持續提供可靠的服務，目標是達到99.98%的可用性或每季度大約26分鐘停機時間

新的SRE團隊是如何實現這麼多目標的？答案是通過啟動項目、指導和培訓

培訓路線圖

雖然新的SRE團隊對他們的負責的服務了解不多，但Sara和Mike熟悉Google的生產環境及SRE。當新雇的四位SRE適應公司之後，Sara和Mike整理出了重點領域的清單，在他們正式輪值On-call之前，進行訓練，如下：

管理生產任務

理解調試信息

將流量從集群中抽離

回退失敗的軟體推送

禁止或限速不必要的流量

提高附加的服務能力

使用監控系統(用於報警和大盤)

描述服務業務的體系結構、各種組件和依賴關係

新的SRE通過研究現存的文檔和編碼實驗(指導、動手編程教程)了解到一些信息，並且通過項目上的工作來理解相關的話題。當團隊成員了解到與新SRE的啟動項目相關的特定話題時，這個人就會進行一個簡短臨時的會議，與團隊的其他成員分享這些信息。Sara和Mike介紹了剩餘的話題。該團隊還通過舉辦常見調試、緩解任務的課程，以幫助每個人建立肌肉記憶並讓他們對自己的能力充滿信心。

另外，除了檢查清單外，新的SRE團隊還進行一些列的"deep dives"活動來挖掘他們的服務。該團隊瀏覽監控控制台、確定運行的任務並且嘗試調試頁面。Sara和Mike解釋說工程師不需要多年的專業知識，都會對每一項服務變的相當熟悉。他們指導團隊從最初的原則中探索服務並且孤立SRE工程師熟悉他們服務、他們對自己認知極限敞開大門，並教會了別人在什麼時候尋求幫助。

在整個過程中，新的SRE團隊並不孤單。Sara和Mike去拜訪其他的SRE團隊和產品開發人員並向他們學習。新的SRE團隊通過舉辦視頻會議與柯克蘭和倫敦的團隊會面，發送電子郵件並且通過IRC聊天。此外，該團隊還參加每周一次的生產會議，審閱每天的On-call、事後檢查以及服務文檔。柯克蘭的SRE來進行分享和答疑。倫敦的SRE組織了一場完整的災難場景，並在谷歌的災難恢復周期內進行。

團隊還通過模擬故障進行on-call，練習調試生產問題。在會議期間，鼓勵所有的SRES提出關於如何解決模擬的生產故障的建議。在每個人都得到強化之後，團隊仍然保持這些會議，團隊每個成員輪流擔任會議主導者，將這些記錄作為未來的參考。

在進行On-call之前，團隊回顧了關於職責的指南:

在每個輪值班次開始時，On-call工程師將從上一個班次獲取交接內容

On-call工程師首先要將用戶的影響最小化，然後在確保問題得到徹底解決

輪值結束後，On-call工程師向下一個工程師發送一封交接郵件

指南還規定了什麼時候將事件升級到其他人，以及如何撰寫大型事故報告。最後，團隊閱讀並更新On-call手冊。手冊包含有如何響應自動報警的高級說明。它們解釋了報警的嚴重性和影響，包括調試建議以及可能採取的措施，以減輕影響並徹底解決該問題。在SRE中，每當創建一個告警時，通常會創建相應的說明手冊，這些指南減少了MTTR（平均修復時間），以及人為錯誤的風險。

維護手冊

手冊內容要根據生產環境的變更進行相應的更新。編寫好文檔，就像任何形式的交流一樣，是一件比較困難的事情，那麼如何維護好文檔呢？在Google 一些SRE主張保持文檔的一般性，因此更新會比較慢。例如：針對所有的"RPC錯誤高"的報警，可能只有一條文檔說明，供經過培訓的On-call工程師結合當前告警服務的架構圖來閱讀。另外一些SRE提倡循序漸進編寫文檔，以減少人為不確定性和降低MTTTR。如果團隊成員對文檔內容有不同看法，手冊可能會有多個方向。

這是一個有爭議的話題，如果不同意這種做法，至少要和團隊一起決定手冊具備的最小、結構化的細節，並且關注結構化的細節以外積累的大量信息。將項目中新的、來之不易的生產知識轉化為自動化或監控控制台。當特定的告警觸發時，On-call工程師每次手動運行文檔中確定的命令列表來解決問題，我們建議實現自動化。

兩個月之後，Sara、Mike和其他的SRE轉移到了即將離任的柯克蘭SRE團隊。在第三個月的時候，他們成了主On-call，原來柯克蘭的SRE成了備On-call。這樣的話，如果有需要，Sara他們團隊就很快能能夠接手柯克蘭SRE團隊的工作。接下來，新招的四名SRE將變的更加有經驗，和柯克蘭當地的SRE一起輪值On-call。

好的文檔積累和前面討論的各種策略都能幫助團隊打牢根基，迅速成長。儘管On-call可能會帶來壓力，但是團隊會有足夠的信心，在不抱有懷疑自己的情況下採取行動。當團隊成員意識到他們反應是基於團隊集體的智慧，就會很有安全感，即使他們升級了，那些On-call工程師仍然被認為是稱職的工程師。

後記

當山景城的SRE團隊快速成長時，他們了解到在倫敦有經驗的姊妹SRE團隊將會加入到一個新項目。在蘇黎世組建的新團隊將去支持倫敦SRE團隊先前負責的服務。對於第二次過度中，山景城SRE團隊使用的基本方法被證明是成功的。山景城SRE團隊先前在培訓上的投入用來幫助蘇黎世SRE團隊快速發展。當一組SRE成為團隊時，山景城SREs所使用的方法就是有意義的。當只有一個人加入團隊時，他們需要一種更輕量級的方法。SREs創建了伺服器架構圖，並將基本的培訓清單規範為一系列的練習，這些練習可以在半獨立的情況下完成，並且很少需要導師參與。這些練習包括存儲層、擴容以及檢查HTTP請求的路由方式等

Evernote: 在雲端站穩腳跟遷移基礎設施到雲端

我們並沒有因此重新設計On-call流程。在2016年12月以前，Evernote的所有應用程序都運行在本地傳統數據中心。我們的網路和伺服器都是根據特定的體系結構和數據流進行設計的，這些約束導致我們缺乏水平擴展架構的靈活性。谷歌雲平台(GCP)針對我們的問題提供了解決方案。然而，我們仍然要克服最主要的障礙：將生產環境和支持的基礎設置遷移到GCP。經過70天的努力，取得了非凡的成績(例如：遷移了數千台伺服器和3.5PB的數據)。接著，我們該如何監控、告警以及最重要的是在新環境中出現問題該如何解決？

調整我們的On-call制度和流程

向雲端遷移釋放了我們基礎設施快速增長的潛力，但我們的On-call制度和流程還未適應這種快速增長。在我們以前物理數據中心中，每個組件都有冗餘，組件失敗是一件常事，但不會對用戶產生直接影響，基礎設施是穩定的，因為我們可控。我們的告警策略是基於這樣構建的：一些丟包會導致JDBC連接異常，這意味著虛擬機可能即將發生故障或者我們的一個交換機上有故障。甚至在我們進入雲第一天之前就意識到這種類型的告警在未來可能是無效的，我們需要採取更加全面的監控方法。

根據第一性原則重新構建分頁事件，並編寫這些規則作為我們的SLOs(服務質量目標)，幫助團隊清晰的認識什麼才是重要的告警。我們關注的是更高級別的指標，比如API響應，而不是像InnoDB行級鎖等待細節，意味著我們更多時間集中在停機期間是否對用戶體驗造成影響上。對我們團隊來說，將有更少的時間花費在短暫的瑣事上，這就變的更加有效、更多的休息，最終提升工作滿意度。

重構監控和度量

我們的主On-call輪值是由一個小而精力旺盛的工程師團隊，他們負責生產基礎設施和一些其他業務系統(如：構建基礎設施的pipeline等)。每周都有一個24*7的日程表，都有準備好的交接程序，並在每天早上站會上回顧日常事件。我們團隊規模小，責任大，因此我們盡一切努力降低流程負擔，並專註於盡快結束告警、分流、修復和分析。我們事先這一目標的方法之一就是通過維護簡單有效的報警SLA(服務等級協議)來保持信噪比。我們通過度量或監控生成的事件分為三個類別:

P1：立即處理

應立即採取措施

打開On-call頁面

區分事件分類

是SLO告警

P2：下一個工作日處理

一般來說，不是面向用戶或影響有限

給團隊發送郵件並通知該事件

P3：信息事件

信息被搜集展示在儀錶盤或通過郵件發送

包括容量規劃相關信息

P1和P2事件都附有事故工單，工單用於諸如事件分類、狀態跟蹤、以及SLO影響、發生次數和事後文檔連接。當事件是P1時，On-call工程師根據對用戶的影響程度分為三個等級(1-3)。對於嚴重性1(Sev 1)事件，我們維護了一組有限的標準，使升級決策儘可能簡單。一旦事件升級，我們召集一個事故小組，開始對事故進行管理。事件解決後，我們進行自動檢測，並將結果在內部進行分享。針對Sev2或Sev3級別的事件，On-call工程師來管理事件的生命周期，包括簡單的事後分析和回顧。這就授權並鼓勵在完成事件檢查智慧，立即採取後續行動，並確定工具或流程中的漏洞。通過這種方式，每次On-call的輪值都能達到持續改進和靈活使用的良性循環，與快速變化的環境保持同步。我們的目標就是讓每個On-call的工程師都比上一個做的更好。

跟蹤性能

隨著SLOs的引入，我們希望隨著時間的推移跟蹤性能的變化，並與公司相關團隊分享這些數據。我們實施了一個月的服務審查會議，對任何感興趣的人開放，來審查和討論前一個月服務的運行情況。我們還利用這樣的會議來審查On-call的壓力，將其作為團隊健康狀況的晴雨表，並在超出預算時討論補救措施。這樣的會議有雙重目的，即在公司內部傳播SLOs的重要性，並使技術組織對我們維護的服務和團隊負責。

保證CRE(Customer Reliability Engineering)

我們在SLO方面的目標是與Google客戶可靠工程團隊合作的基礎，在我們與CRE討論SLOs是否是真實可測量的；兩個團隊都決定CRE與我們自己的工程師一起為SLO進行On-call。有時候可能很難找出隱藏在雲抽象層背後的根因，所以google工程師把黑盒事件進行分類是有幫助的，更重要的是，這項工作進一步降低了MTTR，這對用戶來講至關重要。

維持一個自我實現的循環

我們現在有更多的時間來考慮我們如何推動業務發展，而不是將所有時間都花在分類/根因分析/事後調整周期上。具體而言，這可以轉化為諸如改進我們的微服務平台和為產品開發團隊建立敏捷標準；後者包括我們在重組On-call時遵循的許多原則，這對於團隊第一次On-call特別有用。因此，我們將改善所有人On-call循環延續下去，持續改進。

總結

新的SRE通過有經驗的SRE進行指導、培訓快速進入On-call

梳理On-call清單，不斷訓練

編寫完善On-call文檔、事後總結，與相關技術進行review、分享、答疑，持續改進文檔

將生產知識庫轉化為自動化工具或監控

培養促進團隊智慧(如：每個On-call工程師都要完善On-call文檔等)

根據自身環境定義關鍵SLOs，重視監控和度量(衡量問題的指標)

根據故障級別採取不同優先順序的處理策略

譯自: Chapter8.On-Call

http://ow1schdt5.bkt.clouddn.com/books/site-reliability-workbook.pdf

看完本文有收穫？請轉發分享給更多人

歡迎關注「運維ABC」(AI、BigData、Cloud),運維技術社區,專註運維自動化、DevOps、AIOPS、ChatOPS、容器等落地與實踐。

長按下方的二維碼可以快速關注

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！