帮助盈利/提高文化/加速效率是DevOps实践的三大目标，上世纪八十年代在制造业领域展开的那场如火如荼的精益实践的变革还历历在目，而DevOps在软件领域将要或者已经掀起的风浪也是一模一样。web

然而最终这些许诺会压到开发团队那里，给本来就不太宽裕的项目进度狠狠地来上一刀。这些任务的每每兼具难度大/工期紧/经费少/人手不足等诸多明显标志，完成任务已是精疲力竭，至于技术债务，天然会进一步的积累不断升高。

Dev+Ops = ?

传统的Dev和Ops之间是割裂的状态，若是Dev和Ops一块儿造成了DevOps的方式后将会怎样?
产品负责人/开发/测试/运维/信息安全等相互之间再也不只是相互帮助信息共享，而是做为一个总体保证整个组织的目标实现。他们经过快速的对应，迅速地部署，实现了一流的稳定性/可靠性/安全性的系统服务。
在这里，跨职能的团队的合做并不只仅是为了实现用户要求的功能，他们保障的是：快速的对应在整个价值流中不会带来对内或者对外的混乱和困扰。安全

理想情况

测试/运维/信息安全等人员会一块儿工做下降摩擦而使得开发人员更有效率。经过给测试/运维/信息安全人员提供自动化的自助服务，过去那些必须各个团队的骨干在一块儿才能解决的问题经过这些工具和平台来实现，在每日的工做中，各个团队彼此之间倚赖性大大下降，这种状况下极大地提高了效率。
这使得一个小型的团队也可以快速独立的完成开发/测试/发布，将开发快速/安全/可靠地为客户作价值的转化。这使得组织可以最大化开发者的生产效率，提高员工满意度，在市场竞争中脱颖而出。这些是DevOps所带来的结果。架构

现实状况

而在更多的现实世界中，不存在一个总体，处处是割裂的碎片。
开发和测试是水火不容的，仿佛双方都是为了证实愚蠢的是对方而存在。
测试和信息安全行为的结合只是在项目的结束才会引入，通常都已经太晚基本上是走个过场，或者大致解决面上的问题。
留给咱们不少手工去处理的余地，以及这些不稳定性所带来的各类反作用。不只仅是交付时间变长，更多的是这些工做的质量每每是不可控的，由于在这种状况下，现实状况已经成为最终出场救火队员必须担负这些割裂所能带来的如同大厦将倾的趋势，在现实的世界中这些救火队员不断的扮演奇迹，可是也有不少不少的失败。成功的救火每每也能留下各类隐患，潜在以及时而出现的由此引发的问题给项目带来很大的影响，并且没法避免地影响到顾客和业绩。最终的结果就是，项目在短时间目标上的失败，整个组织对IT的各类不满，以及由此带来的预算收紧，同时众多面对各类变动和不可知的质量部署的郁闷和无助的运维人员。框架

解决方法

怎么办？须要改变的是工做的方式，DevOps给咱们指明了一条可行之路。运维

制造业的变革

为了更好的理解DevOps的变革，让咱们把目光投射到上世纪八十年代制造业的变革上。经过践行精益原则，制造业组织成功地极其显著地提高了生产效率，下降了交付时间，提升了产品质量以及客户满意度，成功的企业在残酷的市场中赢得了一席之地。
在这场改革开始以前，制造行业平均交付时间为6周，并且只有少于70%的订单可以按时交付。而到2005年，随着精益实践的普遍推行，平均交付时间已经少于三周，并且95%的订单可以按时交付。那些没能跟上的组织失去了市场份额，他们之中的不少最终被淘汰出局。svg

软件行业的变革

