运维人员 7*24 值班拯救指南

运维人员经常需要在周末出去游玩的时候也带着电脑，因为很多情况下运维人员需要随时待命。笔者依稀记得2014年左右，我们10多个运维小伙伴团建时背着5斤重的电脑爬青城山的壮丽场面。当年的值班体系还不完善，其中部分原因如下。

（1）业务线较多，不同的问题得由不同的运维人员跟进。

（2）开发人员、客服、测试人员都会给运维人员反馈问题，流程混乱，运维人员长时间处于被动接受的状态。

（3）各种问题堆积，极大地影响了运维内部建设，无法形成有序的工作节奏，内耗不断增加。

后来我们也尝试了值班制度，比如提供值班电话，将团队的问题集中在几个电话出口进行收集，但这样做并没有达到我们想要的效果，因为值班人员无法解决所有问题，他有时候还是需要联系其他运维人员，找到合适的处理人，并且还可能需要其他团队的协助，这种时候值班人员既要承担运维应急工作，又要执行各种协调任务，效率大打折扣。值班这条路开始走得非常不顺，直到后续笔者有幸接触到阿里巴巴本地生活商家中台的NOC的组建过程，这才知道了一种比现有值班制度更好的模式。

在本文中，我们会对轮值运营文化的落地进行实践，同时会从SRE的视角对轮值价值进行放大，找出更多的可能性。

值班模式探究

值班的核心目的是当生产环境发生故障时，有人可以在第一时间响应，同时将其他团队紧急对接过来的工作进行拆分，对接给相关人员，帮助减轻其他同事的压力。但故障毕竟是少数事件，久而久之，相关人员对实战中的应急执行动作会逐渐生疏，并且在值班过程中，因为故障不易出现，而放松警惕，去干一些自己之前没有干完的工作，这导致每天的值班可能会流于形式，在突发事件发生时，应急能力大打折扣。因此我们要探究值班如何既能解决应急问题，又能带来额外的价值。

注意：日常应急中，电话未接听或者电脑不在身边的情况随时都可能会发生，因此优化值班应急顺畅度对事前治理来说非常重要。让故障在第一时间被响应，将会极大地缩短故障时长。

让开发人员参与其中

不少技术团队的值班体系中只包含运维人员，极少有开发人员参与，这也导致当故障发生时，运维人员应急对接开发人员的过程变得不顺畅，再加上开发人员被临时拉进来的时候并没有值班待命状态，需要开电脑、上网等，耗时较长，这无形之间延长了故障时长。下图是一种比较常见的内耗情况。

如果你的团队存在上述这样的情况，试试做如下的尝试进行改进。

（1）根据技术体系的人员和业务线进行划分，每个业务线都需要安排一个值班人员。

（2）业务开发值班人员需要满足7×24小时的待命计划，并且主备两个角色。

（3）正常工作中，参与值班的开发人员的工作需要包含但不仅限于以下内容。

a 关注所属服务的日志内容，如错误等各种状态，一可以及时发现隐患，二可以分析日志内容，找到有问题但未达到应急标准的隐患，为后续的优化做准备。

b 第一时间响应运维值班的应急流程。

c 业务开发值班人员需要梳理自身业务线的应急故障描述，并对故障可能性做分类，可在日常值班时完成这些基础建设。比如，故障描述是订单查询为空，常见可能性处理内容是什么，处理人员一般包括谁（为应急预案做准备）。

d 业务开发值班人员和运维值班人员的名单需要及时同步给各团队，特别是客服团队，他们反馈问题的次数很可能多于监控发现问题的次数（很多时候都是如此）。

制定KPI

技术体系内的每个业务团队都有稳定性指标，但是这些指标有些时候只是挂在每个部门的负责人手里，是否会真的落地还未可知，这也是导致稳定性优化效果一直不太理想的重要原因之一。稳定性治理本身是一个漫长且烦琐的工作，如果人员长期被抽离做稳定性任务，势必会影响团队业务迭代的速度，这可能会造成业绩下滑，因此在很多团队内，并不会将稳定性建设作为核心KPI落实，即使安排了值班人员，应急顺畅度和改进措施仍很难达标。

