运维人的终身成长，从清单管理开始

尊敬的各位运维同学，大家下午好。我是金霄，来自新钛云服，目前从事云计算MSP相关的事业，创业之前曾在盛大等互联网公司做过十年的运维工作，从技术到管理，一路走来，有一些有关运维人未来成长的内容希望在这里和大家一起探讨。

之前萧田国老师在这个讲台上有讲过《基于 DevOps 的新运维成长路径》，布道DevOps，讲述运维如何在纵向（深度）和横向（广度）上延续自己的职业生涯。而我今天的分享主题是运维人的成长，从清单管理开始。

和大家聊聊清单思维，如何用简单的 工具 解决复杂性问题，并且清单思维在运维人的终身成长中起着什么样的作用。

我的分享内容分为四个篇章，成长的因素、错误的分类、清单的应用以及清单背后的思维模型。

成长的因素

本周我以运维顾问和项目管理的身份去参与国内一家大型的自营服装品牌的海外B2C电商的黑五保障工作，该公司的发展速度特别快，而运维在这种情况下缺乏体系化建设，我想这也是很多公司面临的问题。

我将要帮助他们运维团队诊断现在存在的运维体系建设、安全等工作的问题，提出整改方案并落地。

为了保障2个月之后的黑5，需要帮助他们实现现有海外机房的一个商城业务迁移到海外某公有云上，原来机房的其他业务还要做扩容。

两个月，需要完成这么多工作，对整个团队都是严峻的考验。而今天要讲的清单思维实际上已经在过去的2周已经开始帮助这家公司的运维团队慢慢地从杂乱章的琐碎事情和救火救急的状态中抽离，这一效果在我刚刚过去的1，2天时间是万万没有想到的。

为此我还整理出了一张成长方法清单：学习、表达、迭代。学习新的知识，了解背后的思维模型；如果要快速学会一个知识，最好的方式就是讲给别人听；最后，获取新的知识，再不断迭代，最终把知识真真正正变成自己的。

对于成长这件事的因素有很多，外因比如：公司业务的发展带来对新技术、新知识、新能力的需求。

技术本身的发展进步，比如云计算、AI技术的发展，传统运维到自动化运维再到Devops理念，甚至AIops的提出，对不同角色的运维有着不同程度的影响，或多或少的减少了企业对于基础运维人员、应用运维人员、甚至DBA的需求。

社会环境、行业变迁、政治制度等的变化等等。这些因素都推动着你不得不成长。

当然，不可跳过的还有内在的驱动力，这可以从马斯洛需求层次理论里找到答案。

人的内心总有更高层次的需求，先满足衣食住行等的基本生理需求，其次考虑保障自身安全、摆脱失业和丧失财产威胁、避免疾病的侵袭等安全上的需求；

之后在社会交往上，有友爱和归属感的需要，友情、爱情，以及希望归属于某一个群体；再往上到希望自己有稳定的社会地位，希望个人的能力和成就得到社会的承认和尊重；

最后随着能力不断的提升，你不断在寻找和自己能力相匹配的事情，这样才会感到最大的快乐，这个阶段通常表现为实现个人理想、抱负，发挥个人的能力到最大程度。

我们每一个人走上运维这个岗位当时的想法一定是不一样的，有一部分人是为了一份工作，有一部分人是因为对于技术的喜爱，还有一部分人可能一开始连运维工作的内容都不了解也走上了这条道路。对么？

不管当初因为什么原因成为了一个运维人，一旦开启了这个职业，就需要按照这个职业的特性发展下去。

运维也是一个比较新的行业，由于互联网的发展带动了这个职业的需求，作为软件生命周期最长尾的运行维护阶段，运维也在随着互联网技术的发展而不断变化，比如当下devops理念的出现，就是打破开发和运维的界限。

我希望在场的每个人都需要有宏观视野和更深层次的思维模型，技术从来不是独立存在的，每一家公司最核心的是业务，开发、测试、运维组成的软件生命周期是为了全力实现业务的需求，并将需求尽快发布上线以实现商业上的收益。

即使是技术输出型的服务型公司，也是要全力帮助用户的业务需求。

基于商业的基本逻辑，核心点永远是扩大业务规模，降低成本支出，在业务规模不断扩大的同时，如果整个软件生命周期越短、所需要的人力成本越少，是不是收益越大？

