Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.

有人认为 SRE 就是一个岗位，而且是一个具备全栈能力的岗位，只要有这么一个人，他就能解决所有稳定性问题。这还只是一种理解，而且这个理解多是站在管理者的角度。

也有人站在运维人员的角度，认为做好 SRE 主要是做好监控，做到快速发现问题、快速找到问题根因；还有人站在平台的角度，认为做好 SRE 要加强容量规划，学习 Google 做到完全自动化的弹性伸缩；甚至还有人认为，SRE 就是传统运维的升级版，把运维自动化做好就行了。

你看，其实不同的人站在不同的角度，对 SRE 的理解就会天差地别，但是好像又都有各自的道理。

本文将从实践的角度来理解SRE： SRE 是一套体系化的方法，我们也只有用全局视角才能更透彻地理解它。

SRE体系

从全局视角来理解SRE体系

从上面这张图可以看出，为了保障系统的稳定性，我们需要做很多工作，这些能力之间的相互依赖，就决定了从职能分工上，SRE 体系的建设绝不是单个岗位或单个部门就能独立完成的，必然要求有高效的跨团队组织协作才可以。

从实践角度来看，SRE 的力量不能通过一个岗位、一个或几个技术就发挥出来。SRE 是一个体系化工程，它需要协同多个部门、多项技术。

SRE的目的

建设SRE体系是为了 提升稳定性。

从业界稳定性通用的衡量标准看，有两个非常关键的指标：

MTBF，Mean Time Between Failure，平均故障时间间隔。
MTTR，Mean Time To Repair，故障平均修复时间。

通俗地说，MTBF 指示了系统正常运行的阶段，而 MTTR 则意味着系统故障状态的阶段。

提升稳定性

提升稳定性的手段：

提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长
降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长。

从 SRE 稳定性保障规划图中，可以看出 MTTR 可以细分为 4 个指标：MTTI、MTTK、MTTF 和 MTTV。

MTTI (Mean Time To ldentify,平均故障发现时间)，也就是从故障实际发生，到我们真正开始响应的时间。这个过程可能是用户或客服反馈、舆情监控或者是监控告警等渠道触发的。
MTTK (Mean Time To Know，平均故障认知时间)，更通俗一点，可以理解为我们常说的平均故障定位时间。这个定位指的是root cause,也就是根因被定位出来为止。
MTTF (Mean Time To Fix，平均故障解决时间)，也就是从知道了根因在哪里，到我们采取措施恢复业务为止。这里采取的手段就很多了，比如常见的限流、降级、熔断，甚至是重启。
MTTV (Mean Time To Verify,平均故障修复验证时间)，就是故障解决后，我们通过用户反馈、监控指标观察等手段，来确认业务是否真正恢复所用的时间。

现在，我们再来看 SRE 稳定性保障规划这张图，你就会理解，为什么要把所做的事情分组分块呈现。目的就是区分清楚，我们做的任何一件事情、开发的任何一套系统、引入的任何一个理念和方法论，有且只有一个目标，那就是”提升 MTBF，降低 MTTR”，也就是把故障发生时间的间隔变长，将故障影响的时间减少。

比如，在 Pre-MTBF 阶段（无故障阶段），我们要做好架构设计，提供限流、降级、熔断这些 Design-for-Failure 的服务治理手段，以具备故障快速隔离的条件；还可以考虑引入混沌工程这样的故障模拟机制，在线上模拟故障，提前发现问题。

在 Post-MTBF 阶段，也就是上一故障刚结束，开启新的 MTBF 阶段，我们应该要做故障复盘，总结经验，找到不足，落地改进措施等。

在 MTTI 阶段，我们就需要依赖监控系统帮我们及时发现问题，对于复杂度较高和体量非常大的系统，要依赖 AIOps 的能力，提升告警准确率，做出精准的响应。

同时 AIOps 能力在大规模分布式系统中，在 MTTK 阶段也非常关键，因为我们在这个阶段需要确认根因，至少是根因的范围。

好了，按照以终为始的思路，SRE 要实现的目标就是”提升 MTBF、降低 MTTR”，从这个角度出发，我们再次认识到一定要把 SRE 作为一个体系化的工程来建设，因为单纯在某些技术点上发力是没有多大意义的。

系统可用性

衡量系统可用性的 2 种方式：

时间维度：Availability = Uptime / (Uptime + Downtime)
请求维度：Availability = Successful request / Total request

时长维度，是从故障角度出发对系统稳定性进行评估。

时间维度的可用性测量方法包含的三要素:

衡量指标
衡量目标
影响时长

常见的按时长维度统计的可用性对照表：

系统可用性	故障时间/年	故障时间/月	故障时间/周	故障时间/天
90%	36.5天	72小时	16.8小时	2.4小时
99%	3.65天	7.2小时	1.68小时	14.4分钟
99.9%	8.76小时	43.8分钟	10.1分钟	1.44分钟
99.99%	52.56分钟	4.38分钟	1.01分钟	8.66秒
99.999%	5.26分钟	25.9秒	6.05秒	0.87秒

用时长维度来衡量系统稳定性的方式，其主要缺点就是粒度不够精细。

请求维度，是从成功请求占比的角度出发，对系统的稳定性进行评估。

请求维度的可用性测量方法包含的三要素:

衡量指标
衡量目标
统计周期

这种方式对系统运行状况是否稳定监管得更为严格，不会漏掉任何一次问题的影响，因为它对系统整体运行的稳定性判定，不仅仅会通过单次的异常影响进行评估，还会累计叠加进行周期性的评估。

