极客时间SRE 实战手册的个人读书笔记

传送门：time.geekbang.org/column/intr…

SRE提出的背景

大大小小的互联网企业为了提升用户价值的交付效率，都在积极采用微服务、容器，以及其他的分布式技术和产品，而且也在积极引入像 DevOps 这样的先进理念。但挑战紧跟着也来了：在引入了这么多先进的技术和理念之后，这种复杂架构的系统稳定性很难得到保障，怎么办？

比如微服务架构下，相比大单体服务有更为复杂的上下游调用关系、更长的调用链路，需要监控的服务指标更多。结合DevOps各服务频繁的变更、发布更需要在稳定性上得到全局的保障。

答案是SRE！

这几年业界对 SRE 的关注越来越多，大家也几乎达成了共识，Google SRE 就是目前稳定性领域的最佳实践。也可以说，SRE 已经成为稳定性的代名词。

SRE到底是什么

研发小哥： SRE 就是一个岗位，而且是一个具备全栈能力的岗位，我们需要一个SRE大神就能解决稳定性问题。
运维小哥：SRE 就是传统运维的升级版，做好监控、做到快速发现问题、快速找到问题根因，把运维自动化做好就行了。
基建小哥：做好 SRE 要加强容量规划，学习 Google 做到完全自动化的弹性伸缩。

上面的说法好像都有道理，但又不全面，实际上：

SRE 是一套体系化的方法，我们也只有用全局视角才能更透彻地理解它。

从职能分工上，SRE 体系的建设绝不是单个岗位或单个部门就能独立完成的，必然要求有高效的跨团队组织协作才可以：

（图：sre 稳定性保障规划图）

这里面很多事情都很常见，比如容量评估、故障演练、服务降级、服务限流、异常熔断、监控告警等等：

像容量扩缩容，必然会与运维团队有交集；如果做得再弹性一些，还需要与监控结合，就要与监控团队有合作；
同时还可能依赖 DevOps 提供持续交付、配置变更，以及灰度发布这些基础能力，就要与开发和效能团队有交集。

SRE 的根本目的：提升稳定性

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

MTBF，Mean Time Between Failure，平均故障时间间隔
- 目标：提升 MTBF，也就是减少故障发生次数
MTTR，Mean Time To Repair，故障平均修复时间
- 目标：降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长

MTTR

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

Pre-MTBF 阶段（无故障阶段）：做好架构设计，提供限流、降级、熔断这些 Design-for-Failure 的服务治理手段，以具备故障快速隔离的条件。
Post-MTBF 阶段：开启新的 MTBF 阶段，我们应该要做故障复盘，总结经验，找到不足，落地改进措施等。
MTTI 阶段：依赖监控系统帮我们及时发现问题，对于复杂度较高和体量非常大的系统，要依赖 AIOps 的能力，提升告警准确率，做出精准的响应。

按照以终为始的思路，SRE 要实现的目标就是“提升 MTBF、降低 MTTR”，从这个角度出发，我们再次认识到一定要把 SRE 作为一个体系化的工程来建设

认识系统可用性

既然SRE的目标是“提升 MTBF、降低 MTTR”，即提升系统稳定性，那么首先需要对系统的可用性有个基本的了解

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

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

	衡量要素	问题
时间维度是从故障角度出发对系统稳定性进行评估	衡量指标，系统请求状态码；衡量目标，非 5xx 占比，也就是成功率达到 95%；影响时长，持续 10 分钟。只有当问题达到一定影响程度才会算作故障，这时才会计算不可用时长，也就是上面公式中的 Downtime。	最显著的问题就是，稳定性只与故障发生挂钩有些故障持续的时间短不被记为故障，但影响频度非常高也是系统不稳定的表现，时间维度的统计不够准确全面。
请求维度从成功请求占比的角度出发，对系统的稳定性进行评估	衡量指标，请求成功率；衡量目标，成功率达到 95% 才算系统运行正常；统计周期，比如一天、一周、一个月等等	这种方式对系统运行状况是否稳定监管得更为严格，不会漏掉任何一次问题的影响，因为它对系统整体运行的稳定性判定。不仅仅会通过单次的异常影响进行评估，还会累计叠加进行周期性的评估。

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

