稳定性的灯塔：腾讯 SRE 质量运营体系建设实践

发表于： 2023年10月29日 2023年10月29日
标签：思维认知, 故障治理

本文将从整体角度出发，探讨腾讯 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的配置成本，并基于运营经验提供一些推荐的告警配置模板。最后，基于错误预算进入研发投入的决策，是未来希望能进一步做到的能力。

3.2 On-Call 事件管理

3.2.1 事件接入解决的问题

SLO 管理建设之后，就是关于 On-Call 的事件管理。事件管理解决了告警的泛滥问题。很多人提到告警治理并将其作为一项提效工作，告警治理最容易想到的就是实现告警绝对数量的下降。但实际上告警绝对数量很难降到特别低的范围，因为对于研发来说，告警既是因也是果。

比如，很多告警不仅用于故障发现，还用于故障定位，很多研发人员平时不看这些告警，但当他们真的需要定位时，会需要这些告警信息，想要扭转这种行为是很难的，因为有其合理性。因此，个人认为减少告警的绝对数量实际上是一个伪命题，最终无法达到想要的效果。

On-Call 就是从另一个方面解决这个问题，它在可观测领域之上建立一个事件通道，将需要人为介入的事件引入 On-Call 系统里进行标准化的处理动作。

3.2.2 标准化定义渠道

有了这个背景，同时SLO建立了最重要的故障发现渠道，我们就需要对所有事件渠道进行标准化的定义。其中最重要是定义出哪些是自动发现，哪些是用户反馈。

通过覆盖所有用户反馈的事件渠道，获取线上事件的全集，利用数据驱动的方式来持续观测与提高故障自动发现的能力。

3.2.3 告警事件的接入能力

此外，我们还可以在此基础上实现更丰富的告警接入能力，例如匹配、过滤、收敛、升级和恢复等，这些都是对告警的理解和应用。

举个简单的例子，在收敛方面。比如说一个微服务，它会有很多维度的告警，比如成功率、耗时、CPU、MEM、IO等。

虽然告警很多，但我们可以将它们一起接入到 On-Call 中，并配置一个以服务 ID 为去重Key，这样所有的告警就会被追加进一个Oncall 工单，在上层解决了告警泛滥的问题。

3.2.4 告警接入与响应

事件接入的配置理解成本比较高，在推广期有很多配置管理的问题，想要实现 On-Call 既不漏报也不误报，是需要持续运营和功能完善的，但这种方式已经帮助我们解决了很多问题。

此外，这个能力还可以进一步扩展。当运行一段时间后，On-Call 中产生的故障数据以及上下游业务的依赖关系数据，其置信度足够高，足够关键。那就可以利用这些高权重的数据样本，结合服务粒度的调用链，通过算法实现故障根因定位。

3.2.5 On-Call 在研发流程中的定位

如果想在内部实践需要考虑 On-Call 的定位到底是什么。刚才提到用户反馈是一个非常重要的渠道，可以帮助我们校准质量数据的覆盖，补齐完整的数据模型。但是，一旦接入用户反馈，就会与用户相关的运营平台产生产品定位上的冲突，这也是需要考虑的问题，也就是说我们的研发流程和运营流程到底是什么，怎么定义和串联这些能力？

比如腾讯内部的上万名不同领域的研发，有 ToB 和 ToC 的产品，有各自的用户运营方式。而如果我们要建立 On-Call 平台，又覆盖用户反馈，是否在重复造轮子？

因此，我们要明确研发流程与用户运营的关系，从右侧的图可以看出，On-Call是面向技术团队、研发与 SRE 的。而用户运营由专业的 toB 或 toC 平台承载，但流程上如果涉及到技术团队，就可以将事件下发到 On-Call 进行故障运营的流程。而处理过程中，一旦研发认为该事件可能需要代码修复、或是转为用户需求，则进一步流转到专业的研发流程管理工具，比如腾讯的TAPD。

从而实现用户反馈这条路径上的全流程系统级打通与闭环。

3.2.6 运行案例

经过刚才的案例建设，我们就可以实现质量数据的量化与落地，可以持续的观测和提升故障自动发现的比例，同时数据置信度有保障。