软件行业是如此的类似，在上世纪七八十年代，大多数项目须要一到五年才能实现完成开发和部署，常常伴随着极其高昂的成本，而失败也是会带来极其严重的影响和后果。
随着Agile的践行，新功能的开发已经降到周或者月为单位了，可是部署到生产仍然须要数周甚至数月，并且常常还会伴随灾难性的后果。
接下来随着软件和硬件的不断升级，带来了永不停息的服务的广泛实施的可能性，而Cloud更是将其全面推展开来。
DevOps的引入更是使得这些须要部署到生产的服务变成了以小时甚至以分钟计的寻常操做，不少企业在这轮变革中已经先行，部署对他们来讲已是平常和低风险的的做业。借助于DevOps，这些企业甚至可以在实际的环境下现行验证他们的Idea，以确认哪些Idea可以带来最大程度的效益，以此来决定所要开发的功能，而这些功能最终将很是安全地被部署到生产环境之中。工具

现代企业的挑战

时至今日，DevOps原则的践行已经在一日部署上百甚至上千变动。举个极端的例子Amazon在2011年天天大约可以完成7000部署，而到了2015年这个数字上升到了13万次天天。
跟上个世纪八十年的的制造业变革何其类似，这个时代的软件行业已经在变革。快速的市场对应以及不懈的探索和努力已经成为必备的要素。没法实现的企业注定要付出失去市场的代价。就像2016年DORA的DevOps调研报告的研讨会中提到的那样，你能够不相信那些看起来好像不太符合常规逻辑的速度，可是这些确确实实的发生在咱们的身边。学习

软件的纪元

这个时代，无论在哪一个领域中进行的商业竞争，对价值的交付最终都将依赖于科技价值流的实现。说得再简单一些，就像通用电器的CEO Jeffrey Immelt曾经说过的那样，“任何一个领域和公司，若是他们还不曾将软件引入到他们的核心业务，他们注定会被颠覆”。这不是危言耸听，技术对于任何组织都是用于赢得竞争一席之地或者生存下去的极为重要的工具。测试

问题的剖析

了解了全部的这一切，让咱们来看一下这些问题的征兆，以及为何会发生这些问题，为何没有强有力的干预，这些问题会随着时间变得愈发严重google

征兆：所在组织须要改善

大多数企业须要数周甚至数月的准备来部署他们的产品，他们也不能定例地低风险地交付部署新的功能特性，甚至他们中的不少都认为，这么快的部署需求自己就是一件很哗众取宠的事情。可是和当初制造业的变革同样，这场革命实际上已经无声无息地展开了，在这个时代快速和高水准的服务已是必要条件，已经有不少优秀的企业先行一步，掀起了变革的浪潮。没有危机意识的企业在上个世纪八十年代应该也有不少，没有奋起直追的大多数在那场变革中已经消失在滚滚洪流之中。部署只是海面上的冰山，从工具到流程，从组织结构到文化，有太多的环节须要注意，而改善也已经刻不容缓。

核心的固有冲突

几乎在每个IT组织中，开发和运维之间都会产生一个“下行的恶性循环”，使得产品或功能交付的时间增长，质量降低，更为糟糕的是那与日俱增的技术债务。技术债务是Ward Cunningham最初提出来的一个术语，像财务债务同样，技术债务描述了咱们所作的决策可能会引发的逐渐累积的问题，随着这些债务的不断增长，解决这些问题也会花费愈来愈多的成本和时间。
开发和运维的冲突源于隔阂，他们之间像是有着一堵无形的墙，正是这道看不见的隔阂产生了诸多的问题。产生隔阂的缘由在于分工和目标的不一样。组织目标细化的过程当中产生了在实际推行的时候相互制约的要素。具体来讲，企业须要实现快速，须要提供稳定服务。

开发团队为快速将产品推向市场做出努力，固然稳定和安全等也是必要的，在现实的世界中，这些更可能是做为非功能性要素不会出如今大多数的开发人员的视线范围，并且在大部分状况下这些也不是交付的要素。运维则须要负责稳定这个要素，两个团队，两个目标，两套KPI，相互冲突，不管是在这个地球的哪一个国家，相似的隔阂和问题都一直在出现。
制造业变革运动的奠定者之一的Goldratt将这种状况称之为核心的固有冲突（the core, chronic conflict）, 正是这种冲突带来了螺旋下行的恶性循环。