故障一定意味着不稳定，但是不稳定，并不意味着一定有故障发生。

设立系统稳定性目标要考虑的3个因素：

第一个，成本因素。 可用性越高，相应付出的成本就越高。比如为了更高的可用性，要有更多的冗余资源投入，甚至要做主备、双活甚至是多活。
第二个，业务容忍度。稳定性怎么设定，很大程度上还要取决于业务上的容忍度。对于核心业务或核心应用来说，当然是希望成功率越高越好，一般对系统稳定性要求是3 个9或4 个 9。因为这些系统一旦出问题，就会直接影响整个网站和公司的收益，这些都是钱，所以对稳定性要求必然就会提高。但是，对于非核心业务或应用，比如商品评论，商品评分等，或许”2 个 9”也能容忍。因为短时间的评论看不到，并不会对业务收入和用户体验造成太大的影响。
第三个，系统当前的稳定性状况。结合系统的实际情况，定一个合理的标准比定一个更高的标准会更重要。比如，如果系统可用性是低于 99% 的，那首先第一步是不是可以做到 99%，然后再争取做到 99.5%，再到 99.9%，一步一步朝着更高的标准迈进。同时，这样做也会更容易落地，因为你如果定一个太高的目标，又始终达不成，反而会打击到团队的自信心和积极性。

设定稳定性的衡量标准

“确定成功请求条件，设定达成占比目标” 的过程，在 SRE 中就是设定稳定性衡量标准的 SLI 和 SLO 的过程。

SLI，Service Level Indicator，服务等级指标，其实就是我们选择哪些指标来衡量我们的稳定性。
SLO，Service Level Objective，服务等级目标，指的就是我们设定的稳定性目标

落地 SRE 的第一步其实就是“选择合适的 SLI，设定对应的 SLO”。

比如，http状态码返回为非 5xx 的比例大于等于 99.95%时，我们就认为这个应用是稳定的。

在 SRE 实践中，我们用 SLI 和 SLO 来描述。”状态码为非 5xx 的比例” 就是 SLI，”大于等于 99.95%”就是 SLO。说得更直接一点，SLO 是 SLI 要达成的目标。

在这个例子中，SLI 就是我们要监控的指标，SLO就是这个指标对应的目标。

确定SLI指标的两大原则

原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
原则二：针对电商这类有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。

快速识别 SLI 指标的方法：VALET

VALET 是 5 个单词的首字母，分别是 Volume、Availability、Latency、Error 和Ticket。这 5 个单词就是我们选择 SLI 指标的 5 个维度。

类别	解释
Volume（容量）	服务承诺的最大容量是多少。比如QPS、TPS、会话数、吞吐能力以及连接数等等
Availablity（可用性）	代表服务是否正常，比如请求调用的非5xx状态成功率、任务执行成功情况
Latency（时延）	响应是否足够快，比如时延，但时延的分布符合正态分布，需指定不同的置信区间，有针对性解决。
Error（错误率）	有多少错误率，比如5xx、4xx，也可以自定义状态码
Ticket（人工介入）	是否需要人工介入，比如任务失败需人工介入恢复

如何通过SLO计算可用性？

第一种，直接根据成功的定义来计算。

比如 Successful = （状态码非 5xx） & （时延 <= 80ms）
第二种方式，SLO 方式计算。

SLO1：99.95% 状态码成功率 SLO2：90% Latency <= 80ms SLO3：99% Latency <= 200ms

Availability = SLO1 & SLO2 & SLO3

Google 的 SLI 和 SLO 设定模板链接：https://landing.google.com/sre/workbook/chapters/slo-document

错误预算

错误预算（Error Budget）最大的作用就是“提示你还有多少次犯错的机会”

错误预算是怎么得出的呢？其实计算方式一点都不复杂，简单讲就是通过SLO 反向推导出来的。

假设一个应用在4周的时间内，所有的请求次数为4,653,680，按照给出的 SLO 反向推导，就可以得到容许的错误次数，这就是错误预算。

SLO	Error Budget
99.95% Availability	23,268
90% Latency <= 80ms	465,368
99% Latency <= 200ms	46,536

在 SLO 落地实践时，我们通常就把 SLO 转化为错误预算，以此来推进稳定性目标达成。

如何应用Error Budget?

稳定性燃尽图，按照4周一个周期来制作错误预算燃尽图，可以随时查看错误预算的消耗情况。
故障定级，根据错误预算消耗的比例来指定故障的级别。
稳定性共识机制，在我们系统稳定性保障过程中，我们也会根据剩余预算的情况，来制定相应的行动措施，来避免我们的稳定性目标，也就是 SLO 达不成。当错误预算处于不同状态时，采取两个指导原则: 第一.剩余预算充足或未消耗完之前，对问题的发生要有容忍度。第二，剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更。
基于错误预算的告警

如何衡量slo的有效性?

衡量 SLO 及错误预算策略是否有效，其实就是看实际运行后，是否真的能达到我们的期望。我们可以从下面三个关键维度来看。

SLO 达成情况。我们用达成（Met），或未达成（Missed）来表示。
“人肉”投入程度。英文表示为 Toil，这里用形象一点的”人肉”投入作为它的译意，泛指需要大量人工投入、重复、繁琐且没有太多价值的事情。我们用投入程度高（High）和低（Low）来表示。
用户满意度。英文就是 Customer Satisfaction，可以理解为用户感受和体验如何。这个信息可以通过真实和虚拟渠道获得。真实渠道如客服投诉、客户访谈和舆情监控获取；虚拟渠道如真机模拟拨测。我们用满意度高（High）和低（Low）来表示。

