一、前言
重点介绍了云原生背景下运维转型的思考,围绕着整个 DevOps 交付链,贴近业务不断输出运维的能力与价值。这篇内容我想谈谈 DevOps 的下半段,通过我们的构建服务稳定性保障实践,利用 SRE 的思想与方法,不断去冲刺稳定性的终极目标: “提升 MTBF(平均故障时间间隔)、降低 MTTR(故障平均修复时间)”,很多小伙伴会有疑问,DevOps 与 SRE 到底是什么样的关系?在 Google 出版的第二本书《The Site Reliability Workbook》的第一章节 ,已经明确给出了这个问题的解释,一行代码胜千言:“class SRE implements interface DevOps”,即 SRE 是 DevOps 的一种实现方式,也是 Google 在运维领域的一种具体实践。个人也比较认同这个解释,也深受启发,不得不佩服 Google 大佬的抽象与总结能力,放眼国内运维行业的发展历程,也潜移默化在形成自己的发展路径,实践与 Google 提出的 SRE 具有异曲同工之妙,缺少的是进一步做抽象,形成一套完整的方法论体系。本文的出发点也是站在巨人肩膀之上,结合自身业务服务场景,思考在云原生背景下,运维转型还有多少种可能性,本文或许只给出其中一种答案吧。
二、构建 SRE 体系
▫ SRE 能力全景
我们因地制宜,根据 IEG 海量在线营销的业务场景,引入 SRE 度量的机制、定制 SRE 准则,以及打造较为完备的工具链体系,以下是团队构建的玄图-SRE 稳定性建设全景图:
图2.1 - 玄图-SRE稳定性建设全景图
在这个体系中,云原生环境下的 IAAS 或 PAAS,我们关注的是 MTTF (Mean Time To Failure,平均无故障时间),这个能力由基础设施团队来保障。
全景图的中间是我们的玄图 SRE 体系,采用蓝鲸多级编排组装体系中的各种能力项,MTBF 列意为平均故障时间间隔,可以理解成稳定性保障的事前与事后,在这个环节中,我们在原有基础上扩展出两个核心能力,其中一个是“混沌实验”,旨在通过主动注入服务故障,提前发现并解决系统存在的隐患,提升系统的韧性;另一个为“全链路压测”,模拟真实的并发数及用户访问,通过自动拓扑图快速找到影响性能模块,定位问题根源。MTTR 列意为故障平均修复时间,这里我们拆解了 5 个步骤,分别做下解释:
- MTTI (Mean Time To ldentify)平均故障发现时间,强调团队的监控告警能力的完备性;
- MTTA(Mean Time To Acknowledge)平均故障确认时间,强调团队的 OnCall 机制执行,以及制度与技术的配套;
- MTTL (Mean Time To Location)平均故障定位时间,要求团队对故障的分析与解决问题经验的积累,以及平台工具的配套;
- MTTT (Mean Time To Troubleshooting)平均故障解决时间,对服务高可用架构的设计、容错、扩展能力提出要求;
- MTTV (Mean Time To Verify)平均故障验证时间,围绕服务体验为核心的监测体系,建立与业务、用户的反馈机制。
这个环节作为稳定性保障的“事中”尤为重要,其中可观测性作为下一代的质量监控的代表,通过强化分布式服务的日志、链路、指标的关联,缩短发现问题、解决问题的时间,可以极大缩短 MTTR 中 MTTL 的耗时。
▫ 定制 SRE 准则
在实践 SRE 过程中,我们总结并提炼了“SRE 8 准则”,来指导我们的日常运维工作。有了这 8 个准则,就很清楚我们需要具备什么样的能力与工作方法,来达成什么样的工作目标,同时也延伸出下面介绍的 SRE 工具链。首先简单介绍我们的 SRE 8 准则,下面简要进行剖析:
- 架构设计准则 - 我们认为所有的架构都是不完美的,都存在缺陷,因此我们在做业务架构设计时都必须要考虑服务稳定性保障,如负载均衡、多点容灾、集群化服务、数据多活等能力;
- SRE 前置准则 - 在业务立项之初,SRE 角色需要提前介入,将运营阶段可能出现的问题或风险提前在架构设计、编码阶段暴露,提前准备好解决方案,甚至规避问题与风险;
- 混沌实验准则 - 故障不可避免,为何不让其在测试或预发布环境提前到来,通过模拟现网真实故障来验证服务的“韧性”,找出系统的弱点,同时验证我们的监控告警的有效性,在 Pre-MTBF 阶段实施最好不过,也是我们其中一把利器;
- 可观测性准则 - 通过采集业务指标、日志、追踪等数据,快速分析与定位问题,同时发现复杂系统的瓶颈点,在很长一段时间内,业务指标、日志、追踪的采集与应用,都是独立存在并分开建设,随着时间的推移,发现这三者是相互关联,相辅相成的,是我们的第二把利器;
- 全链路压测准则 - 通过与可观测性、混沌实验能力的深度整合,实现模拟真实业务环境全链路压测,达到业务上线前的精准资源评估,主动发现潜在性能、版本缺陷等问题,是我们的第三把利器;
- DevOps 交付准则 - 通过打造高效的价值交付链,覆盖 CI、CD、CO 服务全生命周期运营管理,CI 我们采用 ODP 封装蓝盾方案,CD 与 CO 采用蓝鲸运维编排及监控告警等能力,SRE 会将大分部精力聚焦在 CO 环节;
- 故障应急准则 - 故障不可避免,我们能做的是不断去提升 MTBF,降低 MTTR,包括事前的实施大量混沌实验、故障预案;事中采用打造的工具链,快速发现、分析、定位与解决问题;事后组织总结复盘,沉淀案例经验;
- SRE 学习准则 - 营造学习的文化,目的是实现多个不同职能团队的有机融合,相互了解大家面临的问题或挑战,形成一致的目标,达到有效的协同,解决业务的问题。团队于 2016 年发起的《微分享》机制,截止目前累计 250 次分享 。
三、跟踪 SLO 状态
量化目标是一切工作的起点,所有运维工作都以围绕 SLO(服务水平目标)指标的定制、执行、跟踪、反馈来展开。其中定制与执行因各业务形态的差异,此处不进行展开,指导的原则是选择合适的 SLI(Service Level Indicator,服务等级指标),设定对应的 SLO。梳理与采用业务侧关注的 SLI 指标,目标值达成一致即可。我们具体的 SLI 采集实践见第一篇文章的云原生应用监控 章节,其中关于识别 SLI Google 提出 VALET 法,分别是 Volume、Availability、Latency、Error 和 Ticket 的首字母,这 5 个单词就是我们选择 SLI 指标的 5 个维度。
- [x] Volume&#x