下行的恶性循环

这种螺旋下行的恶性循环产生在现实世界中每每有下面三个简单要素。

运维的技术债

运维的目标是保持应用程序和基础框架持续运行以使得组织可以交付服务给到最终顾客。可是因为应用程序和基础框架及其复杂，缺乏文档，以及难以置信的脆弱，这使得运维人员天天都必须面对和处理的事情。当咱们救火的时候老是想再抽空顺便就把这些个问题修复，可是一直没有抽到空，而这样的技术债务则在不断地增加。
并且，当这些日渐脆弱的系统所支持的是创造利润的关键业务时，问题会变得更加复杂，原本可以对应的问题也会由于担忧和忧虑以及没有非功能性机能的保障而信息不足。问题越积越多，一个小小的改动，最终均可能引发多米诺骨牌效应。因此每次只能最少限的修改，只能头痛医头，脚痛医脚。CSA根本问题分析对应？分析后有钱改么？敢改么？这样的结果形成了你们每日都在接触到的现实世界的一幕一幕。

难以兑现的许诺

理想的项目，缺钱给钱，缺人给人，项目范围稳定，变动管理有序，在Q（Quality）C（Cost）T(Time)三角进行管理的经验丰富的PM也游刃有余。
而现实的世界是，不少项目是要钱没有，资源有限，根本无变动管理。即便是这样的项目也在抢着作的状况下，基于各类场景，不少难以兑现的许诺就这样被添加了。好比项目管理上称之为镀金的行为，实际的项目中每每是给强势的外部以真金白银的无底线自残。

最后一根稻草

螺旋下行的恶性循环还差最后一根稻草。只须要在来一点，每件事情都复杂一点点，每一个人都再忙一点点。一点一点，每一个人都变得愈来愈忙，工做时间愈来愈长，交流时间愈来愈短，任务列表越堆越高。每一个人的工做都和别人的工做紧密相关，一个小的动做均可能带来很大的失败，天然而然，对变动充满畏惧和排斥。工做须要更多的沟通/协调/批准，各个团队必须等待更长一点时间以确保所依赖的部分已经完成。扯皮和吵架变成为了自保的必备生存技能。
这种状况下，部署的时间愈来愈长，更要命的是，开始变得容易出问题了，而对这些问题的救火行为消耗了大量的时间和成本，使得本来能够着手对付那高垒的技术债务的最后一丝机会也丧失殆尽。到了这个时候，就是英雄辈出的时代，对待那基本上已经困难重重的系统，很是规的能力出众的我的或者小的团体的很是规的努力，保证系统可以运行的同时继续推高系统的技术债务，为下一次爆发提供了良好的条件。

为什么如此常见

这种状况对咱们来讲是如此常见，知道了下行的恶性循环是如何发生的，可是为何会这样广泛存在呢？
每一个IT组织都有快速和稳定两个相反的目标，最终造成了Goldratt所说的核心的固有冲突，为这种存在提供了基础。
另外还有一点，现代社会中，无论被意识到与否，各行各业的任何一家公司都是科技公司，科技在各个行业的渗透已经超出了大多数人的想象，思惟方式的转变势在必行。正如一位资深的软件负责人所言：“全部的公司都是科技公司无论他们本身认为他们本身在什么领域。一家银行也只是有着银行营业许可的IT公司而已。”在做咨询的时候，咱们也常常会跟客户说, 在这个时代，”Your software is not part of your business, it is your business”，其实都是同样的道理。是否最终的发展像Jeffrey Immelt所说的那样可能还须要时间的检验能够拭目以待，可是对任何企业来讲这都是一场输不起的赌博。

成本