三种维度在不同情况下的应对策略

第一类，收紧 SLO。这个时候就是目标定得太低了，比如 SLO 达成（Met），但是用户不满意（Low）。遭到大量投诉，这就表示我们的 SLO 设定得太容易达成，没有反馈真实的运行状况。
第二类，放宽 SLO。目标定太高，总是达不成（Missed），但用户反馈却很不错（High），这种就会造成错误预算提前消耗完，导致很多变更暂停，产品延期，甚至会做一些无谓的优化，这时就可以适当松松绑。
第三类，保持现状，对有问题的维度采取有针对性的优化措施。是我们期望的最理想状态，SLO 能达成，人肉投入又低，客户满意度又很高，也没有特别的优化空间，这时我们就可以增加发布和变更次数，更大程度地释放生产力。

设定 SLO 有哪些原则？

第一，核心应用的 SLO 要更严格，非核心应用可以放宽。
第二，强依赖之间的核心应用，SLO 要一致。
第三，弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。
第四，Error Budget 策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的，

如何验证核心链路的 SLO？

容量压测
Chaos Engineering，也就是混沌工程

应该在什么时机做系统验证？

选择在业务量相对较小的情况下, 一般是一天的凌晨时间做演练。

故障发现

MTTI (Mean Time To ldentify,平均故障发现时间)，也就是从故障实际发生，到我们真正开始响应的时间。这个过程可能是用户或客服反馈、舆情监控或者是监控告警等渠道触发的。

减少MTTI时间

第一件事，判断出现的问题是不是故障；

根据设定的 SLO 和错误预算，准确判断发生的问题是否是故障，并依据故障等级决定我们采取什么样的措施去处理这些问题，大大提高反应效率。
第二件事，确定由谁来响应和召集。

建设 On-Call 机制

On-Call 的流程机制建设

确保关键角色在线。 产品体系中的所有关键角色。
组织 War Room 应急组织。建立专门的应急群，将这些关键角色纳入其中，当有故障发生时会第一时间在群通报，这时对应的 On-Call 同事就要第一时间最高优先级响应呼叫。
建立合理的呼叫方式。建议使用固定的 On-Call 手机，建立手机与所有 On-Call 系统的对应关系，比如这个手机号码对应交易核心应用，另一个号码对应 IDC 机房运维等等。这样我们在 On-Call 时就不再找具体的哪个人，而是手机在谁手中，谁就承担 On-Call 职责。
确保资源投入的升级机制。 授予On-Call值班人员有权调动其他必要资源投入。如果故障等级偏高，一下无法明确具体找哪些人员投入的时候，SRE 或运维可以直接上升到自己的主管或相关主管那里，要求上级主管协调资源投入。必要时，还可以上升到更高级主管，甚至 CTO 或技术 VP 来关注。
与云厂商联合的 On-Call。应该把云产品和云厂商作为我们系统的一部分，而不是单纯的第三方。而对于云厂商来说，也要考虑把客户业务作为自身业务的一部分，只有这样双方才能紧密合作。我们应该提前做好与云厂商之间的协作磨合，联合故障演练，必要的授权等等。

故障处理

基本原则： 在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级。

故障处理过程中效率如何，其实取决于三个因素：

技术层面的故障隔离手段是否完备；
故障处理过程中的指挥体系是否完善，角色分工是否明确；
故障处理机制保障是否经过足够的演练。

建立有效的故障应急响应机制

关键角色分工

Google 的故障指挥体系，是参考了美国消防员在处理 1968 年森林大火时建立的应急指挥体系，体系中有三个核心角色。

Incident Commander，故障指挥官，简称为 IC。这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行。
Communication Lead，沟通引导，简称 CL。负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA 或者是某个 SRE 来承担都可以，但是要求沟通表达能力要比较好。
Operations Lead，运维指挥，简称 OL。负责指挥或指导各种故障预案的执行和业务恢复。
这里其实还有一类角色，虽然不在指挥体系内，但是也非常重要，我们也要做一下介绍：

Incident Responders，简称 IR。就是所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，比如具体执行的 SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是 QA 等。

流程机制

故障发现后，On-Call 的 SRE 或运维，最一开始就是 IC，有权召集相应的业务开发或其它必要资源，快速组织 War Room。
如果问题和恢复过程非常明确，IC 仍然是 SRE，就不做转移，由他来指挥每个人要做的具体事情，以优先恢复业务优先。
如果问题疑难，影响范围很大，这时 SRE 可以要求更高级别的主管介入，比如 SRE 主管或总监等，一般的原则是谁的业务受影响最大，谁来牵头组织。这时 SRE 要将 IC 的职责转移给更高级别的主管，如果是全站范围的影响，必要时技术 VP 或 CTO 也可以承担IC 职责，或者授权给某位总监承担。

反馈机制

一般要求以团队为单位，每隔 10～15 分钟做一次反馈，反馈当前处理进展以及下一步Action，如果中途有需要马上执行什么操作，也要事先通报，并且要求通报的内容包括对业务和系统的影响是什么，最后由 IC 决策后再执行，避免忙中出错。没有进展也是进展，也要及时反馈。

为了尽量减少对执行者的干扰，让执行者能够更聚焦，我们一般要求团队 Leader 来收集反馈并传递 IC 的指令。CL 也要收集信息，他要做的不是传达指令，而是在更大范围内同步汇总后的信息，同时还要整理信息传递给外部联系人。