而且从技术上考虑，业务规模越大意味着系统越复杂，那么仅仅投入人数很快会产生边际效益，靠堆人解决不了复杂性系统的问题，所以这一基本逻辑推动了技术的发展，特别是在互联网迅速发展的这十几年时间里。

所以不管你是由于什么初心从事运维这个职业，不管是外部带来的危机感也好，内在需求的升级也罢，运维人需要成长。

提到成长，大家身边的人都是怎么做的呢？ 关注微信公众号的技术文章，关注前沿科技，买本书埋头学习，组织参加技术交流活动、当然，还有参加GOPS运维大会。

我们非常努力，每天看了很多内容，听了很多道理，做了很多事情，但是由于碎片化信息很多，往往有个很好的开端，却缺乏好的过程管理以及理性的思考和提炼，这样是无法成长的。

什么是成长呢？成长就是当你的主观世界和客观世界之间有一道鸿沟的时候，你掉进去了叫挫折，爬出来了叫成长。换言之，如果遇到错误和失败，纳入到自身，叫成长；不能纳入进来，叫不成长。

根据这份成长的定义，其实运维这份工作本身很容易让人获得成长，对于任何一个运维人，如果要问，让他最痛苦、最不愿意面对的事情是什么，我想答案都是故障，故障就是运维人面前的其中一条沟。

另外运维人面前的沟还有无数条，新的开源软件，新的技术，Devops背景下，运维需要具备的研发能力等等。沟那么多，我们只能一条条来填。

错误的分类

相信大家都看过诺兰导演的《星际穿越》这部电影，电影开篇就提到一个著名的定律——“墨菲定律”。“墨菲定律”的原话翻译过来是这样说的，如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会作出这种选择。

简化的意思就是，任何可能出错的事情都会出错。根据“墨菲定理”，我们可以知道：

1. 任何事都没有表面看起来那么简单；

2. 所有的事都会比你预计的时间长；

3. 会出错的事总会出错；

4. 如果你担心某种情况发生，那么它就更有可能发生。

这和《SRE，谷歌运维解密》这本书中说的“系统正常，只是该系统无数异常情况下的一种特例。”有异曲同工之妙，我想这应该是普世哲学。

系统正常，只是该系统无数异常情况下的一种特例。——来自《SRE，谷歌运维解密》

作为运维人，对于墨菲定律，我们应该秉持积极的态度，既然故障无法避免，是一种常态，任何一个软件系统都避免不了，那么我们就不能有丝毫放松的思想，要时刻提高警觉，业务体量越大，系统越复杂，问题和故障就会越多，这个是必然的，我们需要做的，就是在故障发生的时候用最快的时间响应，最短的时间处理，思考借助怎样的方法来持续、正确、安全地把事情做好。

这也是运维人的使命，7*24小时的守候，为的是让这个正常的特例尽可能地维持常态。

在运维的日常工作中，我们是否遇到过这些问题 ：

• 为什么在看似“万事俱备”的情况下，仍然有可能因为一个大家都忽略的小问题而影响进度？

• 为什么有时候在复盘时发现本该10分钟解决的问题，实际过程中，1小时甚至更久才能解决？

• 为什么经历大量案例，并已经形成了知识库，但关键时刻仍无法快速建立索引，找到知识库里面的案例来辅助解决问题？

• 为什么会议中几方沟通的事情，等到落地实施的时候会出现偏差？

这些我们遇到的问题，也印证了前面讲的墨菲定律。咱们运维是应用生命周期的应用运行维护阶段的守护者，而这个阶段也是软件生命周期内最长尾的阶段，占据整个周期的70%左右。

特别是当问题发生在正在提供服务的生产环境的时候，一个是正确操作还有一个是时间，操作和处理问题的时间离复盘之后的理论值越接近，则约接近成功，反之，则是失败。

当然，一次失败并不可怕，可怕的是失败之后，下次遇到类似的问题再次失败。在同样或者类似的问题上摔倒，显然不是一种成长，即便有所成长，代价也是惨痛的。

虽然“墨菲定律”提到错误总会发生，我们无法避免，但是我们可以想办法降低错误发生的概率。

容易犯错误是人类与生俱来的弱点，不管科技多么发达，事故都会发生，而我们解决问题的手段越高明，面临的麻烦就会越严重。

