本期我們就以Google經典運維體系理念——SRE為例，通過對SRE的主旨內容剖析，梳理SRE與運維開發之間的聯系，同時通過典型SRE落地案例詳解，與大家一同探討SRE在金融行業的落地經驗。

01. SRE主旨內容概覽

1）什么是SRE

首先我們來看看SRE的幾個定義：

分別來看，起源于Goole的SRE相對于它的組織來說，定義得是較為契合的，首先Google具備較強實力的人才儲備，其次，經過了大量的內部實踐，是經得起考驗的，同時由內而外的推動使得這一體系的落地情況也比較全面。但對于國內企業來說， 全能型的人才稀缺以及傳統理念的固化讓這一定義顯得并不是那么的完善。

站在國內企業自身的角度來看，我們更傾向于第三種：從實踐角度看 SRE 的關鍵點，就一個詞：體系化，我們需要用全局視角才能更透徹的理解它。SRE實際上是需要多個團隊、多個崗位分別去承擔不同職能，并且各個團隊之間能夠相互協作合力，同時對外與業務團隊、產品團隊連接，構建工具去實現日常的運維和運營。

2）SRE與DevOps關系

本質上來講SRE與DevOps沒有很大差別，都是伴隨著分布式、云原生、容器化、微服務等技術所衍生出來的一些理念，我們可以理解為DevOps是SRE核心理念的普適版。相比起來，DevOps比較抽象，而SRE是Google將DevOps具體實踐后所提煉出來的理論體系。

3）SRE指導思想與關鍵概念

SRE具備以下幾個指導思想：

• 擁抱風險：不確定性始終存在，我的目標是通過一系列的方法，去減少風險。
• 服務質量目標：透過具體指標反應運維水準，反過來約束失誤可靠性。
• 減少瑣事：減少日常重復、人工介入的工作，與自動化聯動。
• 分布式系統監控：全局可觀測性建立。
• 自動化系統：與減少瑣事對應，增強自動化能力。
• 發布工程：在確保穩定性的基礎上，盡可能快的進行發布，滿足業務需求。
• 盡可能簡單化：工具、工作盡可能簡單。

圍繞以上指導思想，我們可以將SRE的一些關鍵概念串聯起來，從而對SRE體系有更明確的認知。

關鍵概念上，主要分為四個層面：

• 指標層：具體描述與SRE相關的指標
• 標準層：SRE相關系列標準
• 工具層：核心常用工具
• 體系層：圍繞SRE建立的流程制度與體系

4）SRE崗位/團隊的主要工作

了解了SRE整個體系的工作方式與方法以后，SRE具體團隊在做什么樣的內容呢？主要分以下三個板塊：

• 參與運維架構標準制定：包括一些技術組件如何選擇、日志規范如何設計、以及其他系統的規范和標準的制定。
• 運維產品開發：當標準梳理清楚之后，在運維日常工作方面，將瑣事提煉為產品需求、規劃能力，從而以產品為中心提升自動化，同時需要注意各個工具之間如何融合打通，避免煙囪式的建設。
• 日常技術運營：在標準化、平臺化之后，針對運維日常工作進行改進和優化。

在這個過程中，我們可以下一個論斷，即：運維模式/體系的下一站是SRE，而運維技術的下一站是AIOps。

5）SRE方法論

方法論層面，主要有以下幾個重要點：

• 確保長期關注研發工作：Google將SRE團隊的運維工作限制在50%以內。
• 監控系統：一個監控系統應該只有三類輸出：緊急警報（立即執行）/工單（短期內執行）/日志（被動關注）。
• 變更管理：漸進式發布、迅速而準確地檢測問題、安全迅速回退
• 資源部署：資源的部署是變更管理與容量規劃的結合物
• 在保障服務SLO的前提下最大化迭代速度：系統總是不穩定，通過引進“錯誤預算”的概念，解決研發團隊和SRE團隊之間的組織架構沖突。
• 應急事件處理：以MTTR為核心，不靠萬能工程師，靠運維手+on-call人員常規性解決
• 需求預測和容量規劃：保障一個業務有足夠的容量和冗余度去服務預測中的未來需求
• 效率與性能：SRE也必須承擔起任何有關利用率的討論及改進。

02. SRE運維平臺與運維開發

1）運維管理平臺：實現SRE運維開發的底座

SRE反復強調運維組織需要大量的參與到運維工具開發中去，來實現SRE的轉型。而做工具的開發，傳統企業與互聯網公司會有較大的區別。

