这种复杂架构的系统稳定性很难得到保障，怎么办？
SRE 要做的事情并不神秘，我们每天做的监控告警、运维自动化、故障处理和复盘等工作，就是 SRE 的一部分
SRE 到底是什么？能帮助我们解决什么问题？
SRE 涉及范围如此之大，我们应该从哪里入手建设呢？ （完善监控、告警体系、制定系统稳定性指标和规范）
引入SRE 之后，团队能力如何提升？组织架构如何匹配？
SRE 的要求这么高，如何提升个人能力以达到 SRE 的要求？
SRE 体系化 ![[Pasted image 20221125084919.png]]
从职能分工上，SRE 体系的建设绝不是单个岗位或单个部门就能独立完成的，必然要求有高效的跨团队组织协作才可以。
如果严格遵循 Google 的要求，SRE 岗位对技术要求是非常高的。只有具备了全面的技术能力，拥有了全局架构的思维，你才会在 SRE 的道路上走得更远。
稳定性的衡量标准 MTBF，Mean Time Between Failure，平均故障时间间隔。 MTTR，Mean Time To Repair， 故障平均修复时间。
提升 MTBF，降低 MTTR
第一，我们需要从全局的角度去理解 SRE。 SRE 一定是靠整个技术和组织体系发挥作用的，单纯从某个技术点或环节出发，都无法呈现出效果，也就是说 SRE 一定要从全局考虑，体系一定要“配套”。
第二，SRE 的目的，本质上是减少故障时间，增加系统正常运行时间，也就是 “减少故障，提升 MTBF；同时，提升故障处理效率，降低 MTTR”。SRE 要做的所有事儿，都是为这两个目标服务的。
SRE是 用软件工程的方法重新设计和定义运维。
DevOps主要是以驱动价值交付为主，搭建企业内部的功效平台。
SRE主要需要协调多团队合作来提高稳定性。 例如：
- 与开发和业务团队落实降级
- 在开发和测试团队内推动混沌工程落地
- 与开发团队定制可用性衡量标准
- 与开发，测试，devops，产品团队，共同解决代码质量和需求之间的平衡问题。
目前业界有两种衡量系统可用性的方式，一个是时间维度，一个是请求维度，
时间维度：Availability = Uptime / (Uptime + Downtime) 请求维度：Availability = Successful request / Total request
请求维度的系统可用性同样包含三个关键要素， 第一个衡量指标，请求成功率； 第二个衡量目标，成功率达到 95% 才算系统运行正常； 第三个是统计周期，比如一天、一周、一个月等等， 我们是在一个统计周期内计算整体状况，而不是看单次的。
设定系统稳定性目标要考虑的 3 个因素
- 成本因素 （ROI 回报率）
- 业务容忍度 （金融支付要求很高）
- 系统当前的稳定性状况 （定一个合理的标准比定一个更高的标准会更重要）
SLI Service Level Indicator 服务等级指标 SLO Service Level Objective 服务等级目标
![[Pasted image 20221125092121.png]]
快速识别 SLI 指标的方法：VALET
Volume- 容量Volume（容量）是指服务承诺的最大容量是多少。 比如，一个应用集群的 QPS、TPS、会话数以及连接数等等，如果我们对日常设定一个目标，就是日常的容量 SLO，对双 11 这样的大促设定一个目标，就是大促 SLO。对于数据平台，我们要看它的吞吐能力，比如每小时能处理的记录数或任务数。
Availablity- 可用性Availablity（可用性）代表服务是否正常。 比如，我们前面介绍到的请求调用的非 5xx 状态码成功率，就可以归于可用性。对于数据平台，我们就看任务的执行成功情况，这个也可以根据不同的任务执行状态码来归类。
Latency- 时延Latency（时延）是说响应是否足够快。
这是一个会直接影响用户访问体验的指标。对于任务类的作业，我们会看每个任务是否在规定时间内完成了。
讲到这里，我要延伸下，因为通常对于时延这个指标，我们不会直接做所有请求时延的平均，因为整个时延的分布也符合正态分布，所以通常会以类似“90% 请求的时延 <= 80ms，或者 95% 请求的时延 <=120ms ”这样的方式来设定时延 SLO，熟悉数理统计的同学应该知道，这个 90% 或 95% 我们称之为置信区间。
因为不排除很多请求从业务逻辑层面是不成功的，这时业务逻辑的处理时长就会非常短（可能 10ms），或者出现 404 这样的状态码（可能就 1ms）。从可用性来讲，这些请求也算成功，但是这样的请求会拉低整个均值。
同时，也会出现另一种极端情况，就是某几次请求因为各种原因，导致时延高了，到了 500ms，但是因为次数所占比例较低，数据被平均掉了，单纯从平均值来看是没有异常的。但是从实际情况看，有少部分用户的体验其实已经非常糟糕了。所以，为了识别出这种情况，我们就要设定不同的置信区间来找出这样的用户占比，有针对性地解决。
Errors- 错误率
错误率有多少？这里除了 5xx 之外，我们还可以把 4xx 列进来，因为前面我们的服务可用性不错，但是从业务和体验角度，4xx 太多，用户也是不能接受的。或者可以增加一些自定义的状态码，看哪些状态是对业务有损的，比如某些热门商品总是缺货，用户登录验证码总是输入错误，这些虽不是系统错误，但从业务角度来看，对用户的体验影响还是比较大的。
Tickets- 人工介入
是否需要人工介入？如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。举一个我们常见的场景，数据任务跑失败了，但是无法自动恢复，这时就要人工介入恢复；或者超时了，也需要人工介入，来中断任务、重启拉起来跑等等。
Tickets 的 SLO 可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月 20 张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。
![[Pasted image 20221125093033.png]]
Availability = SLO1 & SLO2 & SLO3