腾讯运维转型之 SRE 体系建设

来源：腾讯技术工程 刘天斯
https://mp.weixin.qq.com/s/YHR50kF2QOgjMi83WbwuzA

1、什么是SRE

利用 SRE 的思想与方法，不断去冲刺稳定性的终极目标：“提升 MTBF（平均故障时间间隔）、降低 MTTR（故障平均修复时间）”，很多小伙伴会有疑问，DevOps 与 SRE 到底是什么样的关系？

SRE 是 DevOps 的一种实现方式

团队构建的玄图-SRE 稳定性建设全景图

在这个体系中，云原生环境下的 IAAS 或 PAAS，我们关注的是 MTTF (Mean Time To Failure，平均无故障时间)，这个能力由基础设施团队来保障。

MTBF（Mean Time Between Failure） 列意为平均故障时间间隔，可以理解成稳定性保障的事前与事后，在这个环节中，我们在原有基础上扩展出两个核心能力

• 其中一个是“混沌实验”，旨在通过主动注入服务故障，提前发现并解决系统存在的隐患，提升系统的韧性
• 另一个为“全链路压测”，模拟真实的并发数及用户访问，通过自动拓扑图快速找到影响性能模块，定位问题根源。

MTTR（Mean Time to Repair）列意为故障平均修复时间，这里我们拆解了 5 个步骤，分别做下解释：

• MTTI （Mean Time To ldentify）平均故障发现时间，强调团队的监控告警能力的完备性；
• MTTA（Mean Time To Acknowledge）平均故障确认时间，强调团队的 OnCall 机制执行，以及制度与技术的配套；
• MTTL （Mean Time To Location）平均故障定位时间，要求团队对故障的分析与解决问题经验的积累，以及平台工具的配套；
• MTTT （Mean Time To Troubleshooting）平均故障解决时间，对服务高可用架构的设计、容错、扩展能力提出要求；
• MTTV （Mean Time To Verify）平均故障验证时间，围绕服务体验为核心的监测体系，建立与业务、用户的反馈机制。

这个环节作为稳定性保障的“事中”尤为重要，其中可观测性作为下一代的质量监控的代表，通过强化分布式服务的日志、链路、指标的关联，缩短发现问题、解决问题的时间，可以极大缩短 MTTR 中 MTTL 的耗时。

2、定制SRE准则

SRE 8 准则
有了这 8 个准则，就很清楚我们需要具备什么样的能力与工作方法，来达成什么样的工作目标，同时也延伸出下面介绍的 SRE 工具链。首先简单介绍我们的 SRE 8 准则，下面简要进行剖析：

• 架构设计准则 - 我们认为所有的架构都是不完美的，都存在缺陷，因此我们在做业务架构设计时都必须要考虑服务稳定性保障，如负载均衡、多点容灾、集群化服务、数据多活等能力；
• SRE 前置准则 - 在业务立项之初，SRE 角色需要提前介入，将运营阶段可能出现的问题或风险提前在架构设计、编码阶段暴露，提前准备好解决方案，甚至规避问题与风险；
• 混沌实验准则 - 故障不可避免，为何不让其在测试或预发布环境提前到来，通过模拟现网真实故障来验证服务的“韧性”，找出系统的弱点，同时验证我们的监控告警的有效性，在 MTBF 阶段实施最好不过，也是我们其中一把利器；
• 可观测性准则 - 通过采集业务指标、日志、追踪等数据，快速分析与定位问题，同时发现复杂系统的瓶颈点，在很长一段时间内，业务指标、日志、追踪的采集与应用，都是独立存在并分开建设，随着时间的推移，发现这三者是相互关联，相辅相成的，是我们的第二把利器；
• 全链路压测准则 - 通过与可观测性、混沌实验能力的深度整合，实现模拟真实业务环境全链路压测，达到业务上线前的精准资源评估，主动发现潜在性能、版本缺陷等问题，是我们的第三把利器；
• DevOps 交付准则 - 通过打造高效的价值交付链，覆盖 CI、CD、CO 服务全生命周期运营管理，CI 我们采用 ODP 封装蓝盾方案，CD 与 CO 采用蓝鲸运维编排及监控告警等能力，SRE 会将大分部精力聚焦在 CO 环节；
• 故障应急准则 - 故障不可避免，我们能做的是不断去提升 MTBF，降低 MTTR，包括事前的实施大量混沌实验、故障预案；事中采用打造的工具链，快速发现、分析、定位与解决问题；事后组织总结复盘，沉淀案例经验；
• SRE 学习准则 - 营造学习的文化，目的是实现多个不同职能团队的有机融合，相互了解大家面临的问题或挑战，形成一致的目标，达到有效的协同，解决业务的问题。团队于 2016 年发起的《微分享》机制，截止目前累计 250 次分享 。

