当车自燃了后我想到的关于 DevOps 的启示

关键点

• DevOps 和敏捷都鼓励那些有时让人感觉不太自然的思考方式，有些甚至和本能反应相冲突。
• 相对应的工作方式往往与已经在公司中运行起来的组织工作方式冲突。
• 这需要我们有意识的努力来克服认知偏差，在最大程度上发挥好我们和同事们的能力。
• “失败有百害而无一利”这样的意识常常会阻碍个人和团队不断学习和进步的能力。这样的观点可能是我们自己想出来的，也可能是从公司文化中继承下来的。
• 这篇文章中有五个关键点，全是由某一天作者小轿车自燃了的故事联想起来的……

这是一个真实的故事，来源于在 DevOps Days London 2016 上的一场对话。

那是个阳光明媚的春天，天气非常好，我们全家开着车从我的家乡布里斯托尔出发，准备出去度周末。车正开着，我听见妻子小声的说：“我闻到有烟味”。要知道我是个不错的机械工，我的旧车都是我自己组装的，只不过这一次开的车是新车而且刚刚保养过。我看了看仪表盘上的各项显示，一切正常。“肯定是外面的烟味”，我非常自信地回答。结果不到两分钟，滚滚浓烟就盖过了我的脚，我的皮肤有了非常强烈的灼热感。

我们从这件事中可以学到一些关于DevOps 的东西，以及许多其它规则。

不要让自己的专业经验成为阻碍

当人们把某些人当成某个领域的专家时，大家就会希望他可以对各种问题迅速做出回答。人的本性就是这样。本能的反应就是所谓的卡尼曼“系统1 ”: 一个比较快速的反应但实际上是没怎么经过大脑思考的。这种情况下会比较容易得到要处理的问题的最简单的答案，适合于战斗或者飞行的场景，但并不适合开会讨论的场景。与系统1 对应的是相对更理性的“系统2”，但需要比较长的时间才能得到答案。系统1 与系统2 之间的关系有些像发送到缓存与服务器的请求。尽管有的时候在缓存中拿不到数据后并不是查询服务器，而是直接返回所能给出的最快的答案。很多时候我们给出的最快的答案都是本能的、基于多年经验的，所以常常是正确的，当然有的时候也会失手。

在需要解决问题的场景或者动脑思考的工作中我们要学会多去质疑这种本能的第一反应给出的答案。比较有用的技巧是试着挑战自己一下去找找还有没有不同的答案，再和第一反应给出的答案对比权衡一下。如果我们总是采用第一反应的答案，就会忽略掉许多别人给出的有用信息，尤其是当我们认为别人的知识和经验都比不上自己的时候。

“知识的诅咒”提到了相似的挑战，就是一个领域的新手如何学习的问题。我相信这种“擅长做某些事情的诅咒”也是类似的，尤其是当我们承受压力时就会更加倾向于直接给出答案。

我们马上把车靠边停下，那是一个在布里斯托尔名声不太好的地方，非常乱。当我从车里出来的时候马上就围上来了一帮小混混：“马上把你的破车开走！这里不能停！”我只好回答：“你看，我的车着火了，得先让我家里人出来，然后我们再谈行吗？”结果他们的态度立刻来了个180 度大转弯。有一个说要去拿灭火器，另一个问还能帮什么忙。

我们能从这里学到什么？做为DevOps 的一员，我们的做事方法常常看起来标新立异、莫名其妙甚至会让人觉得受到了威胁。当那些年青人从车外看过来时他们并不知道车里发生了什么，他们只是看见一辆私家车冲到了他们的地盘上，然后有个陌生人很紧张的跳了出来。所以我就花些时间向他们解释了一下当时的情况。但当他们明白了我的处境（或者说这样做的原因）之后，他们就马上决定来帮忙了。

当人们明白你做事的原因后他们一般都会帮忙

当人们试图推行某些新技术（比如敏捷、DevOps 或者某项新技术解决方案等等）时我常常看到这样的场景。对于试图推行它的人来说，新概念新方案看起来实在是太完美了，优点也是非常明显，所以他们就常常没有向那些潜在使用者解释背景和动机。但如果人们无法理解或培养同情心，就往往会抵制新方案，或者轻率地继续延用旧的工作方式。

千万不能低估这种同情心的价值，它是双向的：如果做为新方案的推行人我们希望被理解、被倾听，那相应的我们也必须理解别人的感受和别人要承受的压力。

在我全家人都从车里逃出来之后，车里已经非常热，可以看见火舌不断从发动机罩下吐出，必须马上灭火了！我的灭火器是放在车的后备箱里的，可是这时后备箱却打不开了。地上已经有了许多一滴滴烧融化了的金属斑点，说明后备箱都烧着粘在车上了。我只好憋住一口气，钻进车里把灭火器拿了出来。火焰越烧越大，我马上撕开灭火器包装，立刻开始行动——看说明书。终于我拔掉了灭火器上面的插销，开始喷射，可是喷嘴又没对准正确的方向。当我最后转对了方向的时候，泡沫已经喷完了。

这就是我在最关键的时刻失败地使用最重要也是我非常不熟悉的工具——灭火器的经历，它给了我们一些对于意料之外情况的处理教训：

