SRE手册

SRE？

SRE（Site Reliability Engineering），网站稳定性工程，最早是由Google设置的一类工程师岗位，专职负责其超大规模分布式产品（如搜索、Gmail、Docs等）的稳定性。而后，SRE慢慢发展成了一系列面向稳定性的，包括技术、管理、流程、组织架构，以及文化建设的最佳实践，并最终被提炼成一套方法论，广泛流传。

在国内，SRE的这套方法论，也被很多企业的IT团队作为技术能力提升和组织转型，特别是运维转型的参考标准。

它是一套体系化的方法，做好SRE是需要以稳定性为目标的，而建立稳定性共识机制一定是自上而下，至少要从技术VP或CTO的角度去推行。

衡量标准

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

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

而MTTR可以细分为4个指标：MTTI、MTTK、MTTF和MTTV

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

---

SRE的目的，本质上是减少故障时间，增加系统正常运行时间，也就是 “减少故障，提升MTBF；同时，提升故障处理效率，降低MTTR”。SRE要做的所有事儿，都是为这两个目标服务的，一定要把SRE作为一个体系化的工程来建设。

系统可用性

顺着上一节来看，SRE的稳定性目标其实就是尽量减少系统故障或异常运行状态的发生，提升系统可用的运行时间占比，而在设定该目标之前，我们需要了解对应的可量化指标，即“系统可用性”这个概念。

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

目前业界有两种衡量系统可用性的方式：

• 时间维度：Availability = Uptime / (Uptime + Downtime)

  从故障角度出发对系统稳定性进行评估

• 请求维度：Availability = Successful request / Total request

时间维度

那从时间维度的uptime（健康时间）、downtime（生病时间）来看，怎么样才算是可用时长，什么情况下又是不可用时长呢？

测量判定三要素：

1. 衡量指标，系统请求状态码；
2. 衡量目标，非5xx占比，也就是成功率达到95%；
3. 影响时长，持续10分钟。

但是这里最显著的问题就是，稳定性只与故障发生挂钩。

即在持续一两周的时间内，发生了短暂的几秒到几分钟的自愈异常，业务并没有中断，按照时长维度来判断，这肯定不会算作系统故障。但持续发生短适频繁抖动，我们应该也可以判定系统运行状况是不正常的，它可能不是故障，但肯定是不稳定了。

这就需要第二种方式来衡量得更精细些了，也就是从请求维度来衡量系统可用性。

请求维度

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

测量判定三要素：

1. 衡量指标，请求成功率；
2. 衡量目标，成功率达到95%，才算系统运行正常；
3. 统计周期，一天、一周、一个月等，我们是在一个统计周期内计算整体状况，而不是看单次的。

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

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

那我们到底要为系统设定什么样的系统可用性呢？这其实没有一个标准答案，但是可以从以下因素决定：

成本因素

从理论上来说，肯定是9越多稳定性越好，但是相应付出的成本和代价也会更高。

比如为了更高的可用性，要有更多的冗余资源投入，甚至要做主备、双活甚至是多活。

如果一家公司的业务量和影响力都发展到一定程度，那这个成本不管多高都是必须要付出的。

但是，肯定不是所有的公司都需要付出这么高的成本，而是要先考虑ROI（回报率）。这时候就要看企业自身对成本压力的承担情况了。

业务容忍度

稳定性怎么设定，很大程度上还要取决于业务上的容忍度。

对于核心业务或核心应用，我们当然是希望成功率越高越好，一般对系统稳定性要求是“3个9”或“4个9”。

因为这些系统一旦出问题，就会直接影响整个网站和公司的收益，这些都是钱，所以对稳定性要求必然就会提高。

但是，对于非核心业务或应用，或许“2个9”也能容忍，并不会对业务收入和用户体验造成太大的影响。

系统当前稳定性状况

从系统现状入手，如果系统可用性是低于99%的，那首先第一步是不是可以做到99%，然后再争取做到99.5%，再到99.9%，一步一步朝着更高的标准迈进。

同时，这样做也会更容易落地，因为你如果定一个太高的目标，又始终达不成，反而会打击到团队的自信心和积极性。

小结

关于系统可用性的衡量，业界通常从时间与请求两个维度入手，二者各有侧重。

时间维度以故障为中心，关注系统中断的持续时长；请求维度则聚焦成功响应比例，能更敏锐地捕捉到日常运行中的抖动与异常。

