prr image from pixabay.com

SRE 工程师往往会负责一个具体组件,有时也称为服务或系统(下文都称之为组件)。 需要关注的有这个组件生命周期各类事项:运行状态、日常迭代、变更计划,以及在大促等活动中的筹备、预案等等, 有些组件是团队已经在长期持续维护着的,而有些则是要去新接入。 那么,当 SRE 接手(on-borading)这样组件时, 需要做哪些事项呢, 如何将「接手」这个行为做得有掌控力、顺畅且体面?

了解组件现状

第一步永远是了解现状,孙子兵法谋攻篇说,知己知彼,百战不殆。 现状包含组件的当前运行状态、环境, 还包含当前 SRE 团队的能力、平台是否可以顺利衔接。

了解一个组件,可以先以用户角度进行切入。 去理解这个组件提供什么功能,服务对象是谁,服务的规模如何? 能否将组件进行归类?是属于普通业务系统,还是基础设施? 如果时间充裕的话,还可以跟这个组件的用户进行几次沟通,咨询,他们关于这个组件使用上的痛点。

近期和长期的规划也是需要重点关注的内容。 在组件设计和规划上面有没有什么计划和目标。根据规划我们可以推断出该组件处于何种生命周期。 生命早期的组件要多关注变更和基础能力建设; 成熟期组件往往承担了较为重要的角色,很可能承担了相当的生产流量,这时候变更、可观测性和应急方面就要花更多精力。 生命周期末期的组件则关注点是在维稳,优先考虑如何找到人,并且尽量低成本复用现有能力平台,甚至还要适当关注服务迁移和下线计划。

第二步是以技术的视角来切入, 分别从架构、依赖、部署、可伸缩能力、容量等角度切入,具体需要回答的问题如下:

  • 架构和组件依赖:系统架构设计,功能特性图,模块切分图,核心场景的数据链路图,核心模型图;存储视角的模型图; 历史上架构是否发生变化,驱动变化的原因是什么,有哪些决策变量,这些决策变量未来是否还会继续变化?
  • 部署结构:物理部署图,有没有考虑异地机房问题?上下游依赖,哪些是强依赖和弱依赖
  • Scalable:组件是否是无状态的,是否具备水平扩容能力?如果是有状态的,状态管理基于什么存储系统?流量峰值如何应对?
  • 容量:当前吞吐水平如何;是否具备大流量下限流能力;流量峰值来时,是否有足够资源扩容;是否具备限流、降级能力?

结合 SRE 团队服务的其他组件,还要思考一下有哪些其他组件和当前组件类型一样,有什么差异点? 有没有特殊的部署要求?

对一个组件需要了解到什么程度才能接手? 这里我用几种程度来描述掌控力:

  • L1 具备作为普通用户的使用能力,应急时能够定位出问题方向,找到合适的人。
  • L2 具备资深用户能力,有一定调优能力(Tuning)能力。
  • L3 具备处置问题(Trouble Shooting)能力。
  • L4 具备架构设计能力和前瞻性,能够给 SWE 反哺输入

在经过一轮 PRR 完整流程之后,SRE 应当至少需要具备 L2 级别能力。 接管一段时间之后,随着对组件不断的了解,SRE 应当具备 L3 级别能力。

明确日常和应急事项

了解现状这个动作基本上是以静态的视角来看待组件。 完成之后,还要换成动态视角来看:有哪些日常操作(Operational)和紧急状态(Emergency)的操作

需要关注的领域有可观测性、变更、应急预案:

  • 可观测性:当前监控系统是否具备 Metrics、Tracing、Logging 三类观测机制接入?是否具备中心化监控能力?
    • 告警:接入哪些告警系统?是否拎出了核心 SLI(跌零因子、核心指标),是否具备基于 SLO 进行错误预算控制的能力? 告警的具体流程如何?是否具备告警抑制降噪能力?告警是否具备定位能力?历史数据是否可追溯?
  • 变更:目前基于什么工具进行变更?CI CD 流程分别是什么?发布周期是什么样子?配置变更二进制变更是否分离?是否有特性开关? 存储层面变更是否有考虑?各类变更流程是否有完成自动化?变更过程是否可以灰度?是否具备变更回滚能力。
  • 应急预案:是否有突发流量处理预案;是否有限流、降级策略?整体不可用之后业务影响如何?流量处理上是否考虑过雪崩场景?