从时间、请求维度衡量系统可用性，其都包含衡量指标、衡量目标、影响时长 / 统计``周期 3大要素，两种算法最后都会落脚到“几个 9”上，系统到底定“几个 9”才符合我们的稳定需求是值得讨论的

成本因素
1. 成本：9 越多稳定性越好，但是相应付出的成本和代价也会更高
2. 要先考虑 ROI（回报率）。这时候就要看企业自身对成本压力的承担情况了。
业务容忍度
1. 对于核心业务或核心应用：成功率越高越好
2. 非核心业务或应用：并不会对业务收入和用户体验造成太大的影响
系统当前的稳定性状况
1. 定一个合理的标准比定一个更高的标准会更重要
2. 一步一步朝着更高的标准迈进。同时，这样做也会更容易落地，因为你如果定一个太高的目标，又始终达不成，反而会打击到团队的自信心和积极性。

SRE是如何衡量可用性的

既然“系统可用性”有两种计算方式：时长维度、成功请求占比，在 SRE 实践中，通常会选择第二种：

Availability = Successful request / Total request

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

SLI & SLO概念

SLI(Service Level Indicator)：服务等级指标，其实就是我们选择哪些指标来衡量我们的稳定性。
SLO(Service Level Objective)：服务等级目标，指的就是我们设定的稳定性目标，比如“几个 9”这样的目标。

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

系统运行状态指标那么多，哪些适合 SLI？

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

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

Volume- 容量	Volume（容量）是指服务承诺的最大容量是多少。比如，一个应用集群的 QPS、TPS、会话数以及连接数等等
Availablity- 可用性	Availablity（可用性）代表服务是否正常。比如请求调用的非 5xx 状态码成功率，就可以归于可用性。
Latency- 时延	Latency（时延）是说响应是否足够快。这是一个会直接影响用户访问体验的指标。注意：不会直接做所有请求时延的平均，因为整个时延的分布也符合正态分布，就要设定不同的置信区间来找出这样的用户占比，有针对性地解决。
Errors- 错误率	可以增加一些自定义的状态码，看哪些状态是对业务有损的，和可用性有差异的是，错误率往往是业务上的错误。
Tickets- 人工介入	如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。例：Tickets 的 SLO 可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月 20 张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。

通过 SLO 计算可用性

明确SLI后就可以开始设定SLO，设定SLO后就需要在实践中计算真实可用性，从而判断SLO是否达成

系统可用性：Availability = Successful request / Total request

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

Successful = （状态码非 5xx） & （时延 <= 80ms）

问题：

对单次请求的成功与否的判定太过死板，容易错杀误判。
1. (比如我们前面讲对于时延，我们一般会设定置信区间，比如 90% 时延小于等于 200ms 这样的场景，用这种方式就很难体现出来。)
对于状态码成功率和时延成功率的容忍度，通常也是也不一样的，通过这种方式就不够准确。

这种方式通常会被利用在第三方提供的服务承诺中，也就是 SLA（ Service Level Agreement），因为这种方式比较简单易判断。

第二种方式，SLO方式计算

如：

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

直接用公式表示：Availability = SLO1 &SLO2 & SLO3

只有当这个三个 SLO 同时达标时，整个系统的稳定性才算达标，有一个不达标就不算达标，这样就可以很好地将 SLO 设定的合理性与最终可用性结合了起来。

错误预算：达成稳定性目标的共识机制

顺着 SLO 这条线继续深入，一起来看有了 SLO 之后，围绕着它我们可以做哪些事情，或者说我们具体应该怎么来应用 SLO 呢？

落地 SLO，先转化为 Error Budget

错误预算其实和驾照记分制是一样的，最大的作用就是“提示你还有多少次犯错的机会”，并且，错误预算的警示效果比看成功率这种统计数据更直观，感官冲击力更强。