即便是我们通过使用自动化来防止犯错且提高效率，但对于不可预测的故障，管理的不确定性等事件还是难以做到，而且技术，特别是开源技术的底层我们未必熟悉，这些因素都无疑增加了事件的复杂性。

无知之错：我们犯错是因为没有掌握相关知识，科学只让我们部分理解了世界的运行规律。

无能之错：我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。

——阿图 · 葛文德《清单革命》

阿图葛文德在《清单革命》一书中谈到，人类的错误可以分为两类：第一类错误是“无知之错”，我们犯错是因为没有掌握相关知识，科学只让我们部分理解了世界的运行规律。

第二类错误是“无能之错”，我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。

在实际运维工作中，我们遇到的错误大多是“无能之错”，比如人为的本不应该犯的操作错误，以及硬件、软件、系统等在运行过程中出现的可穷举的概率性故障事件，而我们却未能做好预案，从而快速恢复系统的正常工作。

我们在持续、正确地运用我们所掌握知识的过程中遇到了问题，系统在不断变得复杂，无论我们进行多么细致的专业分工和培训，一些关键的步骤还是会被忽略，一些错误还是无法避免。

清单的应用

这个时候就需要使用工具来辅助我们避免错误，使得系统能够持续、正确地运行。这个工具其实也非常简单，就是清单。第三部分我讲讲清单的应用。

在运维操作过程中，运维人需要应对两大困难：

1. 人类记忆和注意力的分散。尤其是在重压之下，人们特别容易忽视一些单调的标准动作；

2. 越是专业的人，越容易犯的错误是，面对重复性操作，人们会不知不觉跳过一些明显的步骤，或者是根据已有经验，总觉得自己不会犯错，而往往会在这个时候犯错。

案例1：

前不久，某云的一个企业用户数据丢失的事件引发了整个行业的关注。原因后来也披露了，该故障起源于因磁盘静默错误导致的单副本数据错误，再加上数据迁移过程中运维人员有两次不规范的操作，导致云盘的三副本安全机制失效，并最终导致客户数据完整性受损且不可恢复。

这两次违规操作分别是运维人员为了加速完成搬迁任务，违规关闭了数据校验；以及运维人员为了尽快降低仓库使用率，违规对源仓库进行了数据回收。

在正常情况下，数据搬迁流程会默认开启数据校验，开启之后可以有效发现并规避源端数据异常，从而保障搬迁数据准确性。而数据搬迁完成之后，源仓库数据应保留24小时，用于搬迁异常情况下的数据恢复。

案例2：

上个月，由于机房的机柜电力调整，我们需要做同一机房的服务器搬迁，我制作了清晰的作业清单，预计1小时完成搬迁并能正常提供服务，但实际上最终花了3个小时，多花的2个多小时原因却是运营商提供的两根上联光纤始终调试不通上，最后发现问题竟然出在运营商人员将中间的光纤ODF架端口插错，实际排查问题也很快，时间大多浪费在协调各个部门，以及对应部门的响应上。

还好深刻领悟了墨菲定律，预留的割接时间就是3个小时，原本是担心服务器硬件在搬迁中出现问题或者系统重启出现异常等常见故障，所以做了相应的预案。最终没有影响到业务。

这个问题表面上看是运营商的问题，实际上是我们清单管理没有做到位，第一并没有把和事件相关的每一个因素考虑到清单内，哪怕是外部因素，准备工作中没有加上搬迁之前检查测试这两条线路的连通性，只是机房单方面告知测试过了，属于简单性事件的忽略；

第二，在排查问题的过程中，由于缺乏预案，以及没有提前协调相关部门做应急准备，所以沟通协调方面花了过多的时间。这件事也反应了运营商端缺乏核查清单，没有对提供的光纤进行核查，也缺乏快速的应急响应的流程清单管理。

这两个案例，是我们行业中真实遇到的案例，我相信在座的大家都能想起自己遇到的很多案例，对此我们不能总是抱怨，必须要有所总结，将这些信息有效管理起来，形成一个个关键步骤。

清单可以帮助梳理事件，提醒人们每一个“关键步骤”的因子，在决策的时候不要跳过“关键步骤”，激活记忆和集中注意力，避免出现由于简单错误导致严重后果的情况。

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

比如升级前核心的检查项目有哪些？升级过程有哪些关键点需要重点核查？升级完成之后，要检查哪些重要的状态指标？这些都需要制作核查清单和操作清单。部分清单如下：

