再谈清单管理：让运维5x8的效率完成7x24的值守

在上篇《清单管理在运维服务中的实践》中谈到了清单（Checklist）应用在运维服务中的原则，以及为什么运维服务需要清单？

今天是724运维日，我在方法论之上，提几个案例，看看我们的清单在实践中起着怎样的作用。

《清单革命》一书中提到了一个关于世界卫生组织手术安全清单（Safe SurgeryChecklist）：

● 在实施麻醉前有7个检查项目：

       √患者本人或家属是否已经确认了患者的身份，并同意进行手术；

       √手术部位是否已经标记；

       √是否给患者进行血氧饱和度监测，该仪器运转是否正常；

       √患者是否有既往过敏史；

       √是否存在气道困难和误吸的风险（这是实施全身麻醉最危险的一个地方），所需设备和辅助人员是否已经就位；

       √是否存在失血量大于500毫升的风险，儿童为每千克7毫升；

       √必需的中心静脉置管、血袋和补液是否已经准备好。”

● 在切开患者的皮肤前，手术团队还要进行7项检查：

       √团队所有成员对各自的姓名和职责是否进行了自我介绍；

       √团队成员是否确认了患者姓名、手术名称和手术部位；

       √在手术前60分钟内是否给患者注射了预防性抗生素；

       √是否已展示手术所需的扫描和影像资料；

    √有关手术的关键信息是否已经讨论过，主刀医生是否介绍了手术的关键步骤是什么，手术需要进行多长时间，预计病人的失血量是多少，相应剂量的血袋是否已准备就绪；

       √麻醉医生是否评估了麻醉计划，是否还有其他需要特别注意的事项要提出；

       √护士是否确认设备已经就位，消毒已经完成，是否还有其他注意事项需要提出。

● 在手术结束后患者离开手术室前还要进行最后5项检查。巡回护士必须对下列事项进行口头确认：

       √记录里的手术名称和刚刚完成的手术是否一致；

       √手术器械、敷料和针头是否清点完毕；

       √需要进行病理检验的组织标本是否已经标记；

       √是否存在需要解决的设备问题；

       √主刀医师、麻醉医生和护士是否说明患者术后康复治疗方面的注意事项，是否确定没有重要信息遗漏，是否已就重要问题进行了沟通。

医疗和运维，在某种程度上来看相似点很多，前者是救人，后者是救业务；前者是让人们一次次从伤病中恢复健康，后者是一次次让业务在故障中恢复持续。

医疗有必要进行清单管理，运维当然也要，接下来，我举运维中两个场景下的清单为例，一个是复杂性事件，第二是高度复杂性事件。

私有云升级，属于主动型操作事件，一般准备工作比较充分，而且会有详细的操作步骤，因为涉及不中断业务在线升级，所以归类为复杂性事件。在这个场景下，清单的作用是一些关键步骤的提示，帮助激活大脑，梳理脉络，同时避免“灰犀牛”事件的发生。

升级前检查项目：

              √测试环境是否进行了升级；

              √测试环境升级是否出现过问题？如果是，是否解决；

              √客户是否得到升级通知，并确认同意升级；

              √是否准备好回退机制？

升级过程：

              √客户环境是是否和测试环境一致，包括操作系统版本，如果不一致，需要保

               持和测试环境一致。

              √升级前，是否对数据库进行备份；

              √管理节点与计算节点操作系统版本是否一致；

              √网络连接是否正常；

              √本地源是否最新；

              √为保持数据库一致性，升级期间不能有任何新建操作。

升级完成：

              √检查管理节点状态；

              √检查计算节点状态；

              √检查云主机状态；

              √检查VPC路由器状态；

              √检查存储节点状态；

              √创建云主机、网络、存储等操作都需要验证一遍。

对于高度复杂性事件，我举一个客户报修的案例。

前不久，我们遇到一个客户报修，客户的反馈是，部署在某机房的私有云服务器上的网站会发生不定时打不开的问题。

遇到这个报障，不妨试着考虑下，如果你遇到这个问题，该如何排查？

需要排查的因子有很多，这种问题有着多种可能的原因，故障出现频率不高，而且监控未发现异常。根据我们对于问题的定级，这种问题属于高度复杂性问题，现象很简单，但可能导致故障的因素会比较多，排查会比较复杂，可能要多次排查才能定位问题，。

