五一假期学习总结：从DevOps到SRE
五一假期学习总结：从DevOps到SRE
大家好，我是Edison。
五一假期，没出远门，带娃露营玩水玩沙骑平衡车，累的不亦乐乎。同时，也刷了一门极客时间的课程《SRE实战总结》，给我带来了一些新的认知，我将这些认知整理了以下，特此总结分享与你，强烈建议已经实践了DevOps的童鞋了解一下SRE。
什么是SRE？
SRE全称Site Reliability Enginering，站点稳定性工程。站在不同角色人员的角度会有不同的认知和解读，但从中立和全局角度来看，SRE其实和PMBOK（项目管理PMP认证的教材）一样提供的是一套体系化的方法，这套方法可以帮助我们保障我们的IT系统的稳定性，进而交付更大的用户价值。
既然是体系化，就得有一系列的规划和措施，下面这张图可能是课程中最大的亮点：
对，这张图就像是PMBOK中的五大过程组和49个子过程一样的存在，用于标准化的指导我们的保障工作全旅程。可以看到，这个所谓的框架图，里面很多的事情其实我们已经在做了，还有些没有做，不过他们也都还比较常见。但是，一旦它们结合起来形成一套稳定的体系，这套体系发挥出的力量就大了，也会告别只发挥某项技术的能力。因此，可以看出：SRE的建设需要高效的跨团队组织协作，而不是依赖单一岗位解决所有稳定性问题。
做SRE的目的是什么？
做SRE的目的，从本质上来看，其实就是 减少系统故障时间，增加系统正常运行时间。换句话说，就是“减少故障，提升MTBF；同时，提升故障处理效率，降低MTTR”。SRE要做的所有事儿，其实都是围绕这两个目标来服务的。
NOTE：从业界稳定性通用的衡量标准看，有两个非常关键的指标：
- MTBF，Mean Time Between Failure，平均故障时间间隔。
- MTTR，Mean Time To Repair， 故障平均修复时间。
通俗地说，MTBF 指示了系统正常运行的阶段，而 MTTR 则意味着系统故障状态的阶段。
SRE和DevOps有什么区别？
DevOps 核心是做全栈交付，SRE 的核心是稳定性保障，关注业务所有活动，两者的共性是都使用软件工程解决问题。
DevOps 的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频地迭代来满足市场需求，抢占市场（产品的迭代是关乎一整条交付链的事），高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，运维必须开启 DevOps 来实现全栈交付。因为不断的迭代交付（也就是俗称的变更）是触发故障、非稳定性的根源，而对于互联网产品来说，服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE 由此诞生。
DevOps 的出发点是“更加高效地交付用户价值”，而 SRE 的出发点是“保障和提升系统稳定性”，两者要做的事情其实本质上差别不大，但是角度不同，那么在执行的时候，要解决的问题也就会有所差异。
实践SRE的切入点是什么？
SRE涉及的范围很大，我们应该从哪里入手呢？
首先，要明确 SRE 关注的稳定性是系统的整体运行状态，而不仅仅只关注故障状态下的稳定性，在系统运行过程中的任何异常，都会被纳入稳定性的评估范畴中。因此，SRE 会更多地采用请求维度的统计方式，即 Availability = Successful request / Total request，而我们常见的系统可用性的几个9就是基于这个维度的一个可量化的实现：
其次，要切入SRE，推荐的做法就是“选择合适的SLI，设定对应的SLO”。例如，“状态码为非 5xx 的比例”就是 SLI，“大于等于 99.95%”就是 SLO。换句话说，SLO 是 SLI 要达成的目标。
NOTE：SLI 就是我们要监控的指标，SLO 就是这个指标对应的目标。
常见的SLI即系统监控指标如下图所示：
常见的SLO的计算方式如下：
- 第一种：直接根据成功的定义来计算
- 比如：Successful = （状态码非 5xx） & （时延 <= 80ms）
- 第二种：复合定义来计算
- SLO1：99.95% 状态码成功率
- SLO2：90% Latency <= 80ms
- SLO3：99% Latency <= 200ms
- Availability = SLO1 & SLO2 & SLO3 => 即只有当这3个SLO同时达标，整个系统的稳定性才算达标。
当设计定好了这些指标，在实践SRE时最重要的方法就是“以赛代练”，即通过事先考虑自己的业务系统的极端场景到底是什么，然后基于这些场景去设计和规划。而这些“以赛带练”的事情，会有一部分转化为例行工作，同时还会增加一些周期性的工作。
如何处理故障的发现、处理 和 复盘？
对于线上故障的处理实践中，耗时最多的就是故障的发现阶段。要提高故障发现的效率，就得建设好On-Call机制。老师在课程中分享了一个On-Call关键5步法：
- 确保关键角色在线；
- 组织 War Room 应急组织；
- 建立合理的呼叫方式；
- 确保资源投入的升级机制；
- 与云的联合 On-Call。
而对于故障的处理，只有一条基本原则：“一切处理活动皆以恢复业务为最高优先级”。故障处理过程中效率如何，其实取决于三个因素：
- 技术层面的故障隔离手段是否完备；
- 故障处理过程中的指挥体系是否完善，角色分工是否明确；
- 故障处理机制保障是否经过足够的演练。
可以看到，想要真正高效处理故障，并不是在技术层面做到完备就可以了，这的确是一个需要体系化建设和反复磨炼才能达成的目标。 如果只处理故障，不对故障复盘也是不行的。而要做好复盘，我们可以通过黄金三问 和 故障判定三原则。
故障复盘黄金三问：
- 第一问：故障原因有哪些？
- 第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
- 第三问：当时如果我们做了什么，可以用更短的时间恢复业务？
具体开复盘会时，我们应该围绕这三个问题来进行，不允许出现互相指责和埋怨的情况，如果出现，会议主持者需要及时控制和打断！
故障判定三原则：
- 健壮性原则
- 业务应用需要提高快速恢复能力
- 第三方默认无责任原则
- 比如云厂商的各类CDN、OSS等服务
- 分段判定性原则
- 将一次故障分段判断，各自完善改进措施
来自《Google SRE运维解密》的经典名句：“故障是系统运行的常态，正常才是特俗状态”。对于我们而言，无论什么角色，都要以一颗平常心来对待故障，鼓励改进，并持续改进。
实践SRE也是在革新生产协作关系
高效的故障应对和管理工作，其实是需要整个技术团队共同参与和投入的。那么这也就必然涉及到生产协作关系的革新，换据说说就是组织架构的调整，这是因为：
- 组织架构需要和技术架构相匹配
- SRE是微服务和分布式架构的产物
如果我们去梳理一下整个软件架构发展的历程，就可以得到下面这张图。我们会发现不仅仅是 SRE 和 DevOps，就连容器相关的技术，持续交付相关的方法和理念，也是在微服务架构不断流行的趋势下所产生的，它们的产生就是为了解决在这种架构下运维复杂度过高的问题。
总的来说，如果我们的技术架构朝着微服务和分布式的方向演进，那我们可以考虑落地 SRE，这时候，我们的组织架构就要匹配我们的技术架构，也就是说，要想在组织内引入并落地 SRE 这套体系，原有技术团队的组织架构，或者至少是协作模式必须要做出一些变革才可以。
蘑菇街的SRE组织架构实践
老师在课程中分享了蘑菇街的SRE组织架构实践，如下图所示。可以看到，SRE 并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队。
参考资料
极客时间，赵成，《SRE实战总结》