(图：通过 SLO 反向推导出来）

如何应用 Error Budget？

稳定性燃尽图

当你和团队成员能够时刻看到还有多少犯错的机会时，对生产系统的敬畏心理也会大大增强。而且当错误预算消耗到一定比例，如 80% 或 90% 时，就要开始预警，控制各种变更，或者投入精力去解决影响稳定性的问题。

故障定级

判定一个问题是不是故障，或者评估问题影响程度到底有多大，除了看影响时长外，还有一个更具操作性的方法，那就是按照该问题消耗的错误预算比例来评判。

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

稳定性共识机制

根据剩余预算的情况，来制定相应的行动措施，来避免我们的稳定性目标，也就是 SLO 达不成。

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

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

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

跟 SRE 一起解决影响稳定性的问题，直至问题解决，且等到下一个周期有了新的错误预算后，再恢复正常变更节奏。

（保障稳定性的行动不是单独某一方就可以完成的，它需要多方共同认可并愿意配合才能真正执行到位。）

一定要自上而下推进周边团队或利益方达成共识。

基于错误预算的告警

相同相似告警，合并后发送
基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，见sre.google/workbook/al…

案例：落地SLO时还需要考虑哪些因素

一个系统的服务依赖关系是很复杂的，我们需要先梳理出核心、非核心链路，在设定系统的SLO时，大的原则就是先设定核心链路的 SLO，然后根据核心链路进行 SLO 的分解。

核心链路：确定核心应用与强弱依赖关系

通过全链路跟踪这样的技术手段找出所有相关应用，也就是呈现出调用关系的拓扑图
确定核心应用是根据业务场景和特点来决定的，基本上需要对每个应用逐个进行分析和讨论。这个过程可能要投入大量的人工来才能完成。

设定 SLO 有哪些原则？

核心应用的 SLO 要更严格，非核心应用可以放宽
强依赖之间的核心应用，SLO 要一致

比如下单的 Buy 应用要依赖 Coupon 这个促销应用，我们要求下单成功率的 SLO 要 99.95%，如果 Coupon 只有 99.9%，是不符合要求的

弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。
Error Budget 策略，核心应用的错误预算要共享

就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的。

（单个应用的错误预算消耗完，都要停止变更，等问题完全解决再恢复变更。）

如何验证核心链路的 SLO？

容量压测

容量压测的主要作用，就是看 SLO 中的 Volume，也就是容量目标是否可以达成。对于一般的业务系统，我们都会用 QPS 和 TPS 来表示系统容量，得到了容量这个指标

容量压测的另一个作用，就是看在极端的容量场景下，验证我们前面说到的限流降级策略是否可以生效。

为什么要做容量压测？

在分布式系统中仅仅靠分析或画架构图是无法暴露出来的，因为业务变更每天都在做，应用之间的调用关系和调用量也在随时发生变化。这时候就需要有容量压测这样的手段来模拟验证，进而暴露依赖关系问题。

Chaos Engineering- 混沌工程

混沌工程是一个非常复杂的系统化工程，因为要在线上制造故障，或多或少都要对线上业务造成影响，如果模拟故障造成的真实影响超过了预估影响，也要能够快速隔离，并快速恢复正常业务。

混沌工程是 SRE 稳定性体系建设的高级阶段，一定是 SRE 体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才会考虑的。

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

错误预算充足就可以尝试：尽量避开错误预算不足的时间段。因为在正常业务下，我们要完成 SLO 已经有很大的压力了，不能再给系统稳定性增加新的风险。
评估故障模拟带来的影响：如果造成的业务影响很大，那就要把引入方案进行粒度细化，分步骤，避免造成不可预估的损失。

（如：选择凌晨，业务量相对较小的情况下做演练）

故障发现：如何建设on-call机制

我们要做的稳定性提升和保障工作，其实就是想办法不要把错误预算消耗完，或者不能把错误预算快速大量地消耗掉。

聚焦 MTTR，故障处理的关键环节

故障处理的环节就是 MTTR，它又细分为 4 个指标：MTTI、MTTK、MTTF 和 MTTV

IBM的统计

MTTK 部分，也就是故障定位部分的时长占比最大。

鉴于网络设备部署模式相对简单，以及日志和报错信息比较固定和明确，所以出现问题时，MTTI 的判定阶段不会花太多时间。

分布式系统的统计

在一个分布式的软件系统下，我们判定一个问题发生在哪儿，影响范围到底是怎么样的，要召集哪些人共同参与定位排查等等，这个反而会消耗更多时间，所以我们看到 MTTI 阶段占比会更重。

当一个分布式系统发生故障时，我们的策略一定不是找到根因，而是优先恢复业务。所以，我们往往是通过故障隔离的方式，先快速恢复业务，也就是我们经常听到的 Design for Failure 这样的策略

MTTI：从发现故障到响应故障

MTTI，就是故障的平均确认时间，也就是从故障实际发生时间点，到触发采取实际行动去定位前的这段时间。

这个环节其实主要有两件事情要做：

第一件事，判断出现的问题是不是故障；
第二件事，确定由谁来响应和召集。

这两件事，其实就是 SRE 里面提到的 On-Call 机制。

判断出现的问题是不是故障

历史问题
- 往往会根据用户投诉，或客服对同一问题的重复反馈来判断。不过，一旦等用户和客服反馈，就说明故障影响已经非常恶劣了，用户也已经处于无法忍受的状态了。
SRE体系的优势
- 搭建了 SRE 体系，设定了 SLO，能对稳定性进行量化管理，那我们就能比用户更快发现问题并响应问题了。至于用户投诉和客服反馈的渠道，只能是作为我们的辅助手段。
谁来响应和召集
- 判定这个问题就是一个故障，首先要有人能判定，接下来需要哪些人来介入，并能够把相关的人员召集起来，一起来处理故障

On-Call 的流程机制建设

确保关键角色在线

不是指一两个值班的运维或 SRE 人员，而是整个产品体系中的所有关键角色。

接收故障告警或第一时间响应故障的，一般是运维、PE 或 SRE 这样的角色，业务开发同事要确保及时响应 SRE 发起的故障应急。

组织 War Room 应急组织

专门处理故障的“消防群”（暗含着灭火的意思），会将这些关键角色纳入其中，当有故障发生时会第一时间在消防群通报，这时对应的 On-Call 同事就要第一时间最高优先级响应呼叫（Page）

建立合理的呼叫方式

我们建议使用固定的 On-Call 手机，建立手机与所有 On-Call 系统的对应关系，比如这个手机号码对应交易核心应用，另一个号码对应 IDC 机房运维等等。

（或者说自动拉值班人和服务owner入群）

无论是 SRE、架构师，还是一线开发，熟悉某个系统的最快最好的方式就是参与 On-Call，而不是看架构图和代码。

确保资源投入的升级机制

SRE 或运维可以直接上升到自己的主管或相关主管那里，要求上级主管协调资源投入。必要时，还可以上升到更高级主管，甚至 CTO 或技术 VP 来关注

与云厂商联合的 On-Call

现在企业上云是大势所趋，绝大多数情况下，我们对问题和故障的处理，是离不开与云产品工程师一起高效联动的。

其它分享

谷歌SRE应急事件处理策略有一条是：由万（全）能工程师解决生产问题向手持“运维手册”的经过演练的on-call工程师演进，核心思路是建设故障处理SOP（Standard Operating Procedure），保证SRE可以处理大多数故障。
先要有on-call机制，因为问题反馈的渠道不一定只要监控，可能还有用户投诉、同事反馈等等，当遇到这些问题时，也需要有高效的响应机制。而且在早期，有可能监控并不准确，反而是其它渠道的反馈占比更高。
变更是“万恶之源”，所以人员不容易聚集的情况下，尽量避免变更是合理的策略。
对于发生的问题或故障，要有分级才可以，不然啥问题过来都要立即马上处理，这种对oncall的同事来说，压力过大。

故障处理：一切以恢复业务为最高优先级

在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级。这也是我们故障处理过程中的唯一目标，没有第二个。

导致故障蔓延的常见问题

故障隔离手段缺失

没有提前考虑到对应的故障隔离手段，比如有效的限流、降级和熔断。如果这些措施不具备，从技术层面其实已经很难采取有效的手段了

反思：是不是业务模型评估得不够准确？在 Design-For-Failure 的高可用设计上做得不够？

关键角色和流程机制缺失

没有一个共同决策和反馈的机制。抛开态度，单从结果上讲就是忙中添乱，导致出现更为严重的衍生故障。

没有演练

担心演练有可能也会影响正常业务，但这也侧面说明我们的技术方案仍然不够成熟和完善

整个应急流程基本跑不起来，要么是人凑不齐，要么是很多团队不愿意配合，只要是这种理由导致的无法演练，基本出现故障后，整个应急状态就是失控的

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

当一个问题被定性为故障，这时我们就要成立 War Room

关键角色分工

Incident Commander，故障指挥官，简称为IC

这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行。

Communication Lead，沟通引导，简称CL

负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA 或者是某个 SRE 来承担都可以，但是要求沟通表达能力要比较好。

Operations Lead，运维指挥，简称OL

负责指挥或指导各种故障预案的执行和业务恢复。

Incident Responders，简称 IR

所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的

流程机制

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

反馈机制

没有进展也是进展，也要及时反馈

为了尽量减少对执行者的干扰，让执行者能够更聚焦，我们一般要求团队 Leader 来收集反馈并传递 IC 的指令
除了要做好怎么快速恢复业务，信息同步的及时和透明也非常关键，并且有些安抚措施必须要快速执行到位。
一定不是用技术术语，而是以尽量业务化的语言描述，并且要给到对方大致的预期
有些事项比如反馈信息的模板，对外通报的模板都要提前建立好，每个角色只要按照模板填写内容即可，可以极大地保证沟通效率。

总结

故障处理过程中效率如何，其实取决于三个因素：技术层面的故障隔离手段是否完备；故障处理过程中的指挥体系是否完善，角色分工是否明确；故障处理机制保障是否经过足够的演练。

故障复盘：黄金三问与判定三原则

故障根因不止一个，与其争论根因是什么，不如一起看看引起故障的原因都有哪些，是不是都有改进的空间。

结合 Timeline 来做，也就是按照 MTTI、MTTK、MTTF 和 MTTV 先做一个分类；然后针对耗时长的环节，反复讨论改进措施是什么；最后定好责任人和时间点，后续持续跟进执行状况。

我们总结出来的故障复盘黄金三问：

第一问：故障原因有哪些？

第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？

第三问：当时如果我们做了什么，可以用更短的时间恢复业务？

会议主持者这个角色，一般情况下，跟我们上一讲提到的 CL（Communication Lead）

故障判定的三原则

明确到底应该由谁来承担主要的改进职责（而不是定责）

健壮性原则

每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等

如果应用因为抖动而失败、无法自愈，这种情况，业务应用就不能以服务器或网络故障为理由，不承担改进职责。

（核心应用对非核心应用的依赖必须要有降级和限流手段。如果因为非核心应用的故障或者瞬时高并发访问，导致核心应用故障，这种情况下，主要的改进责任在核心应用，非核心应用只需要配合改造。）

第三方默认无责

如果使用到了第三方的服务，如公有云的各类服务，包括 IaaS、PaaS、CDN 以及视频等等，我们的原则就是默认第三方无责。

默认第三方无责，稳定性责任一定是内部角色承担，这样做有时看起来虽然不太合理，但这样做的目的，就是让内部意识到稳定性和高可用一定是我们自己的责任，决不能依赖任何一个第三方。

分段判定原则

当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们会将一次故障分段判断，这样分段判定会让故障问题更聚焦，改进措施也会更有针对性。

“故障是系统运行的常态，正常才是特殊状态”。所以，你无论作为什么角色，一定要以一颗平常心来对待故障，能做到这个程度不容易，这就需要我们更加辩证地看待故障，我们一定要做到鼓励改进，而不是处罚错误。

互联网典型的SRE组织架构是怎样的？

高效的故障应对和管理工作，其实是需要整个技术团队共同参与和投入的。

落地 SRE 必须调整组织架构吗？

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

组织架构要与技术架构相匹配

技术架构实现组织目标，组织架构服务并促成技术架构的实现

SRE 是微服务和分布式架构的产物

正是因为分布式技术的复杂性，特别是在运维层面的超高复杂性，才产生了对传统运维模式和理念的冲击和变革。

不仅仅是 SRE 和 DevOps，就连容器相关的技术，持续交付相关的方法和理念，也是在微服务架构不断流行的趋势下所产生的，它们的产生就是为了解决在这种架构下运维复杂度过高的问题。

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

现实情况就是，基本所有的 SRE 经验都是基于微服务和分布式架构的，也都是在这样一个基础下产生的

蘑菇街的 SRE 组织架构实践

基础设施层：为 IaaS 层，主要是以资源为主，包括 IDC、服务器、虚拟机、存储以及网络等部分。
技术中台：使用到的各种分布式部件，如缓存、消息、数据库、对象存储以及大数据等产品，这一层最大的特点就是“有状态” ，也就是要存储数据的产品。
业务中台层：将具有业务共性的产品能力提炼出来，比如用户、商品、交易、支付、风控以及优惠等等，上面支撑的是业务前台应用。
业务前台：以阿里的产品体系来举例，可以类比为淘宝、天猫、盒马、聚划算这样的业务产品。

业务中台和前台的运维职责

通常就是我们常说的应用运维、PE (Production Engineer) 或者叫技术运营这样的角色来承担。

PE 这个角色与 Google 定义的 SRE 所具备的能力，最大差别就在于国内 PE 的软件工程能力有所缺失或相对较弱。这就导致很多基于技术中台的自动化工具、服务治理以及稳定性保障类的平台没办法自己研发，需要由另外一个团队来支撑和弥补

技术保障平台

这部分的能力一定基于技术中台的能力之上生长出来的，是技术中台的一部分，如果脱离了这个架构体系，这个技术保障体系是没有任何意义的。

工具平台团队（效率）
- 负责效能工具的研发，比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，为基础运维和应用运维提供效率平台支持。
稳定性平台团队
- 负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划。

运维职责

传统运维：基础设施和接入层的 4 层负载部分
PE：业务中台、业务前台以及接入层的 7 层负责均衡；技术中台如果自研，也就是我们常说的中间件团队，开发同学自己负责对应的工作，如果上云，则由 PE 负责
工具平台团队：效能工具的研发
稳定性平台团队：稳定性保障相关的标准和平台

总结

SRE 并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队

SRE= PE + 工具平台开发 +稳定性平台开发

都有哪些高效的SRE组织协作机制？

以赛带练

选择类似的真实且具备高压效果的场景，来充分暴露我们的稳定性存在哪些问题和薄弱点，然后有针对性地进行改进。

一定要先考虑自己的业务系统应对的极端场景到底是什么，然后基于这些场景去设计和规划。

SRE 的各个角色如何协作？

大促项目开工会

明确业务指标，指定大促项目的技术保障负责人
明确技术团队的分工以及各个团队的接口人，然后根据大促日期，倒排全链路压测计划

业务指标分解及用户模型分析评审会

PE 是要负责一整条核心链路上的应用的，所以 PE 可以识别出更全局的链路以及整条链路上的容量水位情况
业务开发往往只专注在某几个应用上，所以他可以把业务目标拆解得更细致，并转化成 QPS 和 TPS 容量要求

PE 会更多地从全局角度关注线上真实的运行状态，而业务开发则根据这些信息做更细致的分析，甚至是深入到代码层面的分析。

应急预案评审会

PE 与业务开发配合，针对核心链路和核心应用做有针对性的预案讨论。

PE 更多地是负责平台级的策略
业务开发则要更多地考虑具体业务逻辑上的策略

容量压测及复盘会

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

压测过程中和每次压测结束后，都要不断地总结和复盘，然后再压测验证、扩容和调优，直至容量和预案全部验证通过。

PE 更加关注线上整体的运行状态，所以视角会更全局一些
业务开发则更关注自己负责的具体应用，以及深入到代码层面的分析工作

赛场上的哪些工作可以例行化？

核心应用变更及新上线业务的稳定性评审工作

PE 会跟业务开发一起评估变动的影响，比如变动的业务逻辑会不会导致性能影响，进而影响容量；对于新增加的接口或逻辑，是否要做限流、降级和熔断等服务治理策略。

周期性技术运营工作

关注错误预算的消耗情况，每周或每月输出系统整体运行报表，并召集业务开发一起开评审会，对变化较大或有风险的 SLO 重点评估，进而确认是否要采取改进措施或暂停变更

强调 PE 从全局角度关注系统，除了稳定性，还可以关注资源消耗的成本数据，在稳定和效率都有保证的前提下，也能够做到成本的不断优化

完整了解SRE 概念 - 读书笔记