• 對于大型的互聯網企業而言，由于具備較強的開發能力，企業可以基于開源去打造各類工具，同時也可以不基于平臺，或者基于弱平臺去做各個工具的打通。
• 而對于傳統企業來說，是比較難以去從零開始打造一個新的平臺的，同時不同的開源工具之間的打通也比較難以靠自身去實現。

因此對于大多數企業來說，要實現SRE運維開發，需要一個統一的底座——具備通用能力、通用開發框架，同時提供統一的資源納管，以及資源驅動等能力，借助統一底座，下層資源統一納管實現數據打通和能力擴展，上層通用能力框架實現工具開發，可控生長，建立基于平臺的完整運維開發體系。

其中包括幾個典型的場景：

CMDB——SRE運維管理體系的基石，建立消費驅動的，可視、可用、可信、可靠的運維高質量CMDB，支撐運維開發轉型。

可觀測性——助力SRE實現全鏈路追蹤與問題根因定位。構建trace、log、metric關聯分析鏈路，依賴于平臺，實現數據的統一處理。

自動化編排引擎——SRE自動化運維的抓手，自動化場景的建設需要底層引擎的支撐，調用基本能力構建上層自動化體系，支撐SRE工具能力拓展。

03. SRE在金融行業落地探討

1）落地案例分析

以國內某大型銀行SRE實踐為例，其SRE落地進程有以下幾個重要關鍵點：

① 確定SRE落地的核心理念：

符合長期戰略，改善運維手動、重復性工作，建立SRE團隊提升運維價值。

② 組建SRE試點團隊：

包含團隊負責人，輪值團隊經理，業務核心技術成員，其他部門協助人員，從不同的團隊中抽調相應人員，保證每位人員都清楚的認知SRE的建設目標，力出一孔。

③ SRE工作模式：采取平戰結合模式。

• 平時建設（即日常模式）：解決運維日常問題，保證系統可用性、可靠性、穩定性，減少出故障的時間和概率，保障運維質量。
• 戰時應急（即應急模式）：建立快速處理機制，SRE團隊開展故障處置，第一時間恢復生產。

戰時應急依賴于平時建設的工具、自動化能力、問題總結等，形成平戰結合的工作模式。

④ SRE團隊OKR：

團隊OKR的制定與工作模式緊密配合，通過平戰結合的模式，實現全景業務系統可感可見，應急處置可管可控，業務指標可計可析。同時SRE團隊建立三會機制，即周例會、月例會、專題會，保證日常工作與專項事宜的快速處理。

目前來看該行的SRE實踐是比較成功的，其核心在于SRE團隊的組建，一方面需要有開發人員介入，核心業務人員要懂開發，懂架構，具備運維開發能力。另一方面需要具備組織能力，SRE建設目標分解到各個團隊中，人員之間實現能力的融合，從而形成體系化的組織，推進整體SRE進程。

除此之外我們對眾多企業SRE進程和落地實踐也進行了詳細的深入分析，包含農業銀行、騰訊、美圖等，如您感興趣，歡迎點擊了解詳情！

2）經驗探討

① SRE是否適合在金融行業落地？

SRE是一個體系化的過程，從組織架構、到文化宣貫、到工具構建、到人員能力配備都具備以后，才能形成完整的SRE體系。

• 在中大型銀行來說式比較適合的，中大型銀行未來運維通常都會向著分布式、微服務、容器以及云架構方向去發展，同時運維團隊規模比較大，擁有足夠的團隊和資金支撐SRE落地。
• 對于中小型銀行來說，通常會以傳統架構為主，有的單位會建設一部分云資源。如果說短期內企業并沒有短期內進行容器化、分布式的建設規劃的話，落地SRE是比較困難的。

我們建議可以先針對其中某一方向，例如工具向平臺化層面去靠攏，同時如果還有富余的精力的話可以考慮進行一部分運維開發能力的建設，除此之外組織能力也可以適當培養，從而一步一步向SRE邁進，而不是一步登天。

② 如果要落地，需要注意哪些事項？

主要有3個重點：

• 標準規范制定：標準化、規范化是體系建立的第一步，運維的標準規范需要與開發與業務達成一致。
• 具備軟件開發能力：能夠把運維訴求變成運維產品，然后把運維產品，最終落地成為具體的工具、系統。
• 組織變革：SRE是運維與開發的能力結合，需要一部分懂開發的運維人員，也需要一部分理解運維體系的開發人員，運維與開發需要相互理解，從而將彼此訴求融入到自己的工作中。