什么是 SRE？原则与实践详解

核心要点：站点可靠性工程 (SRE) 是一门工程学科，它将软件工程实践应用于运维工作，以构建并运行可靠、可扩展的系统。

• 定义：该实践依托四大支柱：衡量指标（SLI、SLO、SLA、错误预算）、响应（事件管理和可持续待命）、经验总结（无指责事后分析）以及优化（自动化和减少琐碎工作）。

• 重要意义：SRE 通过将可靠性转变为可衡量、共享的目标，而不是地盘争夺战，解决开发速度与运维稳定性之间长期存在的矛盾。

• Jira Service Management 的作用：集中管理警报、待命值班表、事件响应和事后分析，从而使 SRE 和产品团队能够基于同一份事件记录和同一套可靠性指标开展工作。

软件的开发与发布涉及许多动态环节，跨团队协调上线工作往往极具挑战。站点可靠性工程 (SRE) 这类创新实践能够减少协作阻力，助力团队精简 ITSM 流程。

站点可靠性工程 (SRE) 是一门工程学科，它将软件工程实践应用于运维工作，以便构建并维护可靠、可扩展的系统。在 Google 创立该实践的 Ben Treynor 将其描述为“当一名软件工程师被指派负责过去被称作运维工作时所发生的情况”。

过去，开发团队因快速交付而受到奖励，运维团队则因保持稳定而受到奖励，这两个目标往往背道而驰。SRE 通过设定明确的可靠性目标并据此进行衡量来解决这一问题。本指南介绍 SRE 与传统 IT 运维和 DevOps 的区别、其四大支柱、有效运作方法，以及适用场景。

什么是站点可靠性工程 (SRE)？

SRE 是一门工程学科，它将软件工程实践应用于运维工作，以此构建并维护可靠、可扩展的系统。其核心是通过自动化、可量化的可靠性目标以及持续的运维优化，提升系统性能。

Google SRE 早期负责人之一 Ben Treynor 曾这样定义站点可靠性工程：“让软件工程师承担以往运维人员的工作所形成的实践模式。”

以往，开发团队侧重于快速交付新功能，而运维团队优先保障系统稳定性。二者的理念冲突，往往会在版本发布决策和风险容忍度上产生矛盾。

SRE 提供了一套更规范的落地方法：通过定义可靠性目标、设置可量化阈值来指导何时可安全发布变更。专职可靠性工程师在保障系统达到性能预期的同时，助力业务持续创新。

正如 Google SRE Andrew Widdowson 所言，这份工作就好比“高强度的赛车维修团队”—系统在生产运行的同时，团队不断对其进行优化。

SRE、传统 IT 运维与 DevOps 对比

在传统 IT 运维模式中，核心重点是尽可能减少新版本发布带来的问题与风险。团队按 IT 专业领域进行划分，例如由网络工程师负责网络运维等。该模式虽能最大限度保障系统可靠性，却容易产生流程瓶颈与交付延误。

DevOps 是为应对传统 IT 运维团队面临的挑战而诞生的现代化解决方案。与传统 IT 运维不同，DevOps 侧重于依托自动化实现敏捷高效的交付。DevOps 团队同时采用跨职能团队架构，具备更高灵活性。

SRE 是衔接开发与运营团队的最新创新模式。它通过可观测性、自动化与应用监控，精简开发团队与运营团队的协作流程。SRE 团队依据服务级别协议 (SLA)、服务级别指标 (SLI)、服务级别目标 (SLO) 衡量应用性能，保障系统可靠性。SRE 团队成员可直接排查并修复代码问题，因此编码能力是 SRE 团队的核心技能。

SRE 如何运作？

SRE 拥有多项核心支柱，可简化 DevOps 流程并保障软件可靠性。深入了解 SRE 的关键要点，有助于组织有效落地 SRE 实践。

衡量：定义和跟踪可靠性

衡量是 SRE 决策的基础，为 SRE 团队提供关键数据，助力在每次版本上线时最大化系统可靠性。关键指标包括：

• 服务级别指标 (SLI)：延迟、可用性、吞吐量、错误率等 SLI 指标，是衡量系统可靠性的核心指标。

• 服务级别目标 (SLO)：SLO 允许团队基于用户体验设定切合实际的可靠性目标，这也有助于平衡性能目标与运维约束，以保障软件发布后的稳定运行。

• 服务级别协议 (SLA)：SLA 是面向外部的可靠性承诺，标准通常低于 SLO。SLO 比 SLA 要求更严格，可作为潜在性能问题的预警机制，确保对客户负责并提供优质的客户体验。

• 错误预算：错误预算指一段周期内允许的系统停机时间。团队通过错误预算把控开发节奏。当错误预算耗尽时，放缓开发进度；当错误预算充足时，可加快开发速度并承担更多风险。