在SRE实践中，请求维度的方式被更广泛地采用，因为它更能体现系统整体的健康状态——稳定性不仅关乎是否发生故障，更包含运行过程中所有影响体验的偏差。

同时，设定可用性目标需综合考量成本、业务容忍度与系统现状，避免脱离实际追求过高数字，从而在可靠性与投入之间取得可持续的平衡。

设定稳定性衡量标准：SLI与SLO

在上一节“系统可用性”中，我们了解了“衡量系统可用性的2种方式”，这个“确定成功请求条件，设定达成占比目标”的过程，在SRE中就是设定稳定性衡量标准的SLI和SLO的过程。

SLI（Service Level Indicator）服务等级指标：选择哪些指标来衡量我们的稳定性。

SLO（Service Level Objective）服务等级目标：设定的稳定性目标，比如“几个9”这样的目标。

系统可用性	故障时间/年	故障时间/月	故障时间/周	故障时间/天
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秒

SLI就是我们要监控的指标，SLO就是这个指标对应的目标。落地SRE的第一步其实就是“选择合适的SLI，设定对应的SLO”。

对于常见的监控指标来说，CPU使用率、Load值、端口存活状态、HTTP状态码、吞吐率、在线用户数等，从基础系统指标到业务层面的指标，对我们来说好像都很重要，此时该如何衡量呢？

如何衡量SLI

原则一：选择能够标识一个主体是否稳定的指标，其指标本身最好能贴近业务的应用层。

原则二：优先选择与用户体验强相关或用户可以明显感知的指标。

例如，针对 AI 安全敏感词拦截这类以多租户 API 服务为核心的系统，应优先选择对调用方体验强相关、且租户或业务方能够明显感知的服务指标作为 SLI。

如果我们选择系统层的CPU使用率作为指标呢？

假设CPU使用率达到了95%，但是只要CPU处理能力足够，状态码成功率可能还是保持在4个9，时延还是在80ms以内，用户体验没有受到影响。

另外一种情况，假设CPU使用率只有10%，但是可能因为网络超时或中断，导致大量的请求失败，甚至是时延飙升，这个应用的运行状态也不一定是正常的。

所以结论就是，CPU使用率不管是10%还是95%，都不能直接反映业务层面运行是正常还是异常，不适合作为应用运行稳定性的SLI指标。

VALET方法

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

Volume-容量

Volume（容量）是指服务承诺的最大容量是多少。比如，一个应用集群的QPS、TPS、会话数以及连接数等等。如果我们对日常设定一个目标，就是日常的容量SLO，对双11这样的大促设定一个目标，就是大促SLO。

例如对于数据平台，要看它的吞吐能力，比如每小时能处理的记录数或任务数。

Availablity-可用性

Availablity（可用性）代表服务是否正常。比如，前面介绍到的请求调用的非5xx状态码成功率，就可以归于可用性。

Latency-时延

Latency（时延）是说响应是否足够快。这是一个会直接影响用户访问体验的指标。

例如对于任务类的作业，我们会看每个任务是否在规定时间内完成了。

Errors-错误率

错误率有多少？这里除了5xx之外，我们还可以把4xx列进来，因为前面我们的服务可用性不错，但是从业务和体验角度，4xx太多，用户也是不能接受的。

或者可以增加一些自定义的状态码，看哪些状态是对业务有损的，比如某些热门商品总是缺货，用户登录验证码总是输入错误，这些虽不是系统错误，但从业务角度来看，对用户的体验影响还是比较大的。

Tickets-人工介入

是否需要人工介入？如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。

Tickets的SLO可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月20张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。

通过SLO计算可用性

选择了针对SLO合适的SLI后，我们可以多设定几个不同层级的SLO，例如

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

恒等于：Availability = SLO1 & SLO2 & SLO3

只有当这个三个SLO同时达标时，整个系统的稳定性才算达标。

所以对于非第三方提供商的同学来说，上面的计算方法是比较细化的一个方法。

而对于如云厂商的同学，此前的Successful = （状态码非5xx） & （时延 <= 80ms）也就是SLA（ Service Level Agreement）单一衡量方法应该才用的比较多，因为它们要面对的客户群体是非常大的，所以很难跟每一家客户都去制定像SLO这么细粒度稳定性目标。

至此，你可以尝试按照Google提供的规范格式，制定一个自己所负责系统的SLO：Google的SLI和SLO设定模板链接

