目录
- 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、工具平台开发、稳定性平台开发是核心角色，各司其职，协同保障业务稳定性
)