对于技术以外的人员反馈，如客服、PR 以及商家和其它各类合作代表等等。一定不是用技术术语，而是以尽量业务化的语言描述，并且要给到对方大致的预期，比如我们正在做什么，大致多长时间会恢复，如果不能恢复，大约多长时间内会给一个反馈等等。

如果故障的影响范围很广，那我们就要考虑得尽量周全，这时的故障处理在一定程度上，就不单单是技术团队的问题了，而是需要整个公司都投入资源的。

故障复盘

故障复盘的黄金三问：

第一问：故障原因有哪些？
第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
第三问：当时如果我们做了什么，可以用更短的时间恢复业务？

具体开复盘会的时候，就是紧扣着这三问来进行的。除此之外不允许出现相互指责和埋怨的情况，如果出现，会议主持者要及时控制并打断。

故障判定的三原则：

健壮性原则。这个原则是说每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等
第三方默认无责。如果使用到了第三方的服务，如公有云的各类服务，包括 IaaS、PaaS、CDN 以及视频等等，我们的原则就是默认第三方无责。
分段判定原则。当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们会将一次故障分段判断。

SRE组织结构

在讲 SRE 的组织架构之前，我们需要先明确两点内容。

第一，组织架构要与技术架构相匹配。技术架构实现组织目标，组织架构服务并促成技术架构的实现。
第二，SRE 是微服务和分布式架构的产物。

想要引入 SRE 体系，并做对应的组织架构调整，首先要看我们的技术架构是不是在朝着服务化和分布式的方向演进。

技术架构图

蘑菇街基于微服务和分布式技术的 High-Level 的架构图

基础设施层: 主要是以资源为主，包括 IDC、服务器、虚拟机、存储以及网络等部分，这层所需的运维能力就是我们传统运维这个角色所要具备的能力。如果能够依托云的能力，不管是公有云还是私有云，这一部分传统运维的能力在绝大部分公司，基本就不需要了。
技术中台主要包括我们使用到的各种分布式部件，如缓存、消息、数据库、对象存储以及大数据等产品，这一层最大的特点就是”有状态” ，也就是要存储数据的产品。这部分产品的运维也会由中间件团队自运维。很多大型的公司会有专门的平台运维团队，负责整个中间件产品的运维。
业务中台层，就是将具有业务共性的产品能力提炼出来，比如用户、商品、交易、支付、风控以及优惠等等，上面支撑的是业务前台应用。这层的运维职责，通常就是我们常说的应用运维、PE（ProductionEngineer）或者叫技术运营这样的角色来承担。
什么是业务前台呢？如果以阿里的产品体系来举例，可以类比为淘宝、天猫、盒马、聚划算这样的业务产品。这层的运维职责，通常就是我们常说的应用运维、PE（ProductionEngineer）或者叫技术运营这样的角色来承担。
接入层，分为四层负载均衡和七层负载均衡。前者因为跟业务逻辑不相关，所以通常会跟基础设施层放在一起，由传统运维负责。但是七层负载需要做很多业务层面的规则配置，所以通常会跟中台和前台一起运维。

根据上诉的一些描述，我们可以得到一个理念：“运维能力一定是整个技术架构能力的体现，而不是单纯的运维的运维能力体现”

技术保障体系

工具平台团队，负责效能工具的研发，比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，为基础运维和应用运维提供效率平台支持。
稳定性平台团队，负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划。我们会看到这个团队主要是为稳定性保障提供支撑，平台提供出来的能力是可以直接支撑业务开发团队的，反倒是 PE 这样的角色并不会直接使用。

组织架构图

根据上述的层层剖析，可以得出一张组织架构图。

SRE 并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队。如果从分工来看就是：SRE = PE + 工具平台开发 + 稳定性平台开发。

SRE 的各个角色如何协作？

“以赛代练”这个术语最早也是在一些体育赛事中提出来的，完整解释是通过比赛带动训练。比如足球、篮球或田径等比赛，目的就是让运动员在真实的高强度竞争态势和压力下，充分暴露出个人和团队的不足及薄弱点，然后在后续的训练中有针对性地改进，这样对于比赛成绩的提升有很大帮助，而不是循规蹈矩地做机械性训练。

通过 “以赛代练” 的策略放在我们的系统稳定性建设中也非常适用。你也可以选择类似的真实且具备高压效果的场景，来充分暴露我们的稳定性存在哪些问题和薄弱点，然后有针对性地进行改进。

以电商大促这个场景为例，来协作SRE的各个角色

第一步，大促项目开工会。

在这个会议上，我们会明确业务指标，指定大促项目的技术保障负责人，通常由经验丰富的业务技术成员或平台技术成员承担，同时会明确技术团队的分工以及各个团队的接口人，然后根据大促日期，倒排全链路压测计划。分工和计划敲定了，接下来就是一步步执行了。
第二步，业务指标分解及用户模型分析评审会。

业务指标分解和用户模型分析阶段，需要业务开发和 PE 团队共同配合，主要是共同分析出核心链路，同时 PE 要分析链路上的应用日常运行情况，特别是 QPS 水位，这里就要利用到SLO 的 Dashboard，结合这两点，大致判断出要扩容的资源需求。
第三步，应急预案评审会。

在预案准备阶段，仍然是 PE 与业务开发配合，针对核心链路和核心应用做有针对性的预案讨论。这时就要细化到接口和方法上，看是否准备好限流、降级和熔断策略，策略有了还要讨论具体的限流值是多少、降级和熔断的具体条件是怎样的，最后这些配置值和配置策略都要落到对应的稳定性配置中心管理起来。
第四步，容量压测及复盘会。

