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

• SRE（站点可靠性工程）有助于减少开发团队与运营团队在版本发布过程中面临的常见问题。

• SRE 通过保障应用在每次更新中保持稳定，提升系统可靠性、责任落实度与创新能力。

• 衡量、响应、学习、优化是支撑 SRE 落地的四大核心要素。

• 有效的 SRE 始于管理层层面，同时也依赖完善的团队架构，以及全员共同承担可靠性责任。

• JSM 可帮助您简化事件响应流程，有效落地 SRE 实践。

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

SRE 在现代软件开发中发挥着关键作用，既能缩短产品上线周期，又可减少流程阻碍与系统可靠性问题。进一步了解 SRE 核心原则、支柱，以及 SRE 如何影响您的组织。

什么是站点可靠性工程 (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) 支持团队便捷管理问题、上报问题，并在集中化平台分享最佳实践与处置程序。

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

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

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

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

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

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

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

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

优化是成熟 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 指南，了解如何组建 SRE 团队；也可使用 JSM 优化事件管理，提升跨团队协作能力。