SRE 系列（七）| 从技术架构到团队组织

SRE落地与组织架构实践

在落地 SRE 时，很多团队最关心的问题之一就是组织架构：我们究竟需要怎样的团队形态，才能支撑微服务和分布式架构下的高可用性和高效运维？

在讨论组织架构之前，有两个前提必须明确：

组织架构要与技术架构匹配

技术架构是实现组织目标的手段，组织架构是服务技术架构落地的载体。单纯调整组织架构而不考虑技术现状，往往收效甚微。
SRE 是分布式架构的产物

SRE 理念最早在 Google 出现，解决的是超大规模分布式系统的运维复杂性问题。

随着微服务和分布式架构流行，SRE、DevOps、容器技术、持续交付等一系列方法论应运而生，它们都是为降低架构复杂度、提升稳定性而存在的。

现实情况是：几乎所有成熟的 SRE 实践都是建立在微服务和分布式架构之上的，无论是 BAT、字节跳动、美团，还是中等规模的公司如蘑菇街，甚至传统行业如部分运营商和银行。

所以，如果你的技术架构还很简单，甚至没有微服务化需求，其实完全可以不引入 SRE 体系，否则技术和组织都可能"跑偏"。

基础设施层（IaaS）

包含 IDC、服务器、虚拟机、存储、网络等。

传统运维的职责主要在这里，但如果上云，绝大部分基础能力可由云服务替代。
技术中台

包括数据库、缓存、消息队列、对象存储、大数据等"有状态"产品。

这一层对稳定性和性能要求高，需要专业团队维护，如果使用公有云，可由 PE（Production Engineer）负责运维。
业务中台

提炼业务共性能力，如用户、商品、交易、支付、风控、优惠等。

无状态服务为主，支撑业务前台应用。
业务前台

具体业务产品，例如蘑菇街的购物应用。

PE 团队与业务开发一起对系统稳定性负责。
接入层
- 四层负载均衡：传统运维管理
- 七层负载均衡：需理解业务规则，由 PE 或应用运维团队管理

在这个架构下，运维能力沿着技术栈逐层展开：

PE 是 SRE 实践的核心，职责包括自动化工具使用、服务治理、稳定性保障等。国内 PE 与 Google SRE 最大差异在于软件工程能力相对弱一些，需要依赖技术保障平台提供支撑。

技术保障体系基于技术中台能力生长，包括：

技术保障体系的价值在于支撑整个业务团队的稳定性，脱离技术中台则意义不大。

总结来看，一个典型的 SRE 团队不是单一岗位，而是由多个角色组成：

SRE = PE + 工具平台开发 + 稳定性平台开发

这些角色紧密结合技术中台和分布式架构，形成完整的稳定性保障链条。

在组织设计上，SRE 与承担技术中台或中间件建设的团队同属于一个体系。