当你向老板汇报产品质量情况时，你会拿出各种工作成果和数据，但老板会质疑数据是否可靠、机制是否有保障，而在此以前你很难回答这种问题。

但现在，我们可以通过全流程的数据，来量化与证明稳定性工作。同时技术团队可以一站式地管理各类事件，标准化了处理流程。即满足了管理需求，又满足的用户需求。

3.3 On-Call 响应管理

3.3.1 On-Call 保证标准化执行

事件接入之后，怎么去进行闭环的管理。我简要介绍几个 On-Call 的功能模块，包括业务管理、值班、升级和工单，通过这四个功能来覆盖整个 MTTR 全生命周期。

从事件发生和发现开始，到响应和事中处理，再到是否进行复盘，整个 MTTR 的生命周期都在 On-Call 上完成，因此也可以输出重要的 MTTR 数据。

3.3.2 On-Call 业务管理

关于 On-Call 的四个模块都有一些小细节需要注意。比如说，在业务管理模块中，Service 其实就是面向用户的业务场景，每个研发团队都要明确自己的职责，建立自己的场景，而所有On-Call的功能都是围绕着 Service 进行绑定、配置和定义的。

3.3.3 值班管理

值班管理好处之一是可以提高整个研发团队的效率。例如，在 On-Call 值班模式下，减少了研发人员被频繁打扰这种情况的发生频率，同时故障处理的时效和效率得到了保证。

此外，On-Call 模式在北美的大中小公司中几乎都是默认模式，但国内可能有很多公司声称采用了此模式，但实际上并没有通过标准化工具来整体化承载。

3.3.4 升级策略

此外，通过升级策略的配置，即使在夜间也可以保证通知和处理问题，多层级的管理也可以引入一线、二线、Leader等不同角色，使 On-Call 流转或升级。

3.3.5 工单管理

最后提到的是工单，图中有一个实际的案例，工单将大部分 On-Call 能力串联在一起，包括之前提到的自动化动作、研发流程、企微协作、故障信息、相关事件等等。这些都在一个 On-Call 工单中得到串联和体现。

3.4 数据质量模型3.4.1 数据模型分阶段

如果我们建立了这样一套标准化能力，到底能实现什么样的管理效果？首先，这个系统能够产生多个层面的数据。

第一层是 SLO 数据：用于观测和管理产品稳定性，并且用于故障的自动发现；
第二层是运营数据：用于全流程观测On-Call的运营情况与效率；这部分还包括研发在On-Call中投入的人力，用以评估稳定性的压力，选择合适的产品迭代时机来解决稳定性的问题；
第三层是渠道数据：用于观测事件渠道覆盖，持续提升故障自动发现比例。就比如上文提到的，我们有几十个产品，那么我们就通过标准渠道的覆盖情况，来看产品稳定性的数据是否置信。而后，就可以持续观测与提升故障自动发现的准召率；
第四层是质量数据：用于全面分析产品稳定性，帮助我们统计分析过往的故障原因，指导未来的稳定性工作规划，包括MTTx、故障/事故数、严重程度、根因统计等等。

3.4.2 数据决策与管理稳定性

这些数据为下一阶段的数据决策和工作管理打下了基础。基于这些数据，我们可以制定稳定性相关的 OKR。这里举个示例供参考，例如 Objective 1 是根据 MTTR 的数据来制定今年的整体策略。比如整体目标是降低 MTTR，我们可以制定一个目标，例如下降 30%。之后我们可以基于上述数据来拆分这个目标并制定具体的KR。

比如，KR1是MTTI下降多少时间，应该采取什么措施来建设？KR2是 MTTA 响应时间下降多少时间，应该如何建设？KR3 是定位时间，例如可观测能力还不够，可以投入更多资源来提高定位时间。还有 MTBF 的提升，如果我们在根因统计中发现80%的故障是容量类问题，那 SRE 团队应该重点投入解决容量管理的问题。

因此，这提供了一个科学的决策框架，可以帮助我们将运维工作从被动转为主动，科学的阐述SRE的价值与贡献，并帮助全公司产品提升稳定性。

04 总结展望