如何做好运维 & On-call 机制规范？

作者：高铭谦，腾讯云高级工程师

背景

对于云计算服务而言，后台工程师不但需要负责开发的部分，同时还需要负责运维的部分，所以 Oncall 机制对于云计算的工程师而言并不陌生。

Site Reliablity Enineer （SRE）是 Google 提出的一个岗位，SRE 的团队里包含有硬件工程师，软件工程师和系统工程师，他们的职责与传统的 DevOps 工程师，他们不但需要承担 DevOps 的责任和工作，而且需要通过工程能力主动去运维，让运维自动化。AWS Oncall 机制是云计算行业里的标杆，对于 AWS 的后台工程师来说，开发，架构与运维是一个 AWS 工程师最基本的工程能力，这些工程能力的培养，奠定了 AWS 的 Oncall 机制能够高效顺畅的执行至今。

运维不仅仅是保证服务稳定，更是提升服务质量的重要工作。将运维规范好，能够更好地避免 Oncaller 线上运维思路混乱，定位问题不准确，没有工具及时发现服务情况甚至没有工具恢复服务异常的尴尬情况。

无论是 Google 还是 AWS, 一个团队 Oncall 从来不需要超过两个人 （另外一个是新手 shadow），一个工程师便能将每分钟 PB 级别的请求量，全球 20 + 个地区，过万个服务节点安全护航。所以对运维的规范制定，不是一个选择题，而是一个趋势和答案。

SRE 运维体系提案

01

如何扮演好一个 SRE

当一个团队在给服务做运维的时候，我们希望将整个运维门槛降低，降低老工程师的检查问题的时间成本，降低新工程师的上手运维的学习成本。换句话说，一个成熟的 SRE 团队是建立在相互信任的关系上的，为了维护不同服务在不同地区的稳定性，我们需要相信每一个 on-caller（值班人员）足够了解系统架构，系统如何运作的，以及准确定位问题并且找到相关团队寻求帮助。

团队建立初期的本质问题 - 新加入团队的工程师需要如何进入这样一个 oncall 的良性循环？通常会想到以下问题：

• 老工程师们应该如何判定新工程师达到可以 Oncall 的标准？
• 如何有机结合新工程师的热情和好奇心与老工程师们的诉求？
• 什么样的标准和行为会让整个团队收益的？而不是单纯为了秀技术。

新工程师加入任何一个团队，都有一个学习的过程，要快速成为一个合格的 SRE，我们可以遵循以下推荐的模式，同时也给出了反例作为借鉴。[1]

上述的模式不仅适用于新工程师，也同样适用于老工程师，我们需要保持持续学习的心态，不断迭代优化运维流程，不断优化服务质量，才能将整个流程快速高效的运作起来。

以下是 Oncall 的逻辑关系图，不同阶段会有不同层次的理解。[1]

Oncall 机制规范提案

一个完善的 Oncall 机制，是保护云服务安全的最后一道防，AWS 的 S3 有 11 个 9 的可用性，离不开打磨多年的 Oncall 机制。

传统的 Oncall 机制是 “谁开发负责”，这种体系不适合应用在大企业的微服务架构上。大企业的微服务架构有一个共同的特点，就是服务数量多并且增长速度快，而且需要不断优化已有服务，淘汰质量差、收入低的服务。所以需要以一种新的方式，将旧服务的运维流程化、可复制化，降低团队整体的运维成本以及提升开发效率。

Oncall 机制顾名思义就是需要轮班制，为了保障服务质量，我们需要 24 * 7 去监控维护。在上班时候，大家都在工位上有问题可以即时发现即时解决，但在非上班时候，需要值班人员保障服务质量。

整套 Oncall 体系分为两大块：

NinJa （工作日 10:00 到 18:00）

Ninja 是工作时间里负责（早上 10 点到下午 6 点）保障服务质量的角色，具体工作如下：

1. 充当一名侦探，在各服务中寻觅影响服务质量的蛛丝马迹。在每周的 Ops meeting 中汇报。

1.1 查看监控，分析服务可用性下降或者耗时增加等影响服务质量的问题的根部原因。

1.2 整理以上事件的 1）服务名；2）时间 & 地区；3）关键指标下降证据（监控面板截图）；4）什么影响；5）是否影响到客户

例如：xxx 服务，广州 x 区，在 2020-10-30 10:15am ～ 10:25am 时段，服务可用性从 99.993% 下降到 99.91%。根本原因为 xx 母机负载过高导致访问 xx 集群服务耗时增加，耗时 p99 突刺明显，最高到达约 xx ms，约 xx % 请求大于 xxx ms 直接返回超时。导致用户无法正常使用。

1.3 分析根本原因，优化并且解决（运维手段，代码，或者脚本 / 代码自动化运维手段）

2. 处理线上紧急告警事故，并且将紧急告警事件从发生到解决过程记录，把解决方案记录到文档中，并且在 Ops meeting 中汇报。

3. 处理客户工单事情

4. 剩余时间，Coding time! 自己提出可以优化服务想法，把想法做成支撑服务，将运维自动化，智能化！

Oncall (工作日 18:00 到第二天 10:00，以及周末和节假日全天)

