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

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

窥豹