根本原因来自KPI的目标制定，没有很好地将稳定性作为一个落地计划推进落地。我们把值班运营文化作为KPI目标修正的第一步，让技术体系的每个业务线都有机会参与一线应急，感受用户的各种抱怨和质疑，也感受稳定性建设和KPI的关联性价值。

团队KPI目标制定举例：

（1）本季度比上季度稳定性提升10%（拆分任务）。

（2）优化应急顺畅度，配合客服团队对故障描述进行梳理，本季度需要确保95%的故障可以通过描述找到对应的开发人员。

（3）对值班人员响应故障时长进行统计并评分，如合格指标是1分钟，即值班人员在1分钟内响应了应急报警或者客服反馈。本季度响应达标率需要提升30%。

基于上述KPI，我们可以进行拆分后各个击破，从而减少内耗，提升值班应急顺畅度和稳定性价值。

值班人员的边界探讨

我们时常会遇到如下矛盾。

（1）外部反馈了一件琐事，值班人员接手了这件事，却发现他并不擅长处理这件事，只有另一位运维人员才能处理，但如果转给另一位运维人员，那么自己就变成了反向代理，转发各种需求，但如果不做转发，自己一时半会儿搞不定，甚至有出现误操作的技术风险。

（2）紧急故障出现时，值班人员找到了相关人员解决，但发现其中有些问题是自己可以排查的，但倘若自己直接参与，可能会让整个应急过程缺失主导者，变成大家都在找原因而忽略了“快速止血”才是最重要的，但如果自己不参与，只是在旁边进行控局，又担心别人可能处理问题的速度不如自己，变得左右为难。

权衡利弊后我们做出了如下实践步骤，帮助值班人员在值班中处理不擅长的任务，详见下图，请读者根据自己的情况进行实践。

值班机器人

我们先看看几种不太友好的值班现象。

（1）有些公司的值班人员名单是通过邮件发送给客服团队和其他需要进行应急的部门的，其他人员找值班人员时还要翻找邮件，效率不高。

（2）值班人员存在电话打不通的情况，此时需要使用备用值班人员名单，这对于当前的客服来说，效率也不高。

（3）值班人员并不能时时刻刻关注电脑和手机，但却需要在有人呼叫时及时响应，比如1分钟内需要响应他人的呼叫。

为了降低找人的成本，我们添加了企业机器人，将机器人作为值班接口人，客服或者其他团队可以在第一时间呼叫机器人，然后利用机器人的回调找到对应的值班人员和需要处理应急的人员。

钉钉和企业微信都已经提供了这样的好产品，将机器人加入每个与应急有关的群里，供相关人员使用，机器人的常见任务如下。

（1）每天定时发送今天/明天的运维、开发值班人员姓名和电话号码等有关信息，并告知大家有事情请直接联系机器人。

（2）客服反馈问题时直接和机器人进行互动，比如使发送的内容中包含故障描述关键字。企业机器人回调后端代码时，可以根据描述自动寻找值班人员，如果主值班人员未接听，就会在1分钟内呼叫备用值班人员，若仍未接听，会不断联系其他相关人员，直至团队负责人。

（3）开放签到功能，每次响应故障时，机器人都会要求值班人员签到，确保人员已经就位。

（4）根据故障描述，机器人会自动找出可以参与应急的人员和所有当前值班人员，并一键拉群。故障描述和日常参与者名单都需要在日常工作中进行积累、填写和记录，最后通过程序将这些内容关联起来。完成这些内容需要以KPI目标为导向来推进，如果有稳定性接口人，会比直接通过之前的故障描述对接响应人员更方便，后面会对稳定性接口人进行说明。

（5）提供各项SRE自动化工具。

本文节选自《高性能之道: SRE视角下的运维架构实践》
电子工业出版社出版

书里以SRE的视角，提供了关于运维架构实践的宝贵经验，值得推荐阅读