升级前检查项目：

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

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

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

√  是否准备好回退机制？

升级过程（部分）：

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

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

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

√ 网络连接是否正常；

√ 本地源是否最新；

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

升级完成：

√ 检查管理节点状态；

√ 检查计算节点状态；

√ 检查云主机状态；

√ 检查VPC路由器状态；

√ 检查存储节点状态；

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

对于高度复杂性事件，清单也是非常适用，但是需要做一些更改。

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

遇到这个报障，不妨试着考虑下，如果你遇到这个问题，该如何排查？需要排查的因子有很多，这种问题有着多种可能的原因，故障出现频率不高，而且监控未发现异常。

根据我们对于问题的定级，这种问题属于高度复杂性问题，现象很简单，但可能导致故障的因素会比较多，排查会比较复杂，可能要多次排查才能定位问题，。

首先，需要判断，给事件定级，不同级别的事件，触发的清单内容是不一样的。

其次，在处理高度复杂性问题的时候，需要设置提示清单，要将问题同步给不同职能的人共同完成，复杂性问题的清单不仅仅是关键性步骤，更重要的是一个沟通清单，以确保在每个领域的各个专家们是在以一个团队的形态去应对问题，因为团队犯错的几率比单个人要小很多。部分清单内容如下：

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

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

√ 监控告警是否触发；

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

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

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

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

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

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

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

网线等所有问题；

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

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

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

医生、飞行员和运维面对的工作其实有很大的共同点，对于复杂性、稳定性和安全性，后两者关乎生命，要求显然要更高，清单在这两个行业也有重度的使用。

我们的身体能够以13000多种不同的方式出问题。在ICU，每位病人平均24小时要接受178项护理操作，而每项操作都有风险。

——阿图 · 葛文德《清单革命》

“我们的身体能够以13000多种不同的方式出问题。在ICU，每位病人平均24小时要接受178项护理操作，而每项操作都有风险。“ 医疗行业的例行程序异常复杂，医护人员犯下这样或那样的错误是不可避免的。在压力重重的环境中，即便再优秀的医生也难免漏掉其中一个步骤、少问一个关键问题，以致在医疗过程中出现失误。

清单会提醒我们不要忘记一些必要的步骤，并让操作者明白该干什么。这不仅是一种检查方法，而且还是一种保障高水平绩效的纪律。我们来看一个案例……

这个试验的结果非常令人震惊，一张小小的清单，让约翰·霍普金斯医院原本经常发生的中心静脉置管感染比例从11%下降到了0；15个月后，更避免了43起感染和8起死亡事故，为医院节省了200万美元的成本。

清单从来都不是大而全的操作手册，而是理性选择后的思维工具。抓取关键，不仅是基准绩效的保证，更是高绩效的保证。

下面是世界卫生组织手术安全清单，一共由19个检查项目组成，在实施麻醉前有7个检查项目，在切开患者的皮肤前，手术团队还要进行7项检查，在手术结束后患者离开手术室前还要进行最后5项检查。

当然，手术的整个过程远不止这19个，但清单能够化繁为简，用为数不多的检查项目确保一些重要的步骤没有被遗漏，另外还能够使用沟通清单来确保手术团队成员切实进行团队合作，确保他们对手术中可能发生的问题进行了讨论，并为此做好充分的准备。

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

清单在航天业使用也非常广泛，每当你乘坐波音飞机出行的时候，都有一整套方法掌控着飞行员驾驶飞机的方式。

比如，在飞行各阶段必须完成的动作或检查项目有哪些，哪些是必须亲自完成的，哪些可以交给计算机去完成，在碰到意外情况的时候应该如何应对。

这套方法浓缩为大概有200多页的手册，手册内是由许许多多不同类别的清单组成的。

每一张清单都非常简洁，一般只有几行字，用大号的、容易识别的字体印刷。每张清单都是针对特定情况制作的，所以这本厚厚的手册涵盖了飞行各个阶段可能出现的各种状况。

比如正常操作的检查清单，上面列出了飞行员日常操作所需完成的主要动作以及需要注意的重要事项。

飞行员在每个操作阶段，如启动发动机前、飞机被推出前、开始滑行前等，都必须按照清单逐一完成各项检查。

除了日常的检查清单，还有紧急情况的应对清单，设计人员列出了他们能想到的所有紧急情况，如驾驶舱冒烟、各种警示灯亮起、无线电失灵、副机长无法操作、发动机失灵等，并为应对每一种情况设计了正确的操作流程。

