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

Dev+Ops = ?

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

理想状况

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

现实情况

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

解决方法

怎么办？需要改变的是工作的方式，DevOps给我们指明了一条可行之路。

制造业的变革

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

软件行业的变革

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

现代企业的挑战

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

软件的纪元

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

问题的剖析

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

征兆：所在组织需要改善

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

核心的固有冲突

几乎在每一个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的高效能人员相比于低效者，在很多方面都展现出很大的优势。比如:

项目	说明
部署效率	代码和变更部署频率：30倍
交付时间	代码和变更的交付时间：200倍
部署成功率	生产环境的部署成功率：60倍
生产性/利润目标	2倍以上
…	…

DevOps: 规模开发线性等效

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

总结

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

Referrence

参考文献	作者
The DevOps Handbook	John Willis, Patrick Debois, Jez Humble, Gene Kim

DevOps企业实践指南(1):DevOps能为我们带来什么相关推荐

DevOps企业实践指南(5): 第三条原则：文化
第一条原则体现了价值流的从左向右的流动,第二条原则是快速和日常的行为带来的从优向左的反馈.第三条原则聚焦于创造一个持续学习和持续实践的企业文化.而这些原则使得组织中的成员能够不断地积累知识和经验,而这 ...
DevOps企业实践指南(3): 第一条原则：流动
DevOps的三条基本原则:流动/反馈/文化.第一条原则(流动)需要达成快速平稳地从开发向运维的价值流动,从而更快的进行价值交付.在这个过程中,作为开发或者运维的局部目标被弱化,而开发和运维等协同所产 ...
DevOps企业实践指南(8): 安全机制
DevOps落地实践中,安全机制应该如何保证,这篇文章从当前安全状况调查解读开始,同时介绍了DevOps落地实践时应该遵循的原则. 安全问题现状 Kaspersky Lab对26个国家超过5500公司 ...
DevOps企业实践指南(4): 第二条原则：反馈
DevOps的第二条原则名为反馈,它存在于价值流的各个阶段的逆向过程中,通过反馈而使得工作更加安全和可控.而反馈的重要性在大型复杂系统中显现的更加重要,在故障出现最初端倪的时候就能检测到的能力对于一个 ...
阿里巴巴DevOps实践指南 | 为什么DevOps的必然趋势是BizDevOps？
简介:从精益思想出发,我们可以看到DevOps的必然发展方向,那就是向业务侧延伸.业务是产品开发和运维的源头,完整的价值流必须从源头开始.这不是预测,而是正在发生的事实编者按:本文源自阿里云云效团队 ...
《DevOps实践指南》——阅读笔记(长文告警)
DevOps实践指南 <DevOps实践指南>简介 Part 1--DevOps介绍简史第1章敏捷.持续交付和三步法第2章第一步:流动原则第3章第二步:反馈原则第4章第三 ...
devops实践指南_开发DevOps的实用指南：减少八卦的步骤
devops实践指南我的一个软件开发的朋友最近问我,如果我可以告诉他,他可以做什么亲自来鼓励更多的合作与理解的工作环境-一个与更一致建议从未来的社区的DevOps . 我们之间的对话很长,他的情 ...
DevOps转型陷阱与核心实践指南
本文转自微信号EAWorld.扫描下方二维码,关注成功后,回复"普元方法+",将会获得热门课堂免费学习机会! 2010年,我曾在IBM供职,开始参与DevOps相关的产品研发与实施 ...
DevOps落地实践及案例分享
银行业为了应对业务的快速变化.互联网层面不穷的业务形态和交易压力,IT"双态(或双模)化"无可避免,开始探索部分业务参考互联网的方式引入分布式架构,但对于银行业独特的强监管.高安全 ...

DevOps企业实践指南(1):DevOps能为我们带来什么