在容量压测这个阶段，就需要 PE、业务开发和稳定性平台的同学来配合了。业务开发在容量规划平台上构造压测数据和压测模型，稳定性平台的同学在过程中要给予配合支持，如果有临时性的平台或工具需求，还要尽快开发实现。

每个角色负责的内容：

第一，PE 更加关注线上整体的运行状态，所以视角会更全局一些，业务开发则更关注自己负责的具体应用，以及深入到代码层面的分析工作。
第二，PE 会主要负责平台级的公共部件，如缓存、消息和文件等；DBA 负责数据库，所起到的作用与 PE 相同，他们关注这些平台部件的容量评估、服务治理策略，以及应急预案等；而业务开发则会把更多的注意力放在业务层面的容量评估和各类策略上。同时，PE 和业务开发关注的内容是相互依赖的，他们的经验也有非常大的互补性和依赖性，所以这个过程，双方必须要紧密配合。
第三，这个过程中，你可能会发现，工具开发和稳定性开发的同学在其中参与并不多，这是因为他们的价值更多体现在平时。我们依赖的各类平台和工具，比如扩缩容、链路分析、测试数据制造、压测流量的模拟等能力，都是通过这两个团队在平时开发出来的。对于这两个团队来说，这个时候出现得越少，他们的价值才是越大的。

SRE 组织中的各个角色平时应该要做些什么呢？

第一项，核心应用变更及新上线业务的稳定性评审工作。这里就包括前面讲到的容量评估和压测、预案策略是否完备等工作。PE 会跟业务开发一起评估变动的影响，比如变动的业务逻辑会不会导致性能影响，进而影响容量；对于新增加的接口或逻辑，是否要做限流、降级和熔断等服务治理策略，如果评估出来是必需的，那上线前一定要把这些策略完善好；同时在测试环境上还要做验证，上线后要关注 SLO 是否发生变化等。
第二项，周期性技术运营工作。这些就包括了我们要例行关注错误预算的消耗情况，每周或每月输出系统整体运行报表，并召集业务开发一起开评审会，对变化较大或有风险的 SLO重点评估，进而确认是否要采取改进措施或暂停变更，以此来驱动业务开发关注和提升稳定性。

本文是对极客时间的 « SRE 实战手册 » 的总结。

云原生背景运维转型之 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、会话数、吞吐量以及活动连接数等等；
[x] Availablity（可用性）代表服务是否正常或稳定，比如请求调用 HTTP 200 状态的成功率、任务执行成功率等；
[x] Latency（时延）服务响应是否足够快，比如时延是否符合正态分布，需指定不同的区间，比如常见的 P90、P95、P99 等；
[x] Error（错误率）服务有多少错误率，比如 5XX、4XX，以及自定义的状态码；
[x] Ticket（人工干预）是否需要人工干预，比如一些复杂故障场景，需人工介入来恢复服务。

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

图3.1 - SLO跟踪统计报表

四、工具链建设

SRE 的准则与方法论固然重要，但没有强有力的工具链来作为支撑，在执行面将面临步步维艰，因此我们在 2 年前就开始着手规划 SRE 工具链的建设，根据 SRE8 准则的平台能力要求，明确了三个发展的能力项，分别为可观测性、混沌实验、全链路压测等。首先我们也积极拥抱开源社区，得益于社区成熟技术标准与 SRE 工具链组件，让我们可以充分借用社区的力量，快速且低成本构建满足我们自身业务场景的服务能力。同时我们也积极参与开源社区，包括贡献源码，行业大会技术布道，参与中国信通院发起的行业标准定制等等。玄图-SRE 工具链体系，第一期我们通过“三位一体”，有效助力业务在“事前”提前发现潜在问题，“事中”快速定位问题根因，以及“事后”快速复盘历史故障。帮助业务实现服务高可靠性的目标。放眼行业，此组合方案也是云原生环境稳定性保障的首选。下面是玄图 SRE 工具链能力全景图：

图4.1 - 玄图-SRE工具链能力全景图

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

五、可观测性平台

1、可观测概括

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

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

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

图5.1 -微服务调用关系图

2、可观测性架构

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

图5.2 -玄图可观测性架构图

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

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

3、平台能力扩展

3.1 数据采集治理

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

图5.3 -数据采集治理技术架构

3.2 链路数据检索

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

图5.4 - 服务链路追踪检索

3.3 链路调用拓扑

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

图5.5 -服务链路拓扑图

3.4 数据上报统计

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

图5.6 - 服务数据上报统计

4、平台能力扩展

4.1 全链路的异常检测

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

图5.7 - 服务异常检测方案架构图

玄图 AIOps 实践思路如上图 5.7 所示，获取最新一段时间的 Trace/Metrics 数据，通过训练好的模型推算异常权重，识别出异常的 Trace 数据。其中模型特征较为关键，我们通过测试阶段和上线阶段两个阶段不断完善，其中测试阶段我们结合压测平台和混沌实验，模拟故障，自动标注异常特征，并于上线阶段，采集现网真实的 Trace 异常点结合任何判断不断更新特征库。以下是平台上的 AIops 能力展示：

图5.8 -异常检测效果图1

4.2 调用强弱依赖分析

玄图可观测性链路追踪结合混沌平台，可以快速分析出服务间强弱依赖关系。玄图可观测性调用跟踪系统追踪记录了服务间的调用关系，使用混沌工程给被调服务注入故障，观察主调服务的业务指标，可以得出服务间的强弱依赖关系。业务方可以进一步结合具体业务场景进行依赖治理，优化关键路径，实现低耦合架构。比如某游戏任务系统这个例子，获取任务配置服务超时致入口超时，进而导致玩家请求失败，未能降级从本地获取配置，控制面的配置服务故障影响到了数据面，显然是不合理的。非核心服务出现了问题不能将问题一直传递下去导致服务整体不可用。