1. 只处理线上紧急事故，具体步骤：

1.1 根据文档，以及过往相似事故，迅速定位问题以及解决方案

1.2 是否有办法马上解决？有则马上解决，将遗留问题放到工作时间再慢慢处理。

1.3 没有解决办法？请求 Secondary oncaller/ 业务负责人 /manager 帮助。

1.4 涉及到其他团队？拉群打电话！

1.5 ！！！切记 ！！！不要慢慢思考如何将解决方案做大做好，先解决线上问题，再去思考！

2. 第二天记录前晚上出现的线上事故过程以及如何解决，作为之后 Ops Meeting 需要回顾的重要材料。

3. Oncall 前检查好自己是否都准备好：

3.1 良好的网络环境以及电话信号畅通

3.2 监控面板以及文档是否有不能访问的

3.3 业务负责人以及组长、总监的电话是否都有而且能打通

4. Go fight!

Ops Meeting 提案

Ops Meeting 主要是对过去一周服务质量进行一个回顾、容量评估以及事故汇报的总结大会。从团队维度，Ops Meeting 是一个同步过去服务监控情况以及线上运维进度信息的一个重要的会议，它可以帮助团队各成员更好的理解线上业务情况，更好地在开发过程中避开在线上遇见的问题。同时也为下一个 Oncaller 积累线上运维的进度和基本情况。

从管理者维度去看，Ops Meeting 是深入了解团队和服务健康情况的重要会议，在 Ops Meeting 中，管理者不但可以了解到过去一周服务健康对整个业务带来的风险以及损失，而且也能与团队同步上级对过去服务质量管理的趋向以及态度，为团队提出建议和意见。

另外 Ops Meeting 的容量评估，对管理者而言，不仅仅是了解服务容量状况的一个会议，更是将成本控制调整到最优的一个证据来源。Ops Meeting 可以说对前面 Ninja 和 Oncall 的一个总结回顾，将信息搜集整理并比较和优化的一个重要过程。

从结构上 Ops Meeting 主要分为 3 大块：

1. 过去一周线上事故的汇报与总结
2. Ninja 对过去一周服务质量的汇报与总结
3. 观察 Service Capacity Wall，根据服务当前容量以及 Ninja 提供过去一周的服务质量报告，判断不同服务不同的地区，是否需要扩容或者缩容

过去一周线上事故的汇报与总结

可以根据以下模板进行填写：

• 事故服务名称，时间，地区，影响范围，以及监控指标异常 & 证据截图。
• 引起事故的原因以及结果
• 处理流程（关键时间点），比如

1. oncaller checkin；
2. manager checkin；
3. 发现服务延时持续变高，观察服务器 CPU 升高（贴图！），准备扩容；
4. 扩容 *** 服务，*** 地区，请求其他工程师检查并且 ack；
5. *** 工程师 “ack”；
6. 开始扩容，为 *** 区的 *** 服务扩容 *** 个实力 /pod；
7. 扩容后观察监控，cpu 指标下降缓和（贴图），服务耗时 P99 开始下降并且趋向正常（贴图）；
8. 问题解决（结单）

• 本次事件运维文档上是否有用，文档是否需要优化；是否发现代码 bug, 是否需要优化代码。

Ninja 对过去一周服务质量的汇报与总结

Ninja 的具体工作在上面 Oncall 提案部分已经提及到，这里重点是提供总结 & 汇报模板：

• 出现异常的服务名称，指标，时间，地区，特征，原因。比如：

xxxx 服务，在 2020 年 11 月 11 日 01:03 有大面积的服务延时上升，约 1% 的请求收到请求耗时高达约 7 秒的影响。主要原因是坏节点导致部分请求在初期直接超时，2 分钟后网关自动提出坏节点，导致其他健康节点负载上升。

• 是否有其他在运维和处理客户工单过程中遇到的问题，以及如何解决，是否需要上升到总监及以上。
• 各服务各地区的流量增长 / 减少情况。

观察 Service Capacity Wall，根据服务当前容量以及 Ninja 提供过去一周的服务质量报告，判断不同服务不同的地区，是否需要扩容或者缩容。

Service Capacity Wall 是一个对所有相关服务在所有可用区的负载指标和容量的二维动态报表。

后台通过每天在宿主服务器抓取服务系统指标，并且聚合成每天的容量指标，并且预测未来多少天会达到 80%（需要扩容），或者下降到 20%（需要缩容）。根据上述 Ninja 总结的每周服务情况，团队以及 Manager 判断是否需要做扩容和缩容。另外比如在一些大节日前，Ops Meeting 也是一个提前规划扩容以及资源需求的重要会议。

总结

SRE 模式下的运维体系，是未来时代的产物，是颠覆目前书本教材上现有的工程管理模式，Google 和亚马逊已经在这一套运维体系根据公司自身业务完善到几乎无懈可击的地步。作为刚起步的我们，仍需不断优化，不断学习，负重前行，不断完善我们的监控运维体系，低成本提供可靠高质量的服务给客户，才是云计算的最终目标。

References:

[1] Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy, Site Reliability Engineering.

欢迎联系云监控小助手微信号，加群讨论：）