手册涉及的很多紧急情况飞行员可能一辈子都碰不到，但万一碰到的话，他们就能依靠清单来化解危机。

当然清单制定的优秀与否，操作人员是否当时严格按照清单步骤实施，操作人员的素质也影响了最后的结果，但清单至少提供了这样一个安全规范的指引。

一张小小的清单，让约翰·霍普金斯医院原本经常发生的中心静脉置管感染比例从11%下降到了0；15个月后，更避免了43起感染和8起死亡事故，为医院节省了200万美元的成本。

——阿图 ·葛文德《清单革命》

举个例子，2008年1月17日，英国航空公司的38号航班迫近伦敦，准备降落。这架飞机是从北京起飞的，已经飞了将近11个小时，机上载有152人。飞机下降到220米高度，距离机场还有3公里远。

此时，飞行员需要稍稍增加推力以减小飞机下降的速度。但突然之间，无论他怎样用力推油门杆，发动机就是没有任何响应。

之后，整架飞机就像一块重达160吨的大铁砣一样重重地向地面砸去。索性的是事故最终没有引起任何的人员伤亡。

2008年9月，美国联邦航空管理局发出了厚厚的调查报告，详细说明了在跨越极地飞行过程中，飞行员应该如何防止冰晶在油箱中聚积的操作规程，还说明了当发动机失去动力后，飞行员应该如何恢复动力的操作程序。

如果新知识没有被系统地转变为简单、实用的操作方法，那么并不意味着飞行员的实践会立刻发生改变。

波音公司团队花了一个月的时间，不断筛选和精简检查项，不断推敲如何设置检查点，最终将这个厚厚的报告转变为了实用的极地飞行清单。

2008年11月26日，相似的事故再次发生，达美航空公司的一架波音777客机从上海飞往亚特兰大，机上载有247人。飞机飞临蒙大拿大瀑布的时候，飞行高度是12 000米。这时候，2号引擎突然失去动力。但这次飞行员根据清单上列出的步骤进行操作，最终发动机恢复了工作，拯救了247人。

清单在大公司里的日常工作能起到什么样的作用呢？当时谷歌有一个氧气项目，这个项目对谷歌未来也产生了极为深远的影响，项目最初的目的是为了证明经理的存在没有太大意义，最后却证明优秀的经理很重要。他们是怎么做的呢？

乍一看，如此事无巨细似乎有点把成人当成孩子看了。但是要记住，并非每个人都天生有做经理的本事。告诉经理具体该怎么做，他们就可以划掉待办事项中的一项非常烦人的工作。他们需要思考的事情减少了，转而可以专注于行动。

最终，采用了电子邮件中给出的行动建议的经理，他们手下的谷歌新人达到全效工作的状态比同伴快25%，省下了整整一个月的学习时间。结果显示，检查清单确实有效，即使这份清单简单得有些傲慢也一样。我们都是人，总有些时候忘记一些最基本的事情。

通过这个几个行业的案例，我们应该可以体会到，清单不是大而全的操作手册，而是理性选择后的思维工具，它能将够帮助我们在操作的每一步都尽力保持冷静而睿智的头脑，确保在必要的时候得到所需要的重要信息，系统地进行决策，在遇到复杂问题的时候，和每一个应该沟通的人进行充分交流，从而避免“无能之错”。

有人认为，整个事件是一个“黑天鹅”事件，其根本原因是极小概率出现的“磁盘静默错误”发生了。若磁盘静默错误没有发生，运维人员的上述操作也不会引发后面这些问题。

我认为，在此次事件中，人员违规操作虽然不是引发故障的根本原因，但却是扩大故障影响的重要因素。如果严格按照规范执行，就不会导致数据丢失无法恢复的问题。

背后的思考

清单思维为什么在各个行业都被验证是有效的，我们来看看清单背后的逻辑。

清单的设计背后是不仅仅是对事件的规划和对经验的总结，更是理性思考和深层次思维方式的体现。

诺贝尔经济学奖丹尼尔•卡尼曼在《思考，快与慢》这本书中，提出人类的思考框架由两部分组成，分别命名为系统1和系统2。

系统1，快思考，是简单，自然，迅速，没有感觉，其实可以说它算不上是一种思考，而更像是一种条件反射。