图5.9 - 强弱依赖分析案例

六、混沌实验平台

1、混沌工程概述

在我们将应用以云原生的方式上云之后，受益于云原生的 devops、K8S、微服务、服务网格等技术红利，应用的上线下线、发布变更、容量管理、服务治理等运营效率获得了极大提升。海量的并发请求、敏捷的运营诉求驱动着应用从单体服务向微服务、分布式系统演进。运营效率提升的同时也带来了新的挑战，主要表现为以下几点：

分布式系统日益庞大，很难评估单个故障对整个系统的影响；
服务间的依赖错综复杂，单个服务不可用可能拖垮整个服务；
请求链路长，全链路监控告警、日志记录等不完善，定位问题难；
业务、技术迭代速度快，频繁发布变更，使得系统的稳定性受到更大的挑战。

在复杂的分布式系统中，无法阻止故障的发生，而且发生时间可能是周末、半夜、团建时等。我们应该致力于在这些异常故障被触发之前，尽可能多地识别风险。然后，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。混沌工程正是这样一套通过在分布式系统上进行实验，主动找出系统中的脆弱环节的方法学。混沌工程则是通过模拟现网真实故障来验证服务的“韧性”，找出系统的弱点，同时验证我们的监控告警的有效性，在 MTBF 阶段实施最好不过，是我们 SRE 保障的第二把利器。

图6.1 - 混沌工程的必要性（图片来源网络）

2、平台技术架构

玄图体系致力于打造完整的云原生运维能力，其中混沌工程作为质量管理工具，通过故障注入的方式帮助系统寻找薄弱点，提高系统的稳定性，构建具备韧性的应用。玄图混沌实验平台主要基于开源技术框架，并且在原框架基础上引入了开源组件 ChaosMesh 和 ChaosBlade。玄图混沌实验平台架构如下图 6.2 所示，在平台设计层面，我们按照计划-编排-执行-观察-记录-还原的思路，设计了演练计划、演练编排、演练管理、演练报表和演练报告等模块。基于这些模块，在平台上可以实施自动化日常演练、红蓝攻防演练、突袭演练等丰富的能力，且打通了蓝鲸、奇点、北极星等内部系统，业务开箱即用。

图6.2 - 玄图混沌工程实验平台架构图

具体平台能力体系如下：

故障注入场景丰富，玄图混沌工程实验平台提供 27 种故障原子，覆盖主机和 K8S 环境，并且支持自定义扩展；
灵活的实验编排能力，平台提供灵活的实验编排能力，相对于手工脚本编排实验，通过平台执行故障演练效率提升 10 倍；
实验观测&实验报告闭环，玄图混沌工程实验平台打通了监控系统，实验过程中可实时观测实验效果，实验结束输出实验报告；
红蓝对抗常态化，平台支持对抗演练记录、归档，便于回溯、沉淀，增强趣味性和参与积极性；
可扩展架构，平台基于可扩展架构设计，支持自定义故障原子，可灵活应对复杂实验需求；
通用性方面，玄图混沌实验平台将公司内部的蓝鲸、奇点、北极星、网管系统等系统进行集成打通，实现所有业务都能开箱即用，无需额外的开发接入改造成本，实现了一站式服务。下面分别具体介绍下玄图混沌实验平台具体能力体系。

3、平台能力扩展

1）故障演练提效

传统的手工故障演练一般是根据需求临时开发工具，工具开发完之后还需测试验证，功能大同小异，浪费了很多重复工作，临时开发的工具，效果还不能保证。玄图混沌平台的故障原子是经过大量的实践反复验证的，效果稳定可靠，拿起来就能直接用，没有开发成本。故障的原子非常丰富，可以模拟出机器、网络、操作系统、应用层异常等各种故障场景。平台还提供了灵活的实验编排能力，可以一次性把多个不同的故障编排之后自动执行。实验执行之后都需要观察效果，手工故障演练需要借助于其他工具或者第三方平台看效果，而玄图混沌平台打通了基础指标数据以及支持业务自定义指标，在实验过程中可以直接查看到实验效果。另外，临时演练是一次性的，没有记录和保留现场，没法回溯，玄图实验平台详细记录了每次实验内容，随时都可以查询以及复现。总结起来，玄图混沌工程故障演练平台，提供实验编排、执行、观察、记录一站式服务，将故障演练的耗时从小时级缩短到分钟级，相对于手工故障演练效率提高了 10 倍以上。

图6.3 - 精简流程，提升效率

2）故障注入原子

玄图混沌平台能够模拟的故障非常丰富，通过故障原子组合可以模拟出云服务异常，机器故障，操作系统故障，网络故障，应用层故障，以及根据特定场景定制的故障等。很好的解决了传统故障演练工具开发耗时久，工作重复，效果没发精准控制，工具没法复用等痛点。比如光纤中断生产环境很难复现，但通过混沌工程网络丢包实验可以轻松模拟。目前平台已经支持的故障注入能力如下：

表6.1 - 玄图混沌工程实验平台支持原子

3）实验编排能力

在实际场景中，我们一般需要同时模拟多个故障，也就是需要把多个故障编排在一起并行或者串行执行，玄图混沌平台支持拖拉拽完成复杂故障场景编排，可以同时模拟多个服务，多种类型故障，实现了分钟级复杂故障事件演练。

图6.4-实验编排

4）实验观测报告

