云原生背景运维转型之 SRE 实践

作者：yorkoliu，腾讯 IEG 业务运维专家

一、前言

上一篇文章《云原生背景下的运维价值思考与实践(上)》 重点介绍了云原生背景下运维转型的思考，围绕着整个 DevOps 交付链，贴近业务不断输出运维的能力与价值。这篇内容我想谈谈 DevOps 的下半段，通过我们的构建服务稳定性保障实践，利用 SRE 的思想与方法，不断去冲刺稳定性的终极目标：“提升 MTBF（平均故障时间间隔）、降低 MTTR（故障平均修复时间）”，很多小伙伴会有疑问，DevOps 与 SRE 到底是什么样的关系？在 Google 出版的第二本书《The Site Reliability Workbook》的第一章节 ，已经明确给出了这个问题的解释，一行代码胜千言：“class SRE implements interface DevOps”，即 SRE 是 DevOps 的一种实现方式，也是 Google 在运维领域的一种具体实践。个人也比较认同这个解释，也深受启发，不得不佩服 Google 大佬的抽象与总结能力，放眼国内运维行业的发展历程，也潜移默化在形成自己的发展路径，实践与 Google 提出的 SRE 具有异曲同工之妙，缺少的是进一步做抽象，形成一套完整的方法论体系。本文的出发点也是站在巨人肩膀之上，结合自身业务服务场景，思考在云原生背景下，运维转型还有多少种可能性，本文或许只给出其中一种答案吧。

二、构建 SRE 体系

▫ SRE 能力全景

我们因地制宜，根据 IEG 海量在线营销的业务场景，引入 SRE 度量的机制、定制 SRE 准则，以及打造较为完备的工具链体系，以下是团队构建的玄图-SRE 稳定性建设全景图：

图2.1 - 玄图-SRE稳定性建设全景图

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

全景图的中间是我们的玄图 SRE 体系，采用蓝鲸多级编排组装体系中的各种能力项，MTBF 列意为平均故障时间间隔，可以理解成稳定性保障的事前与事后，在这个环节中，我们在原有基础上扩展出两个核心能力，其中一个是“混沌实验”，旨在通过主动注入服务故障，提前发现并解决系统存在的隐患，提升系统的韧性；另一个为“全链路压测”，模拟真实的并发数及用户访问，通过自动拓扑图快速找到影响性能模块，定位问题根源。MTTR 列意为故障平均修复时间，这里我们拆解了 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 的耗时。

▫ 定制 SRE 准则

 在实践 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 个维度。

• [x] Volume（容量）服务承诺的最大容量是多少，比如常见的 QPS、TPS、会话数、吞吐量以及活动连接数等等；