系统2，慢思考，它需要经过大脑的分析质疑思考评估反省等活动之后在作出具体的决策。

用系统1思考或判断是非常快捷的，因此人们往往第一时间通过它在脑海中形成观点。但有时系统1可能得不到结论或是得到错误的结论，因此人类也经常求助系统2进行更为复杂和费力的思考过程，以图补充或纠正系统1。

但是，上述说法不完全等于系统1是感性的、系统2是理性的。只是为了便于理解，我们本次的讨论可以大致给系统1和感性、系统2和理性之间划等号。感兴趣的同学可以读书深入了解一下。

实际上系统2经常受到系统1的影响。这种影响可能是正确的，也可能是错误的。而且系统2很懒惰，经常疏于校验，从而无法纠正系统1形成的错误。这时候清单的介入就会提醒系统2的介入。

从人类300多万年的进化历史看，7万年前才出现“认知革命”，由此发展出理性认知，而之前的300万年都是感性认知。

在大多数的时间段里，人类都是靠感性，也就是直觉在做决策，而理性的历史非常短。

我们日常生活中95%的行为都是由基因决定的自发式行为，大脑是需要上百万年才能够得以进化的，目前人类的大脑是为了解决前面300万年的进化时间段内，狩猎时期的人类所面临的生存问题。在那个时间内，人类必须是要快速决策，才能生存。

比如遇到一只豹子，第一反应就是跑，而不需要去思考计算我离豹子的距离，以怎样的速度和角度跑是可以成功逃脱的；同时使用系统2思考需要消耗的能量远大于系统1思考，对于能量获取极难的时代，很显然为了求存，系统2自然很难发展出来。我们现代，正常生活，95%的事情通过系统1就能解决，比如你可以一边开车，一边聊天，但是无法一边开车一边计算复杂的数学运算。

介于以上生物学的剖析，现时代，人与人之间差异的最大的原因是系统2到系统1的转化能力。

查理芒格在《穷查理宝典》中，也提出了双轨分析原则：

首先，理性地看，哪些因素真正控制了涉及的利益；

其次，当大脑处于潜意识状态时，有哪些潜意识因素会使大脑自动以各种方式形成虽然有用但往往失灵的结论？

前一种做法是理性分析法——就是你在打桥牌时所用的方法，认准真正的利益，找对真正的机会，等等。

后一种做法是评估那些造成潜意识结论（大多数是错误的）的心理因素。

简单来说，就是首先理性分析，然后完全用感性去决策，通过对比，通常发现感性所做的决策大多数是错误的，并能总结下来，评估出那些容易导致决策失误的心理因素，下一次在遇到这些情况的时候，就不做决策。

我认为这种分析法不仅适用于投资，还适用与其他工作和日常生活。清单的设置，就是理性的思考过程，提炼出容易忽略的点，规避人类思考机制的缺陷，减少大脑潜意识下的决策，引导大脑到使用系统2，从而更容易、更有效地做对事情。

系统2或者说理性思维的前提是思维逻辑，所以为什么说清单思维呢？清单实际是输出项，重要的是由于什么样的思维逻辑，产生出什么样的清单。

优秀的清单背后一定有其优秀的思维模型。

拿我目前在做的海外B2C公司的商城应用迁移上云项目为例，在这个项目的过程中，我依据了WBS思维模型的理念。

WBS(Work Breakdown Structure)，工作分解结构，跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。

我们首先以项目为视角，给迁移分为了四个阶段：准备阶段、实施阶段、验证阶段、上线阶段，确定每个阶段的时间区间、任务规划，责任到人。部分截图如下：

其次，确定迁移业务对象，分解业务到每一个应用，确定应用的运维负责人和研发负责人；

第三，以应用为对象，将工作分解到准备、实施、验证、上线阶段，对于每一个建立关键工作清单跟踪表。    

第四，跟踪小组每天跟踪应用工作进度，汇总到项目总进度，最终达成项目目标。

美国著名对冲基金桥水公司的创始人雷达利欧在《原则》一书中提出一般做事的五步思维。

1、有明确的目标。2、找到阻碍你实现这些目标的问题。3、准确诊断问题，找到问题的根源。4、规划可以解决问题的方案。5、做一切必要的事来践行这些方案，实现成果。

