目錄
- SRE落地與組織架構實踐
- 技術架構與組織架構的匹配
- 技術架構示例
- 運維職責分工
- 技術保障體系
- SRE = 多角色團隊
- 總結
SRE落地與組織架構實踐
在落地 SRE 時，很多團隊最關心的問題之一就是組織架構：我們究竟需要怎樣的團隊形態，才能支撐微服務和分布式架構下的高可用性和高效運維？
技術架構與組織架構的匹配
在討論組織架構之前，有兩個前提必須明確：
-
組織架構要與技術架構匹配
技術架構是實現組織目標的手段，組織架構是服務技術架構落地的載體。單純調整組織架構而不考慮技術現狀，往往收效甚微。 -
SRE 是分布式架構的產物
SRE 理念最早在 Google 出現，解決的是超大規模分布式系統的運維復雜性問題。
隨著微服務和分布式架構流行，SRE、DevOps、容器技術、持續交付等一系列方法論應運而生，它們都是為降低架構復雜度、提升穩定性而存在的。
現實情況是：幾乎所有成熟的 SRE 實踐都是建立在微服務和分布式架構之上的，無論是 BAT、字節跳動、美團，還是中等規模的公司如蘑菇街，甚至傳統行業如部分運營商和銀行。
所以，如果你的技術架構還很簡單，甚至沒有微服務化需求，其實完全可以不引入 SRE 體系，否則技術和組織都可能“跑偏”。
技術架構示例
-
基礎設施層（IaaS）
包含 IDC、服務器、虛擬機、存儲、網絡等。
傳統運維的職責主要在這里，但如果上云，絕大部分基礎能力可由云服務替代。 -
技術中臺
包括數據庫、緩存、消息隊列、對象存儲、大數據等“有狀態”產品。
這一層對穩定性和性能要求高，需要專業團隊維護，如果使用公有云，可由 PE（Production Engineer）負責運維。 -
業務中臺
提煉業務共性能力，如用戶、商品、交易、支付、風控、優惠等。
無狀態服務為主，支撐業務前臺應用。 -
業務前臺
具體業務產品，例如蘑菇街的購物應用。
PE 團隊與業務開發一起對系統穩定性負責。 -
接入層
- 四層負載均衡：傳統運維管理
- 七層負載均衡：需理解業務規則，由 PE 或應用運維團隊管理
運維職責分工
在這個架構下，運維能力沿著技術棧逐層展開：
| 層級 | 主要職責 | 典型角色 |
|---|---|---|
| 基礎設施層 | IDC、服務器、網絡、存儲等 | 傳統運維 / 云平臺 |
| 技術中臺 | 中間件、數據庫、緩存、消息等 | 中間件團隊 / PE |
| 業務中臺 & 前臺 | 業務應用、微服務 | PE / 技術運營 |
| 技術保障體系 | 工具平臺、穩定性平臺 | 工具平臺開發 / 穩定性平臺開發 |
PE 是 SRE 實踐的核心，職責包括自動化工具使用、服務治理、穩定性保障等。國內 PE 與 Google SRE 最大差異在于軟件工程能力相對弱一些，需要依賴技術保障平臺提供支撐。
技術保障體系
技術保障體系基于技術中臺能力生長，包括：
-
工具平臺團隊
- 實現 CMDB、運維自動化、持續交付流水線、報表等
- 側重研發流程和系統集成，技術門檻中等
-
穩定性平臺團隊
- 提供監控、限流降級、全鏈路跟蹤、容量壓測、AIOps 等能力
- 技術要求高，需要深入底層代碼、處理海量數據、實時計算
技術保障體系的價值在于支撐整個業務團隊的穩定性，脫離技術中臺則意義不大。
SRE = 多角色團隊
總結來看，一個典型的 SRE 團隊不是單一崗位，而是由多個角色組成：
SRE = PE + 工具平臺開發 + 穩定性平臺開發
這些角色緊密結合技術中臺和分布式架構，形成完整的穩定性保障鏈條。
在組織設計上，SRE 與承擔技術中臺或中間件建設的團隊同屬于一個體系。
總結
- SRE 并不是簡單崗位定義，而是一套團隊實踐和協作模式
- 組織架構必須與技術架構匹配，分布式和微服務化是 SRE落地前提
- PE、工具平臺開發、穩定性平臺開發是核心角色，各司其職，協同保障業務穩定性
)
