DevOps 三步法前传：生厌离心

DevOps 四书之二的《DevOps 实践指南》对 DevOps 四书之首的《持续交付》做了理论上的拔高。

这种拔高，一方面是关联到精益的价值流理论和敏捷的以人为本社会化工作理论。另一方面是超出技术层面，涵盖理论、原则、实践，更加系统化，显得没那么有技术含量，使 DevOps 变得更流行，但也有点飘。

要搞 DevOps，首先要对过去的做法生厌离心。DevOps 的目标是：把事做好，按时下班，自由休假。激情所在，就是效能。

以下揉摘自《DevOps 实践指南》。

​

不尽如人意的现实：人困马乏

在现实中，系统经常被破坏，服务和产品总是不尽如人意，团队的潜力无法得到正常发挥；在现实中，开发和IT运维是对立的，测试和信息安全活动总是在项目晚期才进行，这导致即使发现了问题也来不及修复；在现实中，产品和服务交付中的关键活动往往全都需要手动操作和互相交接，我们总是要等待其他人的工作完成才能进行自己的工作；在现实中，特性交付的周期一次次被拖延，质量也频频出现问题，特别是与生产环境部署相关的部分，进而对客户和业务造成了负面影响。

结果，不仅是我们的工作无法按预期完成，整个公司也对IT部门的业绩不满意，甚至导致预算被削减，IT员工没有成就感，感觉无力改变流程及其结果。

填坑侠模式：事故与部署如影随形

大多数公司都不能在几分钟或几小时内完成变更需要的所有部署，往往需要几周甚至几个月的时间。他们更不可能每天在生产环境中做到成百上千次的部署，而是在以月甚至以季度为单位进行部署。对他们而言，生产环境的部署并不是日常工作，因此服务中断和各种事故总是与部署如影随形，“填坑侠”们总是前赴后继。

根本的、长期的冲突：地盘为王

在几乎所有的IT公司中，开发部门和IT运维部门之间都存在一种固有冲突，这会让公司业绩下滑，进而导致新产品和新功能的上市时间拉长、质量下降、服务中断时间增加，甚至导致技术债务量与日俱增。

“技术债务”这个术语是Ward Cunningham首次提出的。类似于金融债务，技术债务是指我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息。

开发部门和IT运维部门的目标是对立的，这通常是产生技术债务的一个因素。IT公司需要负责的事情很多，其中包括下面两个必须实现的目标：

对变化莫测的市场做出反应；

为客户提供稳定、可靠和安全的服务。

开发部门通常负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而IT运维部门则要以为客户提供稳定、可靠和安全的IT服务为已任，让任何人都很难甚至无法引入可能会危害生产环境的变更。这种配置方式让开发部门和IT运维部门的目标和动因之间存在巨大的冲突。

制造业管理运动的发起者之一Eliyahu M. Goldratt博士称这种配置为“根本的、长期的冲突”——公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现。

这种冲突造成了一种恶性循环，阻碍了业务目标的实现，不但波及IT公司的内部，而且还会影响外部。这些长期冲突常常导致技术工作者交付出质量低劣的软件和服务，打造出糟糕的客户体验，每天都要采用临时解决方案、应对紧急情况。以上情景在产品管理、产品开发、QA、IT运维和信息安全管理中不断上演。

恶性循环三部曲：负债前行，流血不止

大多数的IT从业者可能都对恶性循环三部曲很熟悉。

第一部曲开始于IT运维，我们的目标是让应用程序和基础设施持续运行，以便公司向客户交付价值。我们日常工作中的很多问题源于应用程序和基础设施过于复杂、异常脆弱、文档不完备。这就是我们背负的技术债务，这就是我们每天所处的工作环境。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来。

更令人担忧的是，我们最脆弱的组件正支撑着最重要的业务系统或者最关键的项目。换句话说，那个最容易发生故障的系统就是我们最重要的系统，也是所有紧急变更的中心。当这些变更失败的时候，那些最重要的公司承诺，例如客户服务可用性、营收目标、客户数据的安全性和财务报告的精确性等，就会直接受到危害。

第二部曲始于有人必须去弥补最近未兑现的承诺——这可能是某个产品经理承诺了一个更大规模、更大胆的吸引客户的功能，或者是业务主管设置了一个更高的收益目标。然而，他们无视技术能实现什么不能实现什么，以及到底为何没能兑现之前的承诺，而是让技术组织按照新的承诺交付成果。

结果，开发团队被指派去做另一个紧急项目，这个项目必然需要解决新的技术难题，需要利用各种捷径以赶上承诺的发布日期，而这又导致了技术债务的增加——此时我们又承诺一有时间就处理这次产生的所有问题。

在这样的背景下，我们进入了第三部曲，也就是最后一部曲。在这里，所有事情都变得更加困难——所有人都越来越忙，工作所消耗的时间越来越多，沟通变得更加缓慢，工作积压得越来越多。我们的工作耦合得更加紧密，即使是很小的行动也会导致较大的事故，我们更加害怕和拒绝做出变更。工作需要更多的沟通、协调和审批；团队必须等待更长的时间，等待相关的工作完成；我们的工作质量持续恶化。车轮开始嘎嘎作响地缓慢移动，要想使之继续转动，就需要付出更多的努力。

尽管当我们身处其中时很难察觉到，但是当你退后一步，就会发现这个恶性循环是显而易见的。你会注意到产品代码部署消耗的时间更长了，从几分钟到几个小时，再到几天或者几周。更糟的是，部署的效果越来越差，这导致客户服务中断的次数越来越多，需要运维部门来救急，而他们也因此无法偿还技术债务。

结果，我们的产品交付周期越来越长，做的项目越来越少，项目目标也越来越小。而且，对所有人工作（尤其是对来自客户的反馈信号）的反馈越来越慢，且越来越弱。不管我们做出怎样的尝试，事情似乎总是变得越来越糟糕——面对日新月异的市场竞争，我们不再能够快速响应，也无法为客户提供稳定、可靠的服务。我们最终因此失去了市场。

我们反复地看到，一个IT做得失败的公司，整个公司也都是失败的。正如Steven J. Spear在The High-Velocity Edge一书中指出的，无论破坏“像消耗性疾病一样慢慢地发展”还是迅速得“像大火焚毁般……其毁灭性都是一样彻底”。

活在无能为力的系统中：失心失人

困于这种恶性循环中多年，特别是那些处于开发下游的人，经常感觉被困在一个注定失败的系统中，无力改变结果。伴随这种无力感的是倦怠感，还有疲劳、愤世嫉俗，甚至是无助和绝望。

许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事——我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚、失败或危及生存而不敢做正确的事。这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。

对于我们的员工而言，这意味着长时间工作、周末加班、生活质量下降，而且影响的不仅仅是员工，还有所有依赖他们的人，包括他们的家人和朋友。当这种情况发生时，我们失去最好的员工（除了那些因为责任感和义务而觉得不能离开的人）也就不足为奇了。

除了人们在当前这种工作方式中受煎熬之外，我们能创造的价值的机会成本更令人震惊——作者认为，我们每年错失创造约2.6万亿美元价值的机会，在撰写本书时，那相当于世界上第六大经济体法国的年经济总产值。

DevOps的准则：保护人类同胞，总有更好的方法

前面描述了根本的、长期的冲突带来的问题和负面影响，从无法实现公司目标，到对人类同胞造成的损害。通过解决这些问题，DevOps能够提高公司业绩，实现开发、QA、IT运维、信息安全等各职能技术角色的目标，同时改善人们的境遇。