SRE 实践

SRE
SRE体系
SRE的目的
- 提升稳定性
系统可用性
设定稳定性的衡量标准
错误预算
故障发现
- On-Call 的流程机制建设
故障处理
- 建立有效的故障应急响应机制
故障复盘
SRE组织结构
SRE 的各个角色如何协作？

SRE

SRE 全称是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程实践中发扬光大。他们还出了一本同名书籍「Site Reliability Engineering」，让这个理念在互联网工程师圈子里广泛传播。

Google 对 SRE 解释是（via Site Reliability Engineering - Wikipedia）：

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 实战手册 » 的总结。