围绕故障管理谈SRE体系建设学习总结

行云流水
2023-07-17 / 0 评论 / 537 阅读 / 正在检测是否收录...

前言

SRE是一个体系化的工程,SRE体系的建设涉及的内容繁多,比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等。故障是众多事项的一个交汇点。

SRE的工作职责

稳定性建设

度量稳定性

在业界我们通常用MTBF和MTTR这两个关键指标来衡量稳定性,这两个指标分别是「平均故障时间间隔」(Mean Time Between Failure)、「平均故障修复时间」(Mean Time To Repair)。

设定稳定性目标

提高MTBF,降低MTTR

提升稳定性

MTTR的指标被细化之后,我们的目标也就变成了降低这些细化之后的指标;我们可以分而治之、各个击破。

故障管理

故障管理分为故障前、故障中和故障后,在每个环节都有一些核心的工作内容和目标。

故障前

关键内容:监控覆盖、架构设计、容量评估、灾备预案、灾备演练、还有持续交付。

监控覆盖的话比较容易理解,服务上线后,只有拥有足够的监控手段,并且尽可能多的覆盖服务的各个环节,才有可能在后面发生问题的时候,快速的感知到。

架构设计
架构设计可能会更偏业务侧一些。我们在故障之前,要尽可能做好服务的架构设计,同时在做一些预案之前,也要把服务架构做好梳理。只有当我们把服务的架构了然于胸,才更有可能在故障发生的时候从容不迫,更好地定位问题。
要更多去加入柔性设计,也就是说你的服务要具备一些像降级熔断、故障隔离这些手段,要有这样的柔性设计在里边。这样架构可以提供这些能力,后面才能更好地去做服务的保障。
再有一点就是,要尽可能的去规避常规的风险点,比如说单点之类的;同时还要尽可能地去规避架构里面常见的坑。

容量评估
容量评估其实就是我们的服务在上线之前,要去对服务的承载能力做一个压测,这样我们才能更好的了解服务上线之后的状态。然后我们基于这个,再根据业务方量级的评估,去规划服务的容量。
容量评估其实是不能完全依赖于压测的。在压缩之前,要基于我们对自己服务的理解,包括每一条请求大概会耗费多少资源等,要有一个基础的认识,再基于这些认识去评估大概需要用多少后端资源、大概会用多少CPU内存,这些东西是可以用数学计算的方法来计算出来的。

灾备预案和灾备演练
这两点是比较关键的,跟故障会更强相关。

持续交付

故障中

故障真的发生了?去发现定位和恢复。核心手段::监控告警、日志分析、链路跟踪、故障隔离、容灾切换、降级熔断。

日志分析、链路跟踪、预案执行都是定位手段,在已经定位问题之后,并且匹配了相应的预案,要求去执行预案。当然前提是有相应的预案应对故障场景。然后依据操作手册,分别按不同的故障层次去执行处理。

恢复之后还要确认执行结果,看服务是否恢复正常。

故障后

在故障后,我们应该做好以下环节:故障复盘、故障改进、预案完善、容量压测、故障模拟、周边清查。

故障管理体系

做好故障管理,需要建设一些SRE体系提供支撑。

可用性体系

SLI是指标,SLO是目标,SLA是我们的目标加上目标未达成的后果

故障定级、定性、定责

定级通用标准

定级个性化标准

除了通用标准,还有一些没有被囊括到体系中来,比如某些电商类、商业化、广告类和金融类的业务,有可能造成资产损失,那么不同的部门会有不同的故障管理的定级策略。

定性有效分类

定责:判定原则

定责任并不意味着处罚。我们整体的故障管理从原则上来说尽量不指责,但不指责不代表着可以持续犯错误。

错误预算

SRE里经常听到错误预算,如何做到实际落地?前面讲了故障的定级规则,明确定级规则之后,不同的故障被定为ABC级,按对应计分标准扣分。扣的分数来源于给出的预算。我们每半年为一个OKR考核周期,在一个考核周期里面每个BU会分到一定的故障分,允许在考核周期里由于故障被扣分,如果分数扣完了意味着错误预算用完了。

组织结构支撑

SRE体系建设

稳定性建设

按照 MTBF和MTTR,把日常时间分成几段,不同时段里要做哪些事情?先是建设演练、Oncall值班,然后应急响应,最后复盘改进、再Oncall。在一个循环里面完成了SRE的工作。

PPTV

即PPT+V。PPT包涵了人员、流程、技术,是ITIL中的IT管理的三要素。SRE体系建设同样无法脱离这个模型,做好故障管理要有一个合适的组织结构、流程流程保障。

未来展望

AIOps和混沌工程Chaos Engineering

评论 (0)

取消
只有登录/注册用户才可评论