在过去的20多年里，谷歌的 SRE 都做了些什么
持续交付20约 7 分钟本文是 SRE 系列的第三篇文章，前两篇参见：
1 谷歌 SRE 的起源与组织发展历程
Site Reliability Engineering (SRE) 是 Google 为解决大规模、高增长环境下的运维挑战而创造的方法论和组织结构。它标志着 IT 运营从传统系统管理(System Admin)向软件工程范式的根本转变。
2 SRE 的起源、提出者与核心动因
提出者与时间
SRE 的概念和名称由 Google 的工程副总裁 Benjamin Treynor Sloss 在 2003 年提出。当时他被要求组建一个七人团队，负责管理 Google 的生产运营。
产生的根本原因
SRE 的产生源于规模危机和运维困境：
- 规模需求激增：
随着 Google 服务的爆炸式增长，传统通过雇佣更多系统管理员来管理服务器的模式变得不可持续。这种线性增长不仅成本高昂，效率也低下。 - 软件工程视角：
Treynor Sloss 作为软件工程师，认为运营工作应该被视为软件工程问题来解决，而非依赖手动操作。他的经典定义是：「SRE 是当你要求一位软件工程师来设计一个运维职能时所发生的事情。」 - 消除「人力消耗」（Toil）：
SRE 通过自动化消除手动、重复、缺乏长期价值的操作任务，释放工程师时间专注于系统改进。
3 SRE 在 Google 组织内部的发展历程
谷歌 SRE 在过去二十年（2003 年至今）的发展并非一成不变，而是伴随谷歌规模指数级增长和技术环境演变，经历了多次重大演进和调整。
这些变化主要源于规模适应、核心原则正式化以及应对复杂系统故障的教训。
4 🚀 SRE 在谷歌近 20 年发展中的重大历史事件与转变
1. 初始阶段 (2003-2007)：概念的诞生与核心原则的形成
- 2003 年：SRE 团队成立。
Benjamin Treynor Sloss 成立了最初的“生产团队”，并将软件工程思维引入运营。这是 SRE 的起源。 - 职责能力要求转变。
其职责从传统的手动运维转向自动化编码。团队的工程师必须具备编写软件来解决运营问题的能力。 - 核心原则确立。SLO (服务等级目标)
和 Error Budget (错误预算) 的概念被创造出来，用于平衡产品开发速度和系统稳定性。 - 工作内容转变。
SRE 的工作被分为 50% 的工程项目（消除重复性工作）和 50% 的运营工作（On-call、故障处理）。通过错误预算，SRE 获得了对产品发布节奏的否决权。 - Borg 平台发展。
谷歌的内部容器编排系统 Borg（Kubernetes 的前身）和相关的自动化工具的成熟。 - 职责细分：
出现了平台 SRE 的雏形，专注于构建和维护像 Borg 这样的核心基础设施工具，使得产品团队可以共享资源并降低操作复杂性。
2. 成长阶段 (2008-2016)：系统化、知识外溢与组织扩大
- SRE 规模突破 1000 人。
SRE 成为一个大型、正式的组织（到 2016 年员工超过 1000 人）。这要求组织结构更加专业化。 - 组织结构固化。
确定了 SRE 作为一个独立的组织，不隶属于任何产品开发团队（这确保了 SRE 在追求可靠性时能保持客观中立）。 - 关键服务故障与吸取教训。
经历了一些严重的全球性服务中断事件（例如 2016 年的 YouTube 全球宕机事件）。 - 工作流程优化：
强调渐进式发布（Progressive Rollout）、金丝雀部署（Canary Deployments）和快速回滚机制，将故障处理从反应式转向预防式。 - 2014 年：SREcon 大会的启动
。Google 开始在 USENIX 等行业会议上公开分享 SRE 实践，知识开始向外溢出。 - 角色定义：
SRE 的角色不仅是“运营者”，更是可靠性咨询师和布道者，帮助整个公司和外部行业提高可靠性水平。 | - 2016 年：SRE 官方书籍出版
。《Site Reliability Engineering: How Google Runs Production Systems》出版，将内部实践正式化为方法论。 - 工作内容细化：
SRE 职责正式定义为：可用性、延迟、性能、效率、变更管理、监控、紧急响应和容量规划。
3. 近期演进 (2017-至今)：系统复杂性与深度安全集成
- 关键服务连锁故障（如 2017 年 OAuth 令牌故障）。
发现即使是核心组件的细微故障也可能导致大规模级联失败和漫长恢复时间。这暴露了跨系统依赖的复杂性。 - 职责深化：
强调跨服务依赖关系的清晰建模，以及建立非谷歌依赖的备份通信渠道，以应对核心服务（如 Google Meet）自身宕机的情况。 - DevSecOps 与安全集成。
随着行业对安全和合规性的要求提高，零信任安全模型和安全实践融入 SRE 工作流。 - 职责扩展：
SRE 的工作内容扩展到 DevSecOps 领域，主动管理安全风险和合规性问题，确保可靠性、性能和安全性并重。 - 系统安全模型 STAMP 的引入。
引入更先进的理论模型（如 STAMP，基于控制理论的系统安全框架），将故障视为系统级的复杂交互，而非简单的线性因果链。 - 思维方式转变。
SRE 从被动应对事件转向主动管理风险，更注重系统建模，提前识别并预防最坏情况下的系统状态。 - 组织结构多样化。Google Cloud Platform (GCP)
的快速发展，除了传统的产品 SRE 和 平台 SRE 之外，咨询 SRE 或嵌入式 SRE 模式被更广泛采用，以帮助新的产品和 GCP 客户快速采用 SRE 实践。
5 SRE 的核心原则与支柱
SRE 体系建立在几个关键工程化原则之上，这些原则指导团队日常工作和决策制定：
- 自动化至上（Automation）：
致力于将重复的手动操作（Toil）自动化，确保 SRE 至少有 50% 的时间投入到工程项目（即自动化和改进工作）中。 - 通过 SLO 和 Error Budget 管理可靠性：
- SLO (Service Level Objectives)：
定义可接受的服务性能目标（例如，延迟 99% 的请求需在 100ms 内完成）。 - Error Budget (错误预算)：
允许服务在不违反 SLA 的前提下，可以容忍的不可用时间。这成为 SRE 和开发团队之间衡量风险、决定是否可以发布新功能的共同语言。
6 Google 内部不同类型的 SRE 团队划分
为在庞大组织中有效管理不同类型的服务，Google SRE 组织内部形成了多种专业化团队：
- 产品 SRE (Product SRE)
专注于确保面向终端用户的特定产品或应用（如 Gmail, Search）的可靠性、延迟和可用性。服务于外部用户 (External Customers)。 - 平台/基础设施 SRE (Platform/Infrastructure SRE)
。专注于构建、维护和扩展跨产品共享的底层核心基础设施和工具（如分布式存储、网络、容器编排系统）。服务于内部工程师 (Internal Engineers)。 - 嵌入式 SRE (Embedded SRE)
。SRE 专家会暂时性加入开发团队，帮助他们建立和迁移到 SRE 最佳实践（例如设计监控、制定 SLO），完成后返回 SRE 组织。服务于产品开发团队 (Product Dev Teams)。
这种划分确保 SRE 专业知识能够精准应用于最关键的两个领域：保障终端用户体验（产品 SRE）和维护整个生态系统的稳定基石（平台 SRE）。
7 总结 SRE 演变的核心驱动力
SRE 组织和职责的演变可总结为从能用到高效可靠，再到应对复杂且不可预测风险的过程：
- 从人工到自动化：
这是最初转变，用软件工程师取代运维人员，将手动操作（Toil）控制在 50% 以下。 - 从经验到指标：
通过引入 SLO 和错误预算，将模糊的“可靠性”概念转化为可量化的工程指标，从而实现开发团队和 SRE 团队之间的协作平衡。 - 从局部到系统级：
随着系统规模达到万亿级，职责不再局限于单个服务，而是深入到全局架构设计、跨服务依赖分析和容量规划，确保整个生态系统韧性。
8 结语
谷歌 SRE 的二十年发展历程，不仅是一部技术演进史，更是一部组织变革史。从最初应对规模危机的应急措施，到如今成为行业标准的方法论，SRE 展现了软件工程思维在解决复杂运维问题中的强大威力。
对于正在经历数字化转型的企业而言，谷歌 SRE 的经验提供了宝贵的参考：可靠性不是成本中心，而是业务增长的加速器。通过将运维视为软件工程问题，建立量化指标体系，培养持续学习的文化，企业可以在保证系统稳定的同时，快速响应业务需求。
未来，随着云原生技术、人工智能和边缘计算的普及，SRE 的理念和实践还将继续演进。但其核心精髓——用工程化方法解决系统性问题——将始终指导我们构建更加可靠、高效的数字基础设施。