在下行的恶性循环中的不少人，被迫面对怪兽通常的系统，那种忧郁/孤立无援/无助甚至绝望的心情估计只能是如人饮水，冷暖自知了，由此带给我的家庭的伤害也是没法估量的。可是这个世界花在IT上的成本确是清楚的。好比IDC和Gartner都曾发布过，2011年全球花在IT上的钱大致是GDP的5%，这个数字高达3.1万亿美圆。试想一下即便一个很小的比例与这3.1万亿一块儿计算，在经济上付出了多大的成本不言自明。

DevOps：更好的方式

与传统方式不一样，DevOps协调各个部门向着组织共同目标协同努力同时改善工做的环境和文化，正是由于如此，它才能在这么短的时间内获得了众多人群的青睐而获得了迅速的发展。

DevOps：打破下行的恶性循环

理想情况下，小型的开发团队也能实现本身的机能特性，在类生产环境中验证正确性，能将他们的代码快速安全地部署到生产环境。代码的部署是可预期的平常行为，部署再也不是必须等待到周五下班而后开始倒计时在周一开始以前必须完成的噩梦。运维人员终于能够在工做日进行例行的部署做业。而客户对此一无所知，只有在他们发现新的可用机能或者被修改好了的bug时，才会意识到部署的动做已经完成。
在整个过程之中，每一个操做都须要有快速的反馈，每一个人都能快速地看到他们的动做所带来的影响和结果。当变动的代码提交到版本库中以后，自动测试开始在类生产环境中运行以确认这次变动是否达到可以部署到生产环境中的标准。
自动测试帮助发现更多的问题而不致于留下不少的技术债务，经过自动测试的确认，发现的技术债务当即解决而不是等待往后再行处理。
不一样于传统的非黑即白的部署，通过测试的代码，能够早早的放到生产环境之中，除了内部用户和一些被选择的特定用户，其余全部用户均此时均不会意识和看到或者使用到此部分部署的机能，并且也不会被此部分功能所影响。这样在生产环境经过内测或者小部分用户的试行方式极大的提升了信息安全相关的保障。
即便出现问题，也能够快速回滚到上一个版本以免没法对外提供正常服务。整个部署是可控的，可预测的，可回滚的，低风险的。
相比于畏惧出错/重于惩罚的文化，高度信任和协做的文化更加被推崇。只有这样，有些问题点才会被提出来而不是装做不知道被藏起来。毕竟，咱们只有先看到问题才能去解决这些问题。同时即便当问题发生的时候，启动的也不是问题追责机制，而是无追责的过后反省或者检讨活动，不是为了惩罚某人，而是为了不下次一样的问题再次出现，组织级别的学习和成长使用这种方式不断展开。这是一个理想的情况，各类企业都在使用本身的方式去实现本身的DevOps。

DevOps：业务价值

正如DORA的DevOps调研报告中所提到的那样，经过对多达25，000职业技术人员的调研，发现践行了DevOps的高效能人员相比于低效者，在不少方面都展示出很大的优点。好比:

DevOps: 规模开发线性等效

当开发人员的数目增长的时候，因为规模效应所增长的沟通/协做等额外做业不可避免的对个体开发者产生比较明显的影响。就像人月神化中所解释的那样，当项目迟延时，增长开发者时，不但会下降个体开发者的效率，一样会下降总体的效率。
而DevOps则从另一个角度，告诉咱们，当咱们有合适的架构，合适的技术实践，合适的文化氛围 ，小的团队也能高效地完成做业。同时，大规模的团队也一样适合DevOps，正像google前管理者Randy Shoup在google中所观察到的那样，“数千人的团队，架构和实践依然能使得小团队像初创公司那样产生难以想象的超高效率”。
下面这张DORA在2015年作的调查结果清晰地展现了当人数上升时候践行DevOps的高效能人员所组成的团队依然可以保证着小团队的线性增加效率。

总结

DevOps不是橱窗里面的展品，也不是旧酒装新瓶的噱头。应该像上个世纪八十年代精益实践浪潮的优秀企业那样，认真思考组织的不足，努力修炼内功，踏踏实实地改进，像Google/Amazon/Netflix那样实践，在新的改革中抓住机会。

Referrence