1.2 DevOps能带来什么

Dev 需要对开发负责，并且需要应对市场快速的变化、实现业务的需求。Ops 的重心则放在提供安全、可靠、稳定的服务上。为了使Dev和Ops更好地协作，已经有了很多方法和流程被提出，但是几乎在每一个IT组织中，Dev和Ops之间都会产生一些不好的因素，使得产品或功能交付的时间增加，质量下降，更糟糕的是出现了与日俱增的技术债务。技术债务描述了所做的决策会引起的问题。随着技术债务的不断增加，解决它所带来的问题也会花费越来越多时间并使得成本不断增加。

Dev和Ops之间到底因为什么产生问题？Dev和Ops，本来就像左手和右手，但在实际的项目之中并非如此，它们之间仿佛有着一堵无形的墙，正是这堵墙使得Dev和Ops产生了隔阂。产生隔阂的原因在于Dev和Ops的分工和目标不同。细化组织目标的过程中产生了在实际推行的时候相互制约的因素，具体来说，企业需要实现快速发展，同时也需要提供稳定服务。Dev为快速将产品推向市场做出了努力，当然稳定和安全也是必要的，在现实中，非功能性要素不会出现在大多数开发人员的视线范围内，而且在大部分情况下这些也不是交付的要素，Ops 则需要负责稳定这些要素。两个团队、两个目标、两套KPI（Key Performance Indicator，关键绩效指标），相互冲突，无论在哪个国家，类似的隔阂和问题一直都存在。

这不再是一个简单的技术问题，Dev的目标和Ops的目标，以及两者在组织层面上的KPI是不同的。在现实工作中问题到底是如何产生的呢？我们可以还原一下场景。

让我们从欠下的“账”（技术债务）说起，每个项目都难免有自己的“账”，Ops 的目标是为最终客户提供稳定服务。但是由于应用程序和基础框架极其复杂，以及复杂系统具有脆弱性，加之缺少文档，运维人员每天都需要面对一些计划外的“救火”任务。而“救火”的时候一般都会留下一些小的问题，“救火”人员总是想之后抽空修复这些问题，但现实是，他们往往因为没有时间或者忘记而导致这些“账”被束之高阁，如果是，他们欠下的“账”不断地增加。

而当这些日渐脆弱的系统所支持的是创造利润的关键业务时，问题就会变得更加复杂，本来能够应对的问题也会因为人们的担心和忧虑，以及没有非功能性要素的保障而使相关人员信心不足。问题越积越多，每一个小小的改动，最终都可能引起多米诺骨牌效应。所以每次只能进行最少量的修改。至于事后分析，结果很有可能是，在进行根本原因分析后发现修改的成本过高，无法实现。

“救火”已经让大家手忙脚乱，但是不收口的需求往往会点起第二把“火”。在IT行业中有一个被讲了很多年的冷笑话：需求的变化只有两种类型，第一种是从项目开始到结束一直在变；第二种是只变一次，项目开始的时候把需求打开，项目结束的时候把需求关闭，因为需求一直没有定，之间的变更都算作一次。

理想的项目是，缺钱给钱，缺人给人，项目范围稳定，变更管理有序，在 QCT（Quality、Cost、Time）三角进行管理的经验丰富的人员也游刃有余。而实际的项目是，钱和其他资源往往比预想的要紧缺，变更也很难管控，项目会存在很多压力，在这些压力之下，很多难以兑现的承诺可能就被许下了。

然而最终伴随着这些许诺的任务都会压到Dev那里，使得项目进度更加缓慢。这些任务往往兼具难度大、工期紧、经费少、人手不足等诸多不利因素，完成任务已经令人精疲力竭，至于技术债务，自然会进一步地累积。

这样只要每件事情都复杂一点点，每个人都再忙一点点，问题就会发生。一点一点，每个人都变得越来越忙，工作时间越来越长，交流时间越来越少，任务列表越堆越高。每个人的工作都和别人的工作紧密相关，一个小的动作都可能带来很大的失败，自然而然，他们便会对变更更加畏惧和排斥。工作中需要更多的沟通、协调、批准，每个团队必须等待更长的时间以确保所依赖的部分已经完成。

在这种情况下，项目部署的时间也越来越长，更糟糕的是，项目开发将开始出现问题，而对这些问题的“救火”行为耗费了大量的时间和成本，使得原本可以着手对付那高垒的技术债务的最后一丝机会也丧失殆尽。到了这时，能力出众的个人或者小团体的非常规的努力，在保证了系统能够运行的同时继续推高了系统的技术债务，为下一次问题的爆发埋下了隐患。

很多传统的IT组织将稳定和快速两个目标（就像油门和刹车）分别给予了Dev和Ops，并为其定下了 KPI。组织所做的事情只是等待冲突的出现，而组织真正的目标和最终客户的需求只好被选择性地无视。那么DevOps能解决这个问题吗？我们先对DevOps的现状进行简单了解。