DevOps-SRE网站可靠性保障图
近段时间西安由于疫情严重导致西安一码通连续几次崩溃，导致一些工程师无法扫码而进不到小区内维修设备，大量市民无法乘坐地铁和出租车，进不了公司和商厦，甚至有家都不能回。
造成一码通崩溃的主要原因还是由于西安疫情暴增导致大量市民日常出行需要访问和使用一码通，一码通后台服务器扛不住突然暴增的流量而导致服务器宕机，同时没有一套完善的服务器扩容机制，导致恢复后没多久又崩溃了，最后连西安大数据局局长都被停职！
今天我们从网站的可靠性保障工程的角度来聊聊“西安一码通”应该如何来保障系统的稳定性。
SRE是什么？
谈到网站的可靠性保障就离不开一个词SRE，它的全称是Site Reliability Engineer (网站可靠性工程师)。
SRE不单单是一个岗位，而是一个体系化的工程。我们需要学习各项技术，诸如：容量评估、故障演练、服务降级、服务限流、异常熔断、监控告警等等，然后将这些技术有机地结合起来，形成一套稳定的体系。同时需要与开发团队、运维团队、测试团队、效能团队等等，进行高效的跨团队组织协作，并最终提高系统的稳定性。
SRE的概念最早是Google提出来的，他们出了一本书《Site Reliability Engineering》 ，描述了这个套体系化工程是如何高效协同工作的。
系统稳定性衡量指标
我们要提高系统的稳定性，就要制定衡量系统稳定性的相关指标，系统的稳定性指标主要有以下两个：
MTBF，Mean Time Between Failure，平均故障时间间隔
MTTR，Mean Time To Repair， 故障平均修复时间
MTTR又可以分为四个小指标，分别是：
MTTI：发现问题的时间
MTTK：找到问题原因的时间
MTTF：解决问题的时间
MTTV：验证问题是否已解决的时间
我们要想提升稳定性，就会有两个方向：
提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长；
降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长
SRE的目的是什么？
减少故障，提升 MTBF；同时，提升故障处理效率，降低 MTTR。
SRE稳定性保障规划
从上图可以看到针对于网站的可靠性保障我们可以做到的几个方面：故障预防、故障发现、故障定位、故障恢复、故障改进；其目的是提升MTBF，降低MTTR。
如何衡量系统的可用性？
衡量系统可用性的 2 种方式
时间维度：Availability = Uptime / (Uptime + Downtime)
请求维度：Availability = Successful request / Total request
测量和判断方法
时间维度
衡量指标：比如状态码
衡量目标：达到什么目标是正常，达不到就是异常
影响时长：比如持续超过 12 小时
请求维度
衡量指标：请求成功率
衡量目标：成功率达到 95% 才算系统运行正常
统计周期：比如一天、一周、一个月等等
上图为系统稳定性的几个9以及对应的描述。
对于系统稳定性到底定“几个9”？应从三方面考虑
成本因素
业务容忍度
系统当前的稳定性状况
SRE切入点
在一个系统中，我们该如何切入SRE可靠性保障工程呢？
先了解两个概念：
SLI，Service Level Indicator：服务等级指标
SLO，Service Level Objective：服务等级目标
SLI就用来判断系统稳定性的指标，比如接口请求状态码是非500的比例
SLO就SLI要达成的目标，比如接口请求状态码是非500的比例要达到99.95%
SRE应该如何选择SLI？
两个原则
原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
原则二：针对电商这类有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。
VALET方法
Google推荐使用的方法。
Volume- 容量
服务承诺的最大容量是多少
Availablity- 可用性
代表服务是否正常
Latency- 时延
错误率有多少？
Errors- 错误率
错误率有多少？
Tickets- 人工介入
是否需要人工介入？
如何通过 SLO 计算可用性？
非常简单，比如我们选择了三个SLO：
SLO1：99.95% 状态码成功率
SLO2：90% Latency <= 80ms
SLO3：99% Latency <= 200ms
那么可用性就是：
Availability（可用性） = SLO1 & SLO2 & SLO3
错误预算（Error Budget）
什么是错误预算呢？其实就是可以犯错误的次数。我们要落地SLO，应该先将其转换为Error Budget。
如何计算错误预算？
假设在 4 周的时间，这个应用所有的请求次数是 4,653,680，按照给出的 SLO 反向推导，就可以得到容许的错误次数，这就是错误预算。
例如：99.95%Availability，则错误预算就等于4,653,680 * 0.05%=23268
在SRE实践中如何应用错误预算？
稳定性燃尽图
制定好错误预算后SRE需要严格遵守它，所以我们需要把错误预算尽可能直观地表现出来，随时可以看到它的消耗情况。当你和团队成员能够时刻看到还有多少犯错的机会时，对生产系统的敬畏心理也会大大增强。而且当错误预算消耗到一定比例，如 80% 或 90% 时，就要开始预警，控制各种变更，或者投入精力去解决影响稳定性的问题。
设定四个自然周内看看错误预算还剩下多少来评定这个周期的稳定性要求是否达标。
故障定级
将故障等级设置为 P0~P4 这么 5 个级别，P0 为最高，P4 为最低。
稳定性共识机制
当错误预算处于不同状态时，一般都会采取哪些常见措施呢？
第一，剩余预算充足或未消耗完之前，对问题的发生要有容忍度。
第二，剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更。
基于错误预算的告警
第一个，相同相似告警，合并后发送，比如同一应用集群内同一时间内，同一异常告警，就先合并，对外只发送一条，这种比较简单直接。
第二个，基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，比如我们前面提到的，当单次问题消耗的错误预算达到 20% 或 30% 等某一阈值时，就意味着问题非常严重了，这种告警信息一旦收到，就要马上做出响应。这样告警数量不多，既达到了收敛效果，又非常精准。
如何衡量 SLO 的有效性？
SLO 达成情况。我们用达成（Met），或未达成（Missed）来表示。
“人肉”投入程度。英文表示为 Toil，这里用形象一点的“人肉”投入作为它的译意，泛指需要大量人工投入、重复、繁琐且没有太多价值的事情。我们用投入程度高（High）和低（Low）来表示。
用户满意度。英文就是 Customer Satisfaction，可以理解为用户感受和体验如何。这个信息可以通过真实和虚拟渠道获得。真实渠道如客服投诉、客户访谈和舆情监控获取；虚拟渠道如真机模拟拨测。我们用满意度高（High）和低（Low）来表示。
总共 3 个维度，每个维度有 2 种情况，组合起来就是 8 种情况。
落地SLO还需要考虑的因素
1.梳理出系统的核心核心链路以及核心应用，以及这些应用之间的强弱关系。
针对核心和非核心应用，以及强弱依赖关系，我们在设定 SLO 时的要求也是不同的，具体来说，可以采取下面 4 个原则。
第一，核心应用的 SLO 要更严格，非核心应用可以放宽。
第二，强依赖之间的核心应用，SLO 要一致。
第三，弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。
第四，Error Budget 策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的
2.通过容量压测和混沌工程来验证核心链路的SLO是否达成。
故障发现：如何建设On-Call的流程机制
1.确保关键角色在线。
关键角色是指整个产品体系中的所有关键角色。
2.组织 War Room 应急组织。
有专门处理故障的“消防群”（暗含着灭火的意思），会将这些关键角色纳入其中，当有故障发生时会第一时间在消防群通报，这时对应的 On-Call 同事就要第一时间最高优先级响应呼叫（Page）。如果是工作日，对于严重故障，会立刻组织成立 War Room，责任人会马上聚到一起；如果是非工作时间，则会通过电话会议的方式拉起虚拟 War Room。
3.建立合理的呼叫方式。
使用固定的 On-Call 手机，建立手机与所有 On-Call 系统的对应关系，比如这个手机号码对应交易核心应用，另一个号码对应 IDC 机房运维等等。这样我们在 On-Call 时就不再找具体的哪个人，而是手机在谁手中，谁就承担 On-Call 职责。除非问题迟迟得不到解决，或者遇到了疑难杂症，这种时候再呼叫其他同事参与进来。
4.确保资源投入的升级机制。
要给到运维和 SRE 授权，当他发现问题不是自己或现有 On-Call 人员能解决的时候，他有权调动其他必要资源投入。
5.与云厂商联合的 On-Call。
做好与云厂商之间的协作磨合，联合故障演练，必要的授权等等
故障处理：一切以恢复业务为最高优先级
故障响应有两个方面：技术方面和流程方面，这里主要讲一下流程方面该如何应对
流程主要有：
1.War Room（应急作战指挥室）：真实的会议室办公或者虚拟群组
2.关键角色分工
Incident Commander，故障指挥官，简称为 IC
这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行。
Communication Lead，沟通引导，简称 CL
负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA 或者是某个 SRE 来承担都可以，但是要求沟通表达能力要比较好。
Operations Lead，运维指挥，简称 OL
负责指挥或指导各种故障预案的执行和业务恢复
Incident Responders，简称 IR
就是所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，比如具体执行的 SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是 QA 等。
客服、PR 以及商家和其它各类合作代表
对客户进行必要的安抚措施
故障响应流程机制
3.沟通反馈机制
以团队为单位，每隔 10～15 分钟做一次反馈，反馈当前处理进展以及下一步 Action，没有进展也是进展，也要及时反馈。
故障复盘：黄金三问与判定三原则
黄金三问
第一问：故障原因有哪些？
第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
第三问：当时如果我们做了什么，可以用更短的时间恢复业务？
故障判定的三原则
1. 健壮性原则。
这个原则是说每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等。
2. 第三方默认无责。
如果使用到了第三方的服务，如公有云的各类服务，包括 IaaS、PaaS、CDN 以及视频等等，我们的原则就是默认第三方无责。
3. 分段判定原则。
这个原则主要应用在情况比较复杂的场景。当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们会将一次故障分段判断。
“故障是系统运行的常态，正常才是特殊状态”。
所以，你无论作为什么角色，一定要以一颗平常心来对待故障，能做到这个程度不容易，这就需要我们更加辩证地看待故障，我们一定要做到鼓励改进，而不是处罚错误。
---end---
我是Seven，一个不懈努力的程序猿，希望本文能对你有所裨益