混沌实验平台提供了实验编排、执行、观测、报告输出等一站式实验能力，比如我们需要验证一台机机器挂了对服务到底有何影响。可以在平台上发起一个丢包 100%的实验，理想情况下，1 分钟内能自动隔离异常机器，请求成功率会出现短暂下跌，1 分钟后能自动恢复。业务 QPS、耗时、成功率都能保持稳定。实验执行之后可以通过平台的报表实时观测效果，这里的例子我们发现响应延迟明显上升，QPS 明显下跌，并且持续 5 分钟以上都没有恢复，不符合预期。实验结束之后在平台可以直接记录实验结论：系统不能自动隔离剔除后端异常实例，需要优化改造。实验过程、数据得以很好的保存记录。

图6.5 - 实验报告

5）红蓝对抗常态化

玄图混沌平台还支持发起红蓝对抗，左右互搏通常很枯燥。通过红蓝对抗的方式，增加了故障演练的趣味性和游戏性。玄图混沌平台通过流程工具打通红蓝对抗的全流程，记录每一次演练的详情，很好的解决了传统的红蓝对抗，沟通成本高，缺少工具支持，流程不规范，反馈不及时，经验无沉淀的痛点。通过常态化的红蓝对抗故障演练培养了业务开发人员的风险意识，从软件设计之初就考虑到可能会遇到的各种故障，提前从架构设计层面规避，有效提升服务的容错能力。

图6.6 - 红蓝对抗流程图

6）可扩展架构

故障演练的需求随着技术和业务的发展会不断的变化，为了应对这种变化，我们从设计之初就采用了可扩展架构，实验原子之间解耦，某个原子的增删改不影响其他原子，遇到新的实验需求，可以任意横向增加原子，从软件架构上实现了对需求变化的灵活应对。

图6.7 - 可扩展框架

七、全链路压测+ 平台

1、全链路压测概述

游戏营销服务旨在通过精细化运营活动，实现拉新、拉活跃、拉回流等运营事件，使玩家获得更好的游戏体验。在线服务有如下特点：

节奏快，比如开黑节，战斗之夜，周年庆，活动仅持续数日；
数量多，每天都会有大量活动上线，而且活动种类繁多；
访问量大，游戏运营活动高峰时段日 PV 超过百亿；
访问量无法精准预估，很难精准的预测一次活动的访问量，玩家参与度经常超预期；
活动逻辑复杂，上下游依赖多，并且对依赖服务有 N 倍放大，容量评估工作量大。

正是由于营销活动这些特点，在日常运营中，我们几乎每天都要面临类似“双 11”的考验，经常面临如下难题：

活动上线节奏快，开发周期短，遇到性能问题需要快速定位解决；
微服务间调用关系复杂，性能问题排查困难，费时费力，难以快速诊断出瓶颈点；
调用拓扑链路不透明，需要耗费大量人力梳理调用关系和放大倍数；
已经在线上运行的服务容量评估主要依据经验，重要活动通过大量堆机器支撑。

为了解决以上难题，我们启动了全链路压测+平台建设，通过在生产环境对业务大流量场景进行高仿真模拟，获取最真实的线上实际承载能力、执行精准的容量规划，目的在于保障系统可用性。

事实上，系统的容量是一只薛定谔的猫，只有打开箱子才知道猫是什么情况，只有通过全链路压测才能准确掌握系统的极限值。如图 7.1 所示，QPS 到 1 万的时候，资源负载是 20%，根据经验预估 QPS 到 3 万负载到 60%，容量是充足的，流量涨 2 倍没问题。事实上影响服务性能的因素有很多，长连接、短链接、请求串、返回串的大小都会影响到服务性能，真正的两倍流量过来，服务已经过载了，经验往往是靠不住的。

图7.1 - QPS与资源负载曲线

只有通过生产环境全链路执行压测，真实模拟用户行为场景，实时监控系统表现，提前识别和快速定位系统的中的不确定因素，并对不确定因素进行处理，优化系统资源配比，使用最低资源成本，使系统从容面对各种极端场景，达到预期的系统性能目标。通过这种方法，在生产环境上落地常态化稳定压测体系，实现业务系统的长期性能稳定治理。因此平台放在 MTBF 阶段实施，是我们 SRE 保障的第三把利器。

2、全链路压测架构

传统压测工具的定位仅仅是制造压力，对目标服务发起请求，被压服务对其而言是个黑盒子，当压测发现问题后需要被压服务侧自行分析定位原因，压测工具能够发挥的作用有限，并且可替代性很强，市面上有非常多的压测工具可供选择。

全链路压测+平台具备传统压测工具的发压能力，压力引擎当前采用的是开源社区的 locust+boomer 方案，经过调优，单核发压能力能达到 2w/s，同时基于 TKE 云原生架构，压力源做到了弹性伸缩，可以根据负载自动扩容，理论上并发数可以做到无限扩展。同时，压力引擎可以根据需要灵活的集成使用其他优秀引擎。

图7.2 - 全链路压测+ 平台架构图

全链路压测+平台的重点在于对被压服务进行剖析，基于 SRE 工具链中的可观测性平台，拿到了服务调用关系链，通过 TraceID 可以将一次请求经过的全链路服务串联起来，基于此可以计算出服务间的调用拓扑图，在发起压测的同时自动生成全链路调用拓扑关系。并且统计出每一层调用的黄金监控指标，如 QPS、耗时、成功率等，可以一目了然的看到微服务间的放大倍数。在压测过程中能实时观测到全链路每个环节的指标，当压测出现瓶颈时，如入口延迟增大，从链路统计视图能快速定位到导致入口延迟增大的具体微服务，再进一步通过 trace 详情下钻分析，能够定位到具体的方法。

