稳定性的灯塔：腾讯 SRE 质量运营体系建设（上）

admin 10 月 16, 2023 118 0

本文将从整体角度出发，探讨腾讯 SRE 质量运营体系是如何构建和实践的，以及建设过程中经验和思考，并进行总结和展望。

01 行业背景

稳定性建设是一件很让大家头疼事情，就像我刚开始入职做 SRE 时一样，面对稳定性建设总是觉得无从下手。Google 的 SRE 提供了一些指导方向，Google SRE 这本书的核心是引导大家如何科学地进行稳定性建设。在此基础上，我们决定在腾讯大规模采用基于 SLO 与 On-Call 的质量运营体系，期望能够正确的量化稳定性建设。

02 基于 SLO 与 On-Call 的质量运营体系

2.1 问题背景

产品稳定性无法量化

在腾讯这样的大规模场景下，如果产品的稳定性无法量化，就是一件很痛苦的事情。我如何管理团队的组织目标？如何制定 OKR？如何判断人力的投入方向？很难向老板解释清楚我们团队的价值和贡献是什么。所以，稳定性建设首要解决的问题就是数据和量化。

故障过程不透明、不可控

特别是在组织规模变大后，每个团队可能都有自己的小流程。因此，通过基于 SLO 与 On-Call 的质量运营体系机制，我们可以将这些行动和不标准的行为收敛起来。提升故障处理效率的同时，实现标准化并产生数据。

传统的方法不具备先进性

如果仍然依赖于传统的运维方式，没有一个体系化的解决方案，或者是 DevOps 的理念引领，这可能会导致成员个体在稳定性中投入的积极性不高，因此需要引入 SLO 和 On-Call 管理将其具象，让每个人都明确的感知到稳定性的提升。

2.2 SLO 管理

SLO 是描述当前系统稳定性的指标。像腾讯内部每天成百上千次的发布，功能迭代速度上来了，引入了更多的代码，那产品稳定性就会相应下降。SLO 是以合理的方式评估迭代功能和产品稳定性之间的关系。同时SRE团队可以与研发团队通过SLO，共同明确合理的质量目标。避免运维和研发互相推卸责任，将所有人拉到同一条战线上。而具体方法则是要树立面向用户而不是面向系统。

在运营过程中，经常会遇到各种故障和问题，但如果大家都站在用户的角度上，就可以有共同的语言合作解决问题。

另外，还有具体的应用，包括基于错误预算的燃烧率告警、基于错误预算的研发策略决策。

2.3 On-Call 管理

On-Call 管理容易被人们忽视，实际上它涵盖了包括系统事件、云组件事件、大数据事件和用户反馈等各种事件。这些事件可以通过一个 On-Call 集中化管理平台进行标准化的处理，这样做可以带来五个方面的收益：

Visible：可实时观测整个系统的故障情况。
Orchestration：间接实现告警的治理和编排。
Automation：On-Call 作为一个中枢环节，可以串联许多自动化工具能力
Teamwork：团队合作可能随着企业规模的扩大而增加，研发、SRE、运营角色之间的协作可以通过Oncall来串联。
Analytics：最重要的就是落地稳定性数据。通过人工处理所有线上事件，可以获得有意义的高质量的运营数据，是分析产品稳定性的关键。

2.4 产品架构

问题明确后就是通过产品实现落地，我们内部开发了一套 On-Call 平台，用于集中管理和处理故障和事件。On-Call 平台有一个门户，上百个研发团队集中响应他们真正关心的事件。

左侧的事件渠道包括SLO、可观测性、风险探测（巡检）和用户反馈。这些渠道都很重要，可以独立实现产品建设，检测到的事件可以接入On-Call中进行处理。因此，On-Call需要有一些细致的管理模块来支持这个过程，在后面的实践中会讲到。

接下来就是集成第三方平台，比如内部研发流程（TAPD）、企业微信、腾讯会议和其他各种内部第三方平台也是通过 On-Call 来串联的。我开始觉得 On-Call 只是一个记录故障的工具，但真正做起来后，发现它解决了很大的研发流程问题。

2.5 实际落地情况

下面简单来说一下实际应用情况。在腾讯内部，目前覆盖了几十个产品，包括视频、QQ、文档、新闻、中台等上百个团队，因此我认为这个经验对其他公司也有借鉴意义的。

03 在腾讯的大规模落地实践

3.1 SLO 管理