小结

设定稳定性的具体标准，关键在于将抽象目标转化为可量化、可执行的指标，这正是SLI与SLO的核心价值。

SLI作为衡量服务状态的“仪表盘”，其选取必须直接反映业务运行的健康度，应避免与用户体验脱节的基础指标（如CPU使用率）；SLO则是对SLI所设定明确、可追求的稳定性目标。

总体而言，从SLI选择到SLO设定，是一个将稳定性从概念层落到操作层的过程，它既需要贴近业务本质，也需要在追求高可用与投入成本之间取得务实平衡。

错误预算

定完SLO即目标后，如何指导我们工作呢？

制定出一个允许犯错的次数标准，就监控这些错误就好了，即错误预算。

可以从日常使用的监控平台配置一个Metric就可以实现

在应用错误预算时，通常建议是4个自然周为一个周期，如果这期间错误预算被消耗完了，尽管整个过程中没有出现达到故障标准的问题，这个周期的稳定性要求其实也是不达标的。

所以我们需要把错误预算尽可能直观地表现出来，随时可以看到它的消耗情况。当你和团队成员能够时刻看到还有多少犯错的机会时，对生产系统的敬畏心理也会大大增强。

而且当错误预算消耗到一定比例，如80%或90%时，就要开始预警，控制各种变更，或者投入精力去解决影响稳定性的问题。

特殊情况特殊处理：在考虑定错误预算的时候，还要考虑到部分特殊场景，例如双十一、春晚、突发新闻等访问量激增问题等等，如果这些活动或事件是发生在某个考核周期内，这时要考虑放大错误预算的值，特别是瞬时的错误或失败，应该要有更大的容忍度。

故障定级

我们可以根据错误预算在一次故障事件的消耗量来决定故障等级。

例如，请求成功率SLO对应的错误预算是25,000次，如果一个问题产生的错误请求数超过了5000次，也就是错误预算一下就被消耗掉20%以上，这时我们可以把这次故障定为P2级。

故障等级	单次消耗比例
P0	比例 > 50%
P1	50% >= 比例 > 30%
P2	30% >= 比例 > 20%
P3	20% >= 比例 > 5%
P4	比例 >= 5%

具体数值可以根据实际业务情况和容忍度来制定。

通过错误预算来定义故障等级就可以做到量化，而一旦可以被量化，就意味着可以标准化，有了标准，我们就可以进而推进达成共识。

稳定性共识

当剩余预算充足或未消耗完之前，对问题的发生要有容忍度。

比如，网络抖动或设备瞬时切换导致了极短暂的系统不稳定，但是有极少一部分客户反馈了，也可能领导或业务使用时遇到了，结果技术同学就被投诉系统或业务不稳定，然后就要放下手头的工作去排查问题，后续还要花大量的时间去复盘总结和汇报等等。

如果预算充足，且单次问题并没有造成大量损耗，那么这次问题就不应该被投诉，也不用以高优先级响应，它应该得到容忍的。

当剩余预算消耗过快或即将消耗完之前，SRE有权中止和拒绝任何线上变更。

如果此时的情况已经说明系统稳定出现了很大问题，不能再让它“带病工作”。同样，这时的业务开发团队，也有权拒绝新的需求，他们首要的事情，应该是跟SRE一起解决影响稳定性的问题，直至问题解决，且等到下一个周期有了新的错误预算后，再恢复正常变更节奏。

---

不过，这里涉及到跨团队沟通共识机制。从推行的角度来讲，建立稳定性共识机制一定是Top-Down，也就是自上而下，至少要从技术VP或CTO的角度去推行，而且当有意见不一致的情况出现时，还要逐步上升，直至CTO角度来做决策。一定要自上而下推进周边团队或利益方达成共识。

基于错误预算的告警

日常工作中，作为一线的工程师肯定要接收大量的告警短信，但是这些告警里面很大一部分都是没有实际意义的。为什么这么说呢？因为它们没有行动指导意义，比如CPU使用率80%、成功率低于95%、时延超过80ms等等，这样的告警只是告诉我们有问题、有异常，但是否需要高优先级马上处理，还是说可以先放一放、过一会再处理呢？可能并没有办法判断。

这样的告警，接收的次数多了，就会变成“狼来了”，让一线变得警惕性不高，当故障真的发生时，也没法快速响应。

这就对应着告警收敛：