我们今天用两个五步连接起来，使用清单思维来考虑，一次性实现成果之后，这件事的关键步骤可能还不是最全的，我们需要不断验证、补充、再实践，让事件离100%正确越来越近，这一思路和PDCA的思维异曲同工。

第一可以让这件事情更正确地被做好，其次也是锻炼了理性思维能力，经过多次的刻意练习，系统2转化为系统1的效率会大大提高，清单对你可以越来越简化，毕竟1+1=2这件事情不需要清单来辅助思维。

看上去是事情做好了，其实是思维方式获得了成长，你再以这样的思维去学习新技术、新知识，避免一个个“无知之错”，获得进一步的成长。

卡罗尔·德韦克在《终身成长》中提到两种思维方式以及对于成功的意义，固定型思维，是重复性工作，一遍遍地重复证明自己的能力，成长遭遇瓶颈；成长型思维，建立在这样一种理念上，你的基本能力是可以通过你的努力来培养的。这不就是我们讲的清单思维么？

为了帮助你更好地理解这两种思维模式是如何工作的，请想象一下，尽可能生动地去想，你是一个年轻人，经历了非常糟糕的一天：

你去上一门对你来说很重要的课，而且你非常喜欢这门课。你的教授公布了期中考试成绩，你得了 C。你非常失望，等到晚上准备回家的时候，你发现自己的车上贴了一张违章停车罚单。你感到非常泄气，打电话给最好的朋友想要倾诉，但是却没有打通。

这个时候，你会怎么想？你会有什么样的感受？你会怎么做？”

请大家花30秒思考一下。下面公布一下答案：

固定型思维者的可能回答：1、2、3、4

成长型思维者的可能回答：1、2、3

不是说你必须拥有某种思维模式，而拥有另一种思维模式的人就会产生挫败感。

谁不是这样呢？糟糕的成绩、朋友或爱人的拒绝都不是什么开心的事，没有人会喜欢这些糟糕的事情。只是这些有着成长型思维模式的人不会给自己贴上标签，或对自己失去信心。即使他们感到沮丧，他们也准备好了去承担这个风险，直面挑战，继续为此奋斗。

如果你的答案，匹配的是成长型思维者的答案，那么恭喜你，你很有可能已经具备成长型思维，如果匹配的是固定型思维者的答案，那么建议你遇到问题的时候，通过清单思维多锻炼你的理性思考，有助于你转变思维模式。

我们来做一个简单的测试，不要大家举手，只需要内心把答案选出。

回答以下关于智力的问题，阅读每一条并判断同意与否：

1．你的智力属于你比较基本的特质，很难做出很大改变。2．你可以学习新事物，但你的智力水平是无法改变的。3．无论你的智力水平怎么样，你总是可以大幅改变它。4．你什么时候都可以对你的智力水平做出根本性的改变。

问题 1 和 2 属于固定型思维模式，3 和 4 则反映出成长型思维模式。你更同意哪种思维模式呢？你可以是两种思维模式的混合，但是大部分人都倾向于其中一种。

1．你是某一种类型的人，基本没有什么可以改变这一点。2．无论你是哪一种人，你总是可以从根本上改变既定类型。3．你可以换一种方式做事，但决定你身份的最重要的特质并不会真正改变。4．你总是可以改变决定你身份的基本特质。

这里面，1 和 3 是固定型思维模式，2 和 4 反映出成长型思维模式。

假如你是固定型思维的话，就不容易发现问题，也不善于去解决问题，并形成迭代。你会觉得这样就好，如果没有强有力的外因推动作用，进步、成长速度就会相对较慢。

假如你是成长型思维，那么首先恭喜你，你善于发现问题，并具备优化问题、解决问题的能力。但还是需要一个工具来时刻提醒你，使用系统2去持续、正确的做好事情，并不断完善和迭代。

前面说到，我们通常花时间看了很多专栏，看了很多书，貌似懂得了很多道理，却依然所得甚微。我们通过DIKW模型来看看智慧是如何形成的。

数据：数据是事实、信号或符号的集合。在这种形式下，数据可能是原始、不一致或杂乱的。因此，这种数据没有用。

信息：信息是按一致的方式整理和 排序 的数据集合。信息形式的数据变得更有用，因为它很容易存储和检索。

知识：知识是信息及其相关上下文的集合。知识是处理一些信息的经验结果。

智慧：智慧是根据知识来选择达到目标结果的最佳方式的能力。通常是决策的原因。