三、跟踪 SLO 状态

量化目标是一切工作的起点，所有运维工作都以围绕 SLO（服务水平目标）指标的定制、执行、跟踪、反馈来展开。其中定制与执行因各业务形态的差异，此处不进行展开，指导的原则是选择合适的 SLI（Service Level Indicator，服务等级指标），设定对应的 SLO。梳理与采用业务侧关注的 SLI 指标，目标值达成一致即可。我们具体的 SLI 采集实践见第一篇文章的云原生应用监控 章节，其中关于识别 SLI Google 提出 VALET 法，分别是 Volume、Availability、Latency、Error 和 Ticket 的首字母，这 5 个单词就是我们选择 SLI 指标的 5 个维度。

• Volume（容量）服务承诺的最大容量是多少，比如常见的 QPS、TPS、会话数、吞吐量以及活动连接数等等；
• Availablity（可用性）代表服务是否正常或稳定，比如请求调用 HTTP 200 状态的成功率、任务执行成功率等；
• Latency（时延）服务响应是否足够快，比如时延是否符合正态分布，需指定不同的区间，比如常见的 P90、P95、P99 等；
• Error（错误率）服务有多少错误率，比如 5XX、4XX，以及自定义的状态码；
• Ticket（人工干预）是否需要人工干预，比如一些复杂故障场景，需人工介入来恢复服务。

定义业务相对应 SLI 的 SLO 后，跟踪 SLO 有利于稳定性目标的达成，时刻提醒还有多少错误预算可以供消费，是否应该调整版本发布的策略或节奏，更加聚焦人力在质量方面的优化。我们采用 SLO Tracker 来对接故障报单平台，获取故障单据、影响时长等信息，定期统计并做团队反馈。

四、工具链建设

SRE 的准则与方法论固然重要，但没有强有力的工具链来作为支撑，在执行面将面临步步维艰，因此我们在 2 年前就开始着手规划 SRE 工具链的建设，根据 SRE8 准则的平台能力要求，明确了三个发展的能力项，分别为

• 可观测性、混沌实验、全链路压测等。
  

如图所示，是我们构建 SRE 工具链的底层逻辑，首先我们打造整个体系的根基，分别定制 SRE 的标准规范、方法与目标。平台化只是将这套理论体系的实例化，在平台层面我们是以可观测性为底座，收集并共享业务的链路拓扑数据，供上层的混沌实验与全链路压测等平台进行集成，来实现更加高级的能力。通过多种能力的整合，目前已经初步具备了强弱依赖分析、资源精准评估、异常快速定位、发现服务瓶颈、业务拓扑理解、增强服务韧性等一系列核心能力。下面将逐一进行相关能力的介绍。

五、可观测性平台

1、可观测概括
在云原生时代下，应用的可观测性基础设施至关重要。在 IEG 营销服务场景下，微服务间调用关系更是错综复杂，给服务性能瓶颈分析、快速定位影响评估范围和根因分析等方面带来了诸多的挑战。云原生一线开发/运维人员时常面临以下问题：

• 服务调用关系错综复杂，如何快速定位问题根因？
• 某服务发生异常，如何快速评估影响范围？
• 如何快速分析复杂系统的服务瓶颈点？
• 服务追踪、指标和日志分开上报，问题定位难度大?
• 活动发布频繁，如何快速评估服务资源？

以上问题亟待建立全新的监控机制，帮助开发/运维人员全面洞察系统运行状态，并在系统异常时帮助其快速定位解决问题，云原生可观测性基础设施应运而生。可观测性则是通过采集业务指标、日志、追踪等数据，快速分析与定位问题，同时发现复杂系统的瓶颈点，在很长一段时间内，业务指标、日志、追踪的采集与应用，都是独立存在并分开建设，随着时间的推移，发现这三者是相互关联，相辅相成的，是云原生 SRE 保障的一把利器。