响应：管理事件与运维负载

响应是 SRE 团队实时处理可靠性问题的规范化方式。团队通过既定流程与标准化框架简化事件管理：

• 事件响应实践：团队制定明确流程、岗位职责及上报路径，以保障及时、统一的事件响应。Jira Service Management (JSM) 支持团队便捷管理问题、上报问题，并在集中化平台分享最佳实践与处置程序。

• 严重性级别与优先级排序：团队采用标准化严重性框架，快速评估特定问题的影响范围与紧急程度。这有助于团队根据严重性确定事件的处理优先级。

• 待命工程：可持续的待命轮换机制可在系统响应速度、开发人员工作效率与身心健康之间取得平衡，减少人员倦怠，实现更优运维成效。

复盘学习：从事件中实现系统性优化

事件响应完成后，复盘学习是帮助团队预防故障复发、提升系统韧性的机制。

• 无指责事后分析：团队聚焦问题的系统性根源，而非个人失误，以此实现更有效的问题解决，同时保障团队的心理安全感。

• 事后分析模板与实践：采用结构化的事件复盘方式，完善文档，并推动可落地的后续改进措施。Jira Service Management 中的事后分析模板可简化此流程。

• 可靠性知识共享：通过集中化的页面与文档，团队可搭建知识库，将经验推广至各项服务与整个组织。

优化：规模化实现工程可靠性

优化是成熟 SRE 实践带来的长期成果。此类改进可随业务同步扩展，保障系统长期稳定可靠。

• 减少繁重工作：识别并消除重复性运维工作流，可释放团队时间，使其聚焦于更高价值的工程工作，避免浪费宝贵资源。

• 自动化与标准化：通过简化运维工作流、降低人为失误风险，自动化可提升系统一致性、韧性与运维效率。

• 产能规划与性能优化：采用预防性方法进行系统设计，可规避常见问题，支撑业务可持续增长，从而确保系统随业务规模轻松扩展。

如何有效落地 SRE

SRE 在得到合理运用时便可成为一种有效的工具。遵循规范流程与最佳实践，能够更有效地落地 SRE。

让可靠性成为全员共同责任

让可靠性成为全员共同责任是 SRE 的核心原则之一。当开发团队与运营团队共同对版本发布结果负责时，团队更能高效协作，从而找到当前问题的解决方案。

错误预算等工具在统一工作优先级、促进团队协作方面起到关键作用。SLO、SLI 和 SLA 是客观衡量系统性能的简便方式，为团队协作奠定坚实基础。

选择合适的团队架构

SRE 团队可采用集中式或嵌入式架构，两种模式各有优势。

嵌入式 SRE 团队隶属于产品团队内部，能更深入理解产品，实现快速响应。集中式 SRE 团队为独立团队，服务于整个组织。

混合式团队是集中式与嵌入式 SRE 团队的有效折中方案，兼具嵌入式 SRE 团队的敏捷性与集中式团队的规范性。混合式工程角色可加快开发速度、减少可靠性问题，从而打造更稳定可靠的系统。

争取管理层对可靠性工作的支持

将可靠性作为长期优先事项并纳入战略决策流程，绝非仅组建一支 SRE 团队就能实现。高效、可持续的 SRE 建设始于管理层的支持。

当管理层致力于提升系统可靠性时，SRE 团队便能获得所需资源以保障系统稳定。管理层的认可还能推动企业文化转变，让组织优先重视可靠性而非一味追求快速发布，从而将 SRE 理念融入组织各项工作。

何时应该采用 SRE？

如果您正考虑采用 SRE，以下迹象表明组织已具备转型条件：

• 大量资源耗费在手动、重复性任务上，导致员工职业倦怠

• 客户频繁因性能问题或系统停机产生不满，或企业频繁违反 SLA

• 部署周期漫长，且常引发问题

尽管实施 SRE 是提升系统可靠性的有效方式，但仍需应对一些挑战：

• 企业文化对变革存在抵触

• 人才招聘或培训存在困难

• 运维琐事过多难以管控

可通过分阶段实施 SRE 应对上述部分挑战。从非核心试点项目起步，逐步实施自动化、错误预算机制，并在团队逐步适应后持续改进。

着手搭建 SRE 实践体系

SRE 是提升系统可靠性、优化开发团队与运营团队协作效率最有效的方式之一。通过 SLO、SLI 和 SLA 衡量系统性能，有助于减少事件发生、改善客户体验，让开发人员专注于创新工作。

如果您准备采用 SRE，可从小型项目起步，搭建团队，并专注于持续完善、优化 SRE 实践。

探索我们关于组建 SRE 团队的深度指南，或了解 Jira Service Management 如何简化事件管理和跨团队协作。