不要只是为灾难做准备，要迎接它并常常练习！

运维部门都特别擅长做灾难恢复计划，而且这也被认为是一件非常有用的事。但这正象那句在拳击界非常经典的话所说：“在脸上挨了一拳之前，每个人都说他自己早有计划”。通常大家关注的焦点在核心生产系统上，但只这样远远不够。辅助系统的负责人在某些公司是开发，在某些公司是运维，它的快速恢复也是非常重要的。有很多失败的系统恢复案例都是已经成功的把业务服务器恢复了，但却由于配置管理服务器或者部署工具服务器仍然不可用而导致不能继续恢复服务。最近Github 有一次停服，停服时间有很长都是在恢复他们的内部沟通服务器，他们必须要通过这个服务器来了解系统的运行状态，以及在紧急情况下进行合作。

我们给消防队打了电话，谢天谢地他们很快就赶到了，是个四人小队。他们立刻简单的交谈了几句，就分头行动了，有人拿出了合适的灭火软管，有人把交通疏导开，有人找到了消防栓，有人把人群疏散到了安全距离之外，然后水龙头一开，我的车立刻被就水龙淹没了。很明显即使我之前练习过如何使用灭火器，我所能做的也就是拖延一下时间而已。一个消防队员说：“你得知道火是从哪里烧起来的，是吧？你看它在发动机厢盖下面，很难喷到的。”

那为什么消防队员们这么擅长灭火呢？一个原因是他们会借鉴已有的经验，他们会为灾难场景做练习，而且演习得非常熟练。消防队员们学习也非常快，学习的方法之一就是研究失败的案例。

失败的案例也有很多可以学习的东西

西方文化似乎总是倾向于对失败的案例做大量的反思。DevOps 和敏捷运动则引导着新风向，认为成功和失败都是非常好的学习和改进机会。你应该已经非常熟悉根本原因分析、回顾、反思（并没有指责的意思）等等行为，这些都鼓励从最近的发生的事情和成就中学习改进。

我们也要反思一下自己对失败的态度。你是不是真的把它们当作学习改进的好机会？你总结的结果是不是只是在寻求自我安慰？我经常想起苏格兰山地自行车骑手Danny MacAskill 的故事，他会把一个跳起动作反反复复的练习，即使很多时候摔得非常重也继续练习，直到最后他完全掌握了这个动作。每一次练习，每一次改进，都使他朝目标更进了一步。

一个公司对待失败的态度实在太重要了，所以Westrum 的“企业文化拓扑”一文中甚至有一个单独的评估公司企业文化的指标，就是看它是怎样对待报信人（那些常常报告有事情没做成的人）的。当公司鼓励大家把失败的经历说出来时，大家也会自行反思失败的原因以及总结改进的措施，通常你会发现这样的公司效率都很高。

最后我们总算回到家了。我们都努力不要过多的回想这件事，以及猜想假如事情发生的过程有一点点不同最后会是怎样。我们向网上上传了一些图片，朋友们都对我们表示了同情，也有的开玩笑说反正都着火了不如就来个夏日烧烤趴吧！但几个月后，有另一位同款车的车主联系了我，他说这一款车在欧洲已经发生过好多次自燃了。这些车主彼此都不认识，但是实际上人数已经足够多了，足以组成一个集体来互相支持，足以引起生产商的注意，足以联合聘请律师，甚至足以促使生产商召回这款车。所有这些都是因为少数人分享了他们的自燃现场相片，而且有足够的刨根问底精神，最终把大家组织起来了。

如果事情很重要，就把它分享出来，你永远也不会知道谁会从中受益……甚至有可能就是你自己。

分享也是DevOps 的宗旨之一：分享知识、代码、指标、风格、方法和模式等等。不过我们常常分享的是自己感兴趣的东西，或者别人让我们分享的东西。我鼓励的是我叫做“故意分享”的行为。这样做的分享是因为它们可能会有趣，而不是要你把隐私公开，包括你尝试过的不成功的和成功的事情。科学研究一直以来都非常鼓励这样的行为，事实上很多边缘的发现最终都转化成了有用的成果。博客、看板、开放式会议等都是类似的非常好的分享实践。这些最后都对正在做的事情做出了有益的贡献。

这就是我的小轿车自燃的故事，以及我从中学到的关于DevOps 的经验了。事实上把这些经验多读两遍还是会非常有收获，甚至对IT 领域之外也是非常有用的，也是这些点让我不断地联想到DevOps 上。通过这个故事，以及社区的分享意愿，我们可能会学到一些对我们生活的其他方面也有意义的东西。

关于作者

John Clapham是一位私人教练、培训师及咨询顾问。他对持续提交、DevOps 和敏捷有相当丰富的经验，也曾帮助团队打造过非常成功的产品，营造了非常有效、高生产率和愉快的工作环境。他做软件开发的经验非常丰富，公司规模从初创到巨型都有，领域涉及出版业、电信业、商业、国防和公共服务部门等。如果他喝够了咖啡而布里斯托尔的天气又糟得他干不了其它事的话，他偶尔也会用帐号 @JohnC_Bristol 潜潜水，他公开的博客是 johnclapham.wordpress.com。

查看英文原文： The Things I Learnt about DevOps When My Car Was Engulfed by Flames