3.1.1 核心场景与 SLI 指标

什么是 SLO 管理？Google 中的定义是面向用户。那么谁是用户？在复杂的组织结构情况下，谁能使用 On-Call 服务？这个问题涉及到层次结构的问题。实际上我们内部将SLO场景也进行了分层定义，例如面向外部用户的定义为一级场景，面向内部用户定义为二级场景。这样每个团队定义自己的职责边界，因此我们允许所有团队接入并使用。

这样做意义在于，我们即可以抓住主要矛盾，一级的SLO场景面向管理者进行数据的展示与汇报，出现大型故障时可以快速了解所有产品线的情况。同时，二级场景又满足了所有研发团队的使用需求。

3.1.2 SLO目标与错误预算

第二步是制定 SLO的目标和错误预算。在这方面，我们主要参考 Google 的计算方式。由于研发对这项工作的理解不如 SRE 团队深入，我们会计算过去28天SLO的错误消耗情况，并自动给出推荐的SLO目标值。比如研发本身的服务的可用性是99.99%，但目标却设定为99%，达不到管理和使用的目的。因此，我们会自动进行推荐，对偏离较多的指标进行人为介入与修正。

另外一点是需要SRE团队与研发团队共同制定。由SRE团队主导、研发团队配合，共同完成目标的制定与落地。

3.1.3 基于错误预算燃烧率的告警

SLO 定义好之后必须要用起来，否则过一段时间数据的有效性会出问题。而第一个应用场景就是基于错误预算的燃烧率告警。我们直接采用了 Google SRE 中介绍的长短窗口计算形式，并在线上大规模应用。告警的时效性相比传统的告警方式，时效性可以满足要求，图中也给出一个基于长短窗告警的例子。

3.1.4 建立 SLO 运营机制

随着具体应用的出现，大规模落地需要 SRE 组织起的标准化的运营机制，我们内部会组织 SLO 运营周会，并由业务 SRE 与业务产品线、技术公线、平台和中台等产品线进行对接。确保我们的理念、机制、产品，持续迭代并输出给所有产品线。这是确保我们在短时间内快速落地几十个业务线，并打磨好产品功能的关键运营机制。

3.1.5 未来规划

未来在 SLO 建设方面，需要更加聚焦于核心场景与核心指标。目前，我们已经有 1000 多个业务场景和 3000 多个SLO指标。此外像错误预算和告警配置的理解成本比较高，有一定使用门槛，因此，我们需要降低SLO的配置成本，并基于运营经验提供一些推荐的告警配置模板。最后，基于错误预算进入研发投入的决策，是未来希望能进一步做到的能力。

下一篇文章将介绍：腾讯 SRE 在On-Call 事件管理方面的实践敬请期待

作者简介

王晓川（腾讯 PCG SRE 研发负责人/SRE技术专家）

目前就职于腾讯，硕士毕业于北京大学，曾任职工行、美团，深耕SRE领域十年，目前负责质量运营、可观测、混沌工程等平台的研发工作。

本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。

为推动各行业系统稳定性体系建设，中国信通院依托分布式系统稳定性实验室，联合多家头部企业于2021年制定了《分布式系统稳定性保障能力分级要求》标准，今年标准工作组对框架及内容进行了全面升级，正式更新为《研发运营一体化（DevOps）能力成熟度模型第14部分：系统可靠性与连续性工程》标准，并依据此标准全新推出了SRE研发运营系统可靠性与连续性评估。

该评估由中国信通院工程师在参评机构现场完成，主要分为研发过程的可靠性与连续性保障能力与技术运营过程的可靠性与连续性保障能力两大部分。覆盖了参评单位在系统研发运营生命周期中为保持系统平稳运行而采取的一系列工作，对参评机构的系统可靠性与连续性保障体系进行全方位的梳理。

未来中国信通院DGA分布式系统稳定性实验室将持续开展系统稳定性评测项目，为各行业研发运营系统可靠性与连续性保障提供指导和帮助，助力我国数字化转型实现“又快又稳”。

DGA分布式系统稳定性实验室及评估咨询联系方式

尚梦宸 13261081232

shangmengchen@caict.ac.cn

学会这些软技能，可以有效提升运维人的工作幸福感？

达到 BizDevOps 的业技融合，还需要多久？

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。

点个“在看”，一年不宕机

稳定性的灯塔：腾讯 SRE 质量运营体系建设（上）