总体而言，全链路压测平台不仅提供了传统压测基础功能，如数据构造、请求拨测、压测监控、压测编排、发起压力等。同时提供了压测分析增值功能，如链路拓扑计算、链路统计、性能瓶颈定位、压测流量染色、根因下钻分析等。

3.平台能力介绍

3.1 灵活的压测编排

平台支持灵活的发压模式，包括：

固定压力模式：并发数固定，可以设置最大 QPS
阶梯压力模式：并发数持续增加，可以设置最大并发数和最大 QPS
快速压测模式：并发数持续增加，达到指定错误率或耗时阈值后压测自动停止

图7.3 - 压测编排

3.2 云原生架构

全链路压测+平台的压力源由平台托管，用户无需关注压力源。压力源基于 TKE 容器化部署，资源可以根据需要灵活扩展，理论上可以做到无限扩展。同时，平台将压力源的负载指标主动暴露出来，可以通过压测报告实时查看压力源负载数据。

图7.4 - 压力源负载指标

3.3 丰富的压测指标

全链路压测+平台的压测工具作为请求客户端，会实时上报压测指标，在压测过程中通过压测报告能实时观测到相关的监控指标，包括 QPS、耗时、成功率等，同时能够查看压测客户端的请求返回日志。

图7.5 - 压测指标监控

3.4 全链路拓扑图

基于可观测性技术，全链路压测平台能捕获微服务间调用拓扑关系，在压测过程中，根据实际请求调用链实时生成服务间调用拓扑图，并且统计出每一层调用的黄金监控指标，如 QPS、耗时、成功率等，通过拓扑图可以一目了然的看到微服务间的放大倍数。其中对于第三方服务（如 DB）在没有上报 trace 的情况下也能通过自动补链技术计算出统计指标。

图7.6 - 全链路拓扑图

3.5 全链路统计

基于可观测性技术，全链路压测平台能计算出链路拓扑图中每一层调用的黄金指标（QPS、耗时、成功率等），并通过时序报表实时展示。当压测出现瓶颈后（失败率或耗时明显增加），通过报表能够快速定位到导致系统出现瓶颈的微服务，再进一步通过 trace 详情下钻分析，能够定位到具体的方法，极大提升了性能问题定位效率。

图7.7 - 全链路指标统计

3.6 其它

除此之外，全链路压测+平台还提供压测流量染色（特定 Header 头）以及压测标记全链路透传功能，被压服务适配后能够实现压测流量隔离，将压测流量导流到影子库表。实现了在不污染生产环境业务数据情况下进行全链路性能测试，能在生产环境对写类型接口进行直接的性能测试，实现在生产环境可控压力测试。当前我们也正在探索无侵入的流量隔离方案，敬请期待。

八、思考与未来规划

SRE 体系的建设任重道远，完全复制 Google SRE 方法显然是行不通，个人认为原因有三个方面，第一点是以 Google SRE 岗位能力要求进行人才招聘，在国内存在一定难度；第二点是 SRE 文化在国内企业的认知与普及都不太够；第三点受限于基础设施即代码、体系化的 SRE 工具链、服务标准及抽象等能力成熟度。另外，我们也面临着诸多挑战，包括互联网行业日新月异的业务形态、新技术的不断发展，业务的复杂度势必会日益增大，但业务对稳定性诉求是不变的。同时，云原生环境存在着大量的三方 PaaS 连接与集成，稳定性保障也存在失控的风险。站在 SRE 的角度，任何一个细微环节的缺失与不足，都有可能影响 SLO 达标率。

为应对这些挑战，我们会将整个 SRE 稳定性全景拼图逐步进行拼凑，所以注定是一个长期持续建设的过程。下阶段我们会重点深度整合“三件套”能力，验证其真正发挥的效能。部分能力也会积极贡献给社区。相信不久，我们会陆续推出 SRE“四件套、五件套...”,大家拭目以待。

作者简介：刘天斯腾讯 IEG 在线营销 SRE 负责人，腾讯 T12 级技术专家，国家工程实验室兹聘专家。从事互联网技术运营近 16 年，热衷开源技术研究与应用，擅长海量服务运维(SRE)与规划、云原生技术、大数据治理、数据中台与业务中台的建设等工作。

o 曾荣获：华章最有价值作者、中国十大杰出 IT 博主、WOT 十大优秀讲师、OpsWorld 金牌讲师、TOP100 优秀出品人、中国数据质量杰出专家奖、DAMA 中国数据治理专家奖。

o 中国信息通信研究院-专家委员、海南省大数据产业联盟专家组成员，曾参与行业级《数据资产管理实践白皮书》、《数据标准管理白皮书》、《大数据运维成熟度模型》、《微服务分级标准》、《混沌工程平台能力要求》、《可观测性平台能力要求》等多个行业标准的编写。

o 个人著作：《python 自动化运维：技术与实践》、《循序渐进学 Docker》、《第一次使用 Docker 就上手》、《破解数据治理之谜》等，个人发明专利 12 个。

以上是关于《SRE实战》实践的主要内容，如果未能解决你的问题，请参考以下文章

SRE Google 运维解密读书笔记一：SRE 方法论概述

《SRE实战》实践

SRE实战手册带你搞定系统稳定性

基于计费流处理的全链路压测-江苏移动SRE运维实践

优维DevOps系列沙龙全回顾：DevOps+SRE落地实践+DevOps最后一棒

目录 SRE实战手册