复杂性问题的清单不仅仅是关键性步骤，更重要的是一个沟通清单，以确保在每个领域的各个专家们是在以一个团队的形态去应对问题，因为团队犯错的几率比单个人要小很多。部分清单内容如下：

判断问题（设置清单触发事件）

              √故障是否影响生产环境；

              √监控告警是否触发；

              √能否根据告警信息迅速定位到问题；

              √根据历史经验是否在10分钟之内能够定位到问题，并有具有处理的能力。

处理高度复杂性问题：（部分清单）

              √是否将信息同步到网络、应用、数据库、云系统、物理基础设施等各个领域

         的运维专家；

              √专家们是否充分交流，共同商讨行动计划。

              √在系统运维层面是否排查了各个相关性应用和组件；

              √在网络运维层面是否排除了网络设备、路由、交换、端口、模块、光纤、网

         线等所有问题；

              √是否排除数据库层面的所有问题；

              √是否在云系统层面排除所有问题；

              √是否排除物理基础设施层面的机房、电力、线路等问题。

根据高度复杂性问题对应的清单，我们的专家们进行了短暂沟通，各自完成各自领域内的问题排查。

系统运维专家根据经验，按照单因子排除策略，逐一排除DNS，tomcat，Nginx等服务问题。

网络运维专家检查网络层、数据链路层、物理层问题，并从全国其他点进行模拟访问，缩小问题范围。

云计算专家检查云系统各个虚拟路由器的服务、云主机的网卡等是否正常。

这个问题又因为不能访问网站的现象是不定期出现的，所以并不能快速在出现问题的时候定位问题。在排除了一系列最有可能的原因之后，依然没有定位到问题，但是很显然排查范围已经缩小了，根据经验，判断TCP协议出现了问题。

为了验证这一判断，由系统运维专家写脚本，监听网站的服务的状态，一旦发现不能访问的情况，由网络专家在服务端和访问段同时进行抓包，终于最终发现了造成网站有时不能访问的原因，是因为服务器TCP协议的返回包，终端未收到，但ICMP协议不受影响。

下一步就是判断是TCP协议的返回包丢在哪个路径上，我们又依次排查服务器的物理网卡，接入交换机，核心交换机等设备，最终关闭主上联链路，使用备用上联链路。每一步，都需要持续观察10分钟以上，直至启用备份链路，网站不能访问的现象不再出现。

至此事件管理告一段落，客户的业务在经过复杂地排查后，恢复访问稳定。后面是问题管理，在这里不再深入讨论。

在这次复杂性问题的排查过程中，清单的作用是能够帮助我们在操作的每一步都尽力保持冷静而睿智的头脑，确保在必要的时候得到所需要的重要信息，系统地进行决策，在遇到复杂问题的时候，和每一个应该沟通的人进行充分交流，充分发挥每一个参与解决问题的专家的能力，从而使得事情有条不紊的完成，问题高效而有条理的解决。

清单的制定是专家们处理复杂问题经验的提炼，但前提是得有经验的积累，运维专家经验获取的途径往往是血和泪的教训换来的。如果经验获取的成本如此之大，那还不如不要的好，但故障始终会存在。系统正常只是万千异常中的一种特殊形态而已。所以我们更应该考虑如何让系统更加健壮。

后面有时间我们再聊聊系统的反脆弱，比如：Netflix公司为了使他们的系统更加健壮，甚至主动随机的增加破坏，创建了一个叫 Chaos Monkey 和 Simian Army的系统，随机杀死一些服务，制造错误和混乱来测试和攻击系统稳定性，以此来增加运维和安全人员的挑战。

做好清单管理，让运维更高效，防止灰犀牛事件，处理问题更迅速，祝大家724运维日快乐。

作者介绍：金霄 新钛云服运维总监

十年运维经验，苏州大学数学专业本科和中国科学技术大学MBA毕业，并以论文《运维风险管理》获校优秀毕业生。曾任盛大在线系统工程师、微烛云和某互联网金融平台运维负责人、微烛云COO，组建微烛云产研测运团队，主导自研微烛云和自动化运维管理平台，致力于企业基础设施和运维服务。

精品好文：