My Github

五一假期学习总结:从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实战总结

推荐学习

Microsoft Learn,《制定站点可靠性工程(SRE)策略

 

posted @ 2024-05-06 08:30  EdisonZhou  阅读(109)  评论(0编辑  收藏  举报