• 第一个，相同相似告警，合并后发送，比如同一应用集群内同一时间内，同一异常告警，就先合并，对外只发送一条，这种比较简单直接。
• 第二个，基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，比如我们前面提到的，当单次问题消耗的错误预算达到20%或30%等某一阈值时，就意味着问题非常严重了，这种告警信息一旦收到，就要马上做出响应。这样告警数量不多，既达到了收敛效果，又非常精准。

不过该告警就涉及AIOps了，毕竟故障只是刚被监控系统捕捉，还没有形成完整闭环。谷歌基于SLO和错误预算的几种告警算法

那怎么确定SLO推到的错误预算和相应策略是否有效果呢？

衡量SLO的有效性

这里推荐三个维度：

1. SLO达成情况：有”达成”、”未达成”两个指标
2. 人工投入程度：有”高”、”低”两个指标
3. 用户满意度：有”高”、”低”两个指标

组合起来就是八种情况，可以形成一个图表与建议。

SLO达成情况	人工投入程度	用户满意度	建议
达成	低	高	期望的最理想状态，SLO能达成，人工投入又低，客户满意度又很高，也没有特别的优化空间，这时我们就可以增加发布和变更次数，更大程度地释放生产力
达成	低	低	目标达成了，但用户并不满意，说明 SLO 指标选错了，没反映真实体验。建议收紧或重定义 SLO，换成更贴近用户感知的指标
达成	高	高	我们的SLO设定得太容易达成，要么投诉多，要么到处吐槽，没有反馈真实的运行状况，需要收紧SLO
达成	高	低	忙而无功，建议重构 SLO 和告警体系
未达成	低	高	目标定太高，总是达不成，但用户反馈却很不错，这种就会造成错误预算提前消耗完，导致很多变更暂停，产品延期，甚至会做一些无谓的优化，可以放宽SLO
未达成	低	低	既达不到目标，又没人真正投入，用户体验也在下滑，建议收紧 SLO 并加大工程投入，修产品、补自动化，先止血
未达成	高	高	大量人工投入还救不回来体验，说明系统设计或架构有问题。需要收紧 SLO，停止堆人救火，集中时间修根因、做自动化故障缓解。
未达成	高	低	目标定太高，总是达不成，但用户反馈却很好。这会导致错误预算提前消耗完，频繁冻结变更，影响产品节奏，需要放宽SLO

小结

1. 错误预算是通过SLO推导出来的，为了达成SLO，就要尽量减少对它的消耗。
2. 错误预算的警示效果更显著，所以我们通常会围绕它来开展稳定性保障工作。落地错误预算可以遵循一些基本原则，比如要对系统故障或问题有容忍度，在预算消耗过快或消耗殆尽之前，SRE有权踩踩“刹车”，减少或拒绝线上变更等等，这些策略要自上而下达成共识。
3. SLO和错误预算是否合理，基于它们的策略是否有效，我们可以通过SLO达成情况、人肉投入程度和用户满意度三个维度进行评估，进而调整和优化它们。

关于故障定级，不同团队的标准可能不一样，例如有按照故障范围来制定的，使用多个服务，核心服务，网络区域，IDC等来划分等级区间。

告警这块很多都是通过（监控产品本身优化）收敛，聚合等优化，其实还可以通过运营的角度进行优化，通过对告警信息进行多维度的统计分析，为优化指明方向，参考：面对每天过万的告警量，该如何进行优化？

a. 面向SRE的统计分析

• 告警总量趋势：清晰展示每日历史告警总量变化，帮助SRE把握整体告警态势。
• 业务线告警分布：统计各业务线告警数量与占比，指导SRE优先关注告警集中的业务线。
• 服务告警分析：汇总各服务告警情况，便于服务负责人第一时间掌握所属服务状态。
• 主机告警分析：定位是否因个别主机异常导致整体告警量上升，辅助SRE精准排查。
• 层级下钻分析：按业务线→服务→主机→告警类型逐层展开，理清告警构成与根源。

b. 面向监控系统的优化

• 告警类型分布：统计各类告警数量与占比，推动监控负责人关注需调整的监控项或阈值。

c. 面向研发的协同优化

• 研发告警统计：按研发人员汇总其负责项目的告警数量与占比，针对长期告警推动研发参与优化，共同提升系统稳定性。

引用

Google的SLI和SLO设定模板链接

谷歌基于SLO和错误预算的几种告警算法

面对每天过万的告警量，该如何进行优化？