微服务调用关系图：

2、可观测性架构
玄图-可观测性平台 基于 OpenTelemetry 通用解决方案，结合 IEG 营销服务场景的服务高吞吐以及采集治理等特性要求，平台架构设计如下图 所示。玄图可观测性平台的架构以 OpenTelemetry 为核心，覆盖 Trace/Metric/Log 数据采集、传输、处理和应用全流程。

玄图可观测性平台特点如下：

• OneSDK 统一上报 : 遵循 OpenTelemetry 协议规范，集成指标、追踪、日志能力-OneSDK，解决多节点上报时间误差至微妙级；
• 灵活的数据治理能力 : 支持多种动态采样策略、数据聚合控制、熔断及降级机制。根据业务的不同体量、精细化程度等要求，灵活配置与下发策略。通过兼容流式线的头部干预、尾部干预的综合治理能力，保障业务运行稳定；
• 丰富的能力扩展支持 : 为运营场景中复杂业务架构提供 AiOps 异常检测、混沌强弱依赖分析、全链路压测（精准资源评估）等扩展能力；
• 多语言 SDK 支持 : 目前可支持 Golang、Python、C++、PHP、RUST、JS 多种开发语言；
• 稳定性架构 : 支持多租户管理与运营，支持主机与 K8S 环境部署，支持百亿 PV 架构，协助运营人员快速发现、定位、分析与解决问题，效率提升 5 倍+；
• 服务解耦&分级存储 : 引入 Kafka/Pulsar 消息中间件做上下游解耦，极大扩展前后台服务能力，便于集成数据应用，且支持满足不同应用场景的分级存储，支撑高峰上报 QPS300W/S 的运营能力，提供秒级数据处理能力。

3、可观测性架构
1）数据采集治理
微服务链路错综复杂，海量的链路追踪数据对可观测性平台服务的运营能力更是不小的挑战，完备的数据采集治理能力必不可少。玄图可观测性平台为运维和开发人员提供了丰富的采样治理能力和运营治理能力，如图 所示， 玄图可观测平台支持多种动态采样策略、数据聚合控制、熔断及降级机制等采集运营策略。满足不同业务体量和精细化程度运营要求，支持灵活配置与下发策略，且通过兼容流式线的头部干预、尾部干预的综合治理能力，为业务稳定运行保驾护航。

2）链路数据检索
玄图可观测性平台为用户提供链路追踪数据采集、传输、处理和应用全流程服务。其中通过链路数据检索和可视化功能可清晰明了地看到同一调用链下服务内部和服务间调用链路及其相应调用状态、调用时延等指标，可帮助用户快速定位链路异常点和分析服务性能瓶颈点。同时平台也提供了丰富的查询条件来帮助业务快速检索到所需链路数据，方便易用。

3）链路调用拓扑
微服务链路错综复杂，玄图可观测平台提供了服务间调用拓扑关系图，帮助业务快速了解其业务场景下服务间上下游调用关系，从全局的视野观察和保障服务运营。玄图还利用该链路拓扑能力结合混沌工程、全链路压测，扩展更多业务服务能力（下面会有详细叙述）。

4）数据上报统计
对上报的链路数据，平台同时提供了多维度的统计能力，包括租户和服务维度下的错误率、P50/P95/P99 延迟、调用次数等指标。通过该分析数据，业务可轻松地观测到某个时间段内耗时最高、成功率最差、调用次数最多的服务表现，从而帮助运营任务分析问题；同时这些统计数据也对接了外部监控组件，可按照业务自定义规则进行告警，帮助业务第一时间发现问题。

4、平台能力扩展
1）全链路的异常检测
就异常检测而言，基于领域的传统 IT 管理解决方案往往只能在单一或数个维度根据人工规则进行判断，无法充分利用多种数据间的潜在关联性，也很难考虑到一些特殊情况，因而无法智能化地提供可靠、高可用的洞察和预测性分析。以玄图可观测性平台为基础的 AIOps 的研究旨在使用智能化的分析手段对 Trace/Metric/Log 数据进行分析，辅助传统规则方法，以更加精准识别服务的异常点，减少误告。

…