在应急方面,还需要去了解过去历史上出现过哪些的问题。 翻看组件的故障复盘文档,了解历史上故障过程,故障原因,对应的 Action 是否落地? 尤其注意的是要关注 Action 工作机制是阻断式、检查式还是发现式? 老故障放到当下如果要避免是依赖系统、流程机制还是人工?

由于 SRE 日常工作主要构成是两类:能力建设和 On-Call。 在了解日常、应急场景事项时,还需要持续思考这些日常事项和应急动作能否基于 SRE 的工具平台、能力平台完成。 按照能力模型等级:手工 -> 工具 -> 自动化 -> 智能化来划分,当前日常、应急动作进入哪个环节了? SRE 也可以借事修物,借接收这个环节,重新审视自己的各类工具平台,是否满足这些日常、应急动作,能否更快更强更安全更准更好用?

明确服务范围

为了保证接手过程的顺畅,以及日后合作的体面,服务范围必须要在接手环节明确清楚。

什么是服务范围?就是接手之后工作内容的边界和日常合作模式。

一个最常见的边界划分是。变更:SRE 团队负责 CI / CD 环境建设,而 SWE 团队使用 CI 环境完成日常的部署。 SRE 团队则使用自行建设的 CD 系统进行变更管理。 日常和应急:在日常 Operational 事项和应急中,SRE 会按预案进行处置并保障组件回到最理想状态。 SRE 还需要建设可观测性、应急相关的技术基础设施,对组件全生命周期监控和应急处理。 SRE 最终承诺的组件对外 SLA,并将 SLA 拆解为 SLO 跟 SWE 共背。 在接受过程中很重要的一个工作就是,理清楚组件的 SLI / SLO,并且根据现状跟 SWE 团队商榷出对外承诺的 SLA。

除了服务范围,SRE 和 SWE 还要建设任务协作机制和沟通机制。 有没有统一的任务记录和流转平台?遇到稳定性相关的反馈如何,如何将需求转化为任务并追踪完成? 故障相关的 Action 如何追踪落地?一些基础环境变化以及业务上活动变化,是否有统一场合进行同步? 比较理想的情况是,基于任务管理系统,一个需求/缺陷从提出,到设计,到实现,到变更,SRE 都参与其中。 考虑到成本,现实执行时候可以根据精力、理解成本、重要程度、组件生命阶段进行微调。 有一个简单低成本执行方式,将服务领域组件进行划分后,每个领域派遣一个 SRE 进入对口的 SWE 团队进行追踪: 参加 SWE 团队的周会和日会,并将信息带回 SRE 团队同步。

谨记,划分没有统一的标准,不同团队,不同技术成熟度,不同生命周期组件都会导致不一样的边界和合作模式

总结

「接手」是管理的第一步。 在了解现状、明确日常和应急事项、明确服务范围等一系列动作之后, 相信 SRE 已经具备初步掌控力了。有了方法论,还要持续精益求精,将掌控力从 L2 进步到 L4。 想把事情给真正做好,核心是持续学习思考在对应领域的基础技能,并且持续了解客户的需求变化。 保持一专多能,成为随时可以顶上去独当一面的 SRE,这才能避免成为一个工单人。🐶

sre-push-up image from Twitter

扩展阅读:


原文链接: 如何做好 PRR(Production Rediness Review)? | Log4D

3a1ff193cee606bd1e2ea554a16353ee

欢迎关注我的微信公众号:窥豹

窥豹