从数据到智慧，纵坐标代表你所获取的内容量，横坐标代表你的理解力，如果内容量随着你的理解力程度的加深，会由数据到信息，到知识，最后形成智慧。也就是我们智慧不断形成的过程，实际是对数据做处理的方式由简单到复杂。

通常，在每家公司都会建立一个运维知识库，用于存放出现过的故障复盘总结以及一些技术分享、经验分享。这些内容是是很有价值，建立的初衷也是为了方便积累、回顾和反思，但这凑效么？我在和同行朋友的交流的时候，发现通常会有两个问题：

第一，这个制度很难坚持执行下去，积累大多是有的，但是回顾和反思却很少去做，这些内容都是以案例个体形式存在的而且通常内容较多，缺乏对过往所有故障事件的阶段性回顾、总结和提炼。

第二，即便是按照知识库建立的初衷那样认真的践行这一制度，也很少有公司对以往故障进行统计分析，将故障分类，找到同类故障的关键因素，提炼出简洁而有效的避免下次再犯同类错误的办法。由于没有建立清单思维来提炼和编制他们，他们就仅仅是信息，或者知识，并不能提供关键时刻用来决策的智慧。

清单对于处理好已有知识和学习新的知识，并将他们转化为智慧是非常有帮助的，实际也是促进系统2介入到思考模式中来的过程。

最后简单总结了几个清单设计的原则：

设置清晰的触发事件。也就是当遇到这些关键事件的时候，需要按照清单列出的项目执行检查程序。比如：在做监控告警设置阈值，设置通知人，时间点；遇到某种故障的时候，首先检查清单中列出的可能性原因等。

根据不一样的问题分级，选择不一样的清单类型，比如检查清单、操作清单、沟通清单。

清单需要简明扼要，不宜太长。内容主要是注意力容易跳过的但又是一旦跳过容易造成严重威胁的步骤。

用语精炼、准确，版式整洁，不能杂乱无章。

认真执行，在现实中检验，建立信任，并不断更新。

运维清单本质上是运维专家将其遇到的大量案例，进行梳理、总结、提炼出在各种场景下最关键的原则和关键点，是经验的传播，保证曾经成功过的方法和结果能极大概率的复制。

但清单内容再好，实际工作中不执行，便无法检验，也就无法指出清单内的问题，内容就无法更新以适合最新的情况，最终无法凑效。所以日常的训练和执行非常重要，通过执行获得检验和反馈，再根据反馈修改清单内容，最终获得最合适的清单。

当清单内容在实践中被证明是有效的之后，运维人员就会越来越能体会到它的好处。    

运维清单的力量是有限的，它不会列出具体的操作步骤，解决问题的主角毕竟还是人，但它能够帮助人们搞清楚哪些事情是最重要的，确保在必要的时候得到所需要的重要信息，使用“系统2”进行决策，并和每一个应该沟通的人进行充分交流，促进团队合作。

所谓的成功往往无法复制，因为因素并不单一，但成长却可以是终身的，我们可以通过制定不同情况下的清单，不断执行、检验、反馈、更新、再执行，一方面能够使运维工作不再是简单的重复，最重要的是实现成长型思维的刻意练习，强化主动性，实现运维人的终身成长。

总结

最后，我使用了dalio提出的五步思维模型，做一次刻意练习，来给今天的演讲做一个总结。

第一步：确定目标，运维人的成长，而且成长需要终身；

第二步：找到运维人成长遇到的问题，“无能之错”和“无知之错”；

第三步：找到这两个问题背后的原因，无能之错是在于人类的思考机制缺陷，终身成长需要成长型思维；无知之错在于缺乏有效的学习，形成长在大脑里的知识；

第四步：制定解决方案，学习、提炼思维模型框架，不断练习，并输出高质量的清单，形成成长型思维的转变

第五步：使用清单这一工具，在工作中不断积累、提炼、迭代，最终形成自己完善的思维模型框架，提升成长型思维，以此获得终身成长的前提基础。

回到标题，运维人的终身成长，从做好清单管理开始，谢谢大家！

说明：本文根据金霄老师在 GOPS 2018 · 上海站演讲整理而成。

参加完 GOPS 2018 · 上海站，还不过瘾？11月2-3日，还有另一场重量级大会在等着您！

DOIS 2018 · 深圳站震撼来袭！

更多精彩，点击 阅读原文