谷歌SRE運維模式解讀

前面我和你分享了一些關于運維組織架構和協作模式轉型的内容，為了便于我們更加全面地了解先進的運維模式，今天我們再來談一下谷歌的SRE(Site Reliability Engineer)。 同時，也期望你能在我們介紹的這些運維模式中找到一些共通點，隻有找到這些共通點，才能更深刻地了解，并借鑒到真正對我們有用的東西。

專欄的第一篇文章我們介紹了Netfix的NoOps模式。這個模式并不意味着不存在任何運維工作，隻是Netfix将這些事情更緊密地融入到了日常的開發工作中，又做得非常極緻，所 以并沒有很明顯地展現出來。

但是，谷歌的SRE卻是一個真實具體的崗位，也有明晰的崗位職責。從借鑒意義上來講，SRE可以給我們提供更好的學習思路和樣闆。 SRE這個概念，我應該是2014年下半年的時候聽到的。當時可接觸的資料和資訊有限，隻知道是谷歌對運維崗位的定義，負責穩定性保障，就沒有更多其他的認識了。

後來，有越來越多在谷歌工作或接觸過這個崗位的專家開始在公開演講中分享這個概念。同時，《SRE:Google 運維解密》，這本由多名谷歌SRE親筆撰寫的圖書也開始在國内廣 泛流傳，讓我們對很多細節有了更加細緻的了解。

SRE崗位的定位 首先，SRE關注的目标不是Operation(運維)，而是Engineering(工程)，是一個“通過軟體工程的方式開發自動化系統來替代重複和手工操作”的崗位。我們從SRE這本書的前面幾 個章節，可以看到谷歌不斷強調SRE的工程能力。我簡要摘取幾段:

Common to all SREs is the belief in and aptitude for developingsoftware systems to solve complex problems.

所有的SRE團隊成員都必須非常願意，也非常相信用軟體工程方法可以解決複雜的運維問題。

By design, it is crucial that SRE teams are focused on engineering.

SRE模型成功的關鍵在于對工程的關注。

SRE is what happens when you ask a software engineer to design anoperations team.

SRE就是讓軟體工程師來設計一個新型運維團隊的結果。

與之相對應的，還有一個很有意思的地方，整本書中提到Operation的地方并不多，而且大多以這樣的詞彙出現:Operation load，Operation overload，Traditional/Manual/Toil/Repetitive Operation Works 。你可以仔細體會一下，這些大多就是傳統的純人工操作模式下的一些典型詞彙。

我們可以看到，從一開始，谷歌就沒把SRE定義為純操作類運維的崗位，也正是谷歌換了一個思路，從另外一個次元來解決運維問題，才把運維做到了另一個境界。

SRE崗位的職責 書中對SRE的職責定義比較明确，負責可用性、時延、性能、效率、變更管理、監控、應急響應和容量管理等相關的工作。如果站在價值呈現的角度，我覺得可以用兩個詞來總結，就 是“效率”和“穩定”。

接下來，詳細說下我的了解和分析。 SRE的能力模型，不僅僅是技術上的，還有産品設計、标準規範制定、事後複盤總結歸納這些技術營運能力，同時還需要良好的溝通協作能力，這個就屬于職場軟技能。

SRE，直譯過來是網站穩定性工程師。表面看是做穩定的，但是我覺得更好的一種了解方式是，以穩定性為目标，圍繞着穩定這個核心，負責可用性、時延、性能、效率、變更管理、監 控、應急響應和容量管理等相關的工作。

分解一下，這裡主要有“管理”和“技術”兩方面的事情要做。 管理體系上，涉及服務品質名額(SLI、SLA、SLO)、釋出規則、變更規則、應急響應機制、On-Call、事後複盤機制等一系列配套的管理規範和标準制定等。

技術體系上，以支援和實作上述标準和規範為目标，涉及自動化、釋出、監控、問題定位、容量定位，最終以電子流程串聯各個環節，做到事件的閉環。 可以看到技術上的平台和系統是用來支撐管理手段的。谷歌的運維其實并沒有單獨去提自動化、釋出、監控等内容，而是通過穩定性這個核心目标，把這些事情全部串聯在一起，同 時又得到了效率上的提升。

我們來看幾個主要的系統。

自動化。是為了減少人為的、頻繁的、重複的線上操作，以大大減少因人為失誤造成的故障，同時提升效率。比如谷歌内部大名鼎鼎的Borg系統，可以随時随地實作無感覺的服務 遷移。現在，它的開源版本，已然成為業界容器編排體系标準的Kubernetes。

持續傳遞。谷歌非常重視持續傳遞。由于它的需求疊代速度非常快，再加上是全球最複雜的分布式系統，是以就更加需要完善的釋出系統。

問題定位。這塊跟監控相關但又有不同。我看到谷歌SRE這本書中并沒有提到太多Tracing 的内容，更多的是講監控和問題管理層面的跟蹤機制。其實，關于問題定位，谷歌 的Dapper大名鼎鼎，功能很強大，國内外很多跟蹤系統和思路都參考了Dapper的理論。這塊也是為了能夠快速定位問題，保障穩定而産生的，國内分享的大多關于全鍊路跟蹤和 分析、限流降級、開關和預案系統、強弱依賴等都屬于這個範疇，我認為這塊應該更準确地定義為分布式服務治理相關的内容。

各類分布式系統。如分布式鎖、分布式檔案、分布式資料庫，我們熟知的谷歌三大分布式論文，就是這些分布式系統的優秀代表，也正是這三大論文，開啟了業界分布式架構理念 的落地。

這些系統大都是以穩定性為導向，同時帶動了日常運維效率的大幅度提升，有了監控和全鍊路這樣的問題發現和定位手段，也大大提升了我們對故障處理和問題定位的效率。容量管理，不僅僅可以保障容量充足，還能最大程度地保障資源配置設定的合理性，盡可能減少浪費，對于成本管控也大有好處。是以，圍繞着穩定性這個核心目标，不僅達到了穩定的目的，還獲得了高效的運維效率。

是以，SRE的理念通過穩定性這個核心點，将整個運維體系要做的事情非常系統緊密地整合起來，而不是一個個孤立的運維系統。是以，SRE是一個崗位，但更是一種運維理念和方法 論。

如何借鑒和落地

在國外，SRE崗位的薪資，和SWE軟體開發工程師相比，要平均高出25%。從實際的崗位要求上看，SRE的技能要求也要比SWE更高、更全面，是以這樣的人才是比較緊缺的。即 使在國外，除了谷歌、Facebook以及Netfix這樣超一流的科技公司能夠招聘到，或者内部培養出較多這樣的人才，其它公司的SRE、PE或者應用運維也無法完全達到上面的要求。