2017年度的DevOps最新现状研究报告最新出炉，这份由Puppet牵头DORA（DevOps Research Assessment）主导的报告已经成为每年获取DevOps最新研究现状的权威资料。今年从这份长达53页的报告中又能有哪些收获和感悟，让我们拭目以待。

Dora

Jez Humble和Gene Kim位列其中，为这份报告的权威加上了足够的注解。而Dora也正是由这二位和 Dr. Nicole Forsgren共同创立的。

Dora的Sponsor和参与企业有HPE/Splunk/Amazon/Atlassian等

内容概要

如今，作为一种已经被接纳和理解的一组文化价值和实践的集合，DevOps已经被证明能够帮助各种体量的组织改善软件发布以及质量和安全，同时能为产品的开发提供快速的反馈。在过去的六年中通过对超过27000份DevOps调查反馈，有了足够的证据去证明DevOps实践推动了IT的更高效能。而更高的效能则改善了生产性，利润和市场份额。

今年，研究同样发现了DevOps所能带来的不仅仅是财务上的改善。所有的组织，不管是盈利组织还是非盈利组织，不管他们的使命是什么，通过实践DevOps都能在实现目标的过程中有所改善。

通过对领导者如何高效地影响技术实践和流程改善以实现更好的IT和组织效能方面进行研究，同时发现自动化是各个组织之间效能不同的关键要素。而在应用架构以及组织结构构成是如何影响软件开发和交付方面同样也做了更加深入的研究。

六大主要发现

变革型领袖体现出文化塑成的五个维度

在塑成高效能企业文化方面，五个维度的共性要素能够极其有效地帮助企业文化转型。 愿景, 启发性沟通, 智能激发, 支持性的领导力, 相互间的认可：这个五个共性要素与形成高效能企业文化有着紧密的联系。高效能团队在这些要素方面表现都非常好，而这些也是其与低效能团队的显著区别。

高效能团队持续保持更快的速度和更好的稳定性

与去年相比，随着低效能成员改善部署频率以及缩短交付实践的变化，高效能成员和低效能成员在产出方面的差距在缩小。然而，低效能成员在故障的回复时间和失败率上明显偏高。研究认为这是快速部署的压力更多的造成了低效能者对构建质量的重视不足导致。

自动化给组织带来巨大福利

相比与其他团队，高效能成员所在团队通过自动化显著地提高了他们地配置管理/测试/部署以及变更审批流程。其结果是更多的时间和创新可以用在反馈回路中。

DevOps在所有的组织中得到了践行

今年通过研究组织的财务和非财务的指标，在愿意实现这些指标方面高效能者是低效能者的两倍。去年的研究也表明，不管是COTS（ commercial off-the-shelf software）还是部署在云端的微服务，都可以进行DevOps实践来实现更好的效率。而今年，如何在DevOps的世界里重新审视COTS，更加深入的指导原则被引入了进来。

松耦合的架构和团队在持续交付方面表现更好

为了达到IT高效能之路，在架构上迁移到松耦合的服务，组织上转换为松耦合的团队是一个好的开始。松耦合的服务使得服务之间能够独立的进行开发部署而不相互影响。而松耦合的团队则能使得对变更对应更加有效。对那些从创意到产品之间需要很多手工处理和审批流程的企业，这种转变需要不少投资。而松耦合的服务和团队带来的益处也是显而易见的：更多的产出和更好的质量与稳定性。

精益产品管理驱动更好的组织效能

精益产品管理实践帮助团队更加高频地交付客户真正想要的特性。这个快速的交付回路使得团队可以进行尝试，与客户之间创建一个反馈回路。而这个结果则是整个组织的收益，可以从利润/生产性/市场份额上予以衡量。

采样分布

过去的六年中，对IT职业从业人员/开发者/决策者等进行了超过27000份的调查问卷，涵括了当今最复杂的DevOps实践。而今年超过3200人参与了这项调查。

区域

采样的地域多数取于北美和欧洲，二者之和超过80%。

行业与规模

科技与金融撑起半壁江山，而零售/通信/教育/医疗/政务/健康/保险/制造等主要行业也达到40%左右，整体行业均有涵括。

2000人以上的大型公司占到41%，100-2000人中等公司占比35%，100人以下的小型公司22%，另有2%状况不明。整体来说各种规模构成均有研究。

关于系统规模，2000台服务器以上的大型系统占比29%，100到2000台服务器构成的中型系统占比38%，100台以下的小型系统占比20%，各种系统规模也均有涵括。

DevOps团队

随着DevOps理念和实践的不断推广，与DevOps团队相关的工作人员也开始逐年明显地递增。

变革型领导力

变革型领袖所体现出地领导力非常之重要，根据gartner的预测，到2020年，近半数没有进行团队能力转型的CIO都将会被他们组织中的数字化信息领导团队所取代。

这是因为领导力确实在发挥着重要的作用与影响。一个好的领导者能够影响团队如何更好地交付代码，设计好的系统架构，践行精益原则等。而所有的这些都会直接影响那些肉眼可见的指标比如利润/生产性/市场份额。而非盈利型的组织不会考虑利润，但是领导力会影响到客户的满意度，效率以及实现组织目标的能力。

而今年令人兴奋的一项研究则是聚焦在调查那些帮助驱动高效能的领导力的特性。而这一点是在DevOps中一致被我们所忽视的话题之一，虽然变革型领导力在很多地方都已经体现出其非常重要比如：

• 创建和支持高效和互信的文化规范
• 实施提高开发者生产效率的技术和流程，缩短交付时间，支持更加可靠的硬件设备
• 支持团队尝试与创新，更快地开发更好的产品
• 打破组织壁垒以实现策略协同

而最为共通的一个问题我们所听到的则是：什么时候领导才能到位？因为这样那些必须的变更才能有可能得到执行。每个人都知道，被赋予权利的领导可以调节资源以及预算等才有可能是的大规模的变革成为可能。领导者是为组织设定基调并强化其期待的文化规范的重要人物，取得其支持非常重要。

在今年的研究中我们使用了2004年Rafferty和Griffin所提出的变革型领导力模型的五个维度来分析研究，这个五个维度分别是：

• 愿景(Vision): 设立清晰的理念组织在5年之内将何去何从
• 启发性沟通 （Inspirational communication.）：即使是在一个不确定而且复杂多变的环境中，沟通也是鼓舞和激励的重要方式。
• 智能激发（Intellectual stimulation）：激发跟随者从一个新的角度重新思考问题。
• 支持性的领导力（Supportive leadership）：显示出对跟随者的考虑，照顾到他们的个人需求以及感受。
• 相互间的认可（Personal recognition）: 对工作目标的达成以及质量改善的表扬和承认，当别人工作很出色是个人对其进行赞赏。

通过对高中低的领导力在IT团队中的观察和研究发现，变革型领导力特质跟IT高效能有密切的关系。高效能团队这些维度明显比低效能团队做的要好。

在研究中触动较大的是：将变革型领导力进行分级，那些连合格级别的变革型领导者都缺乏的团队很难成为高效能团队，甚至成为高效团队的意愿都不强。虽然我们听到很多来自于底层的DevOps成功的事例，但是有强有力的变革型领导者支持的话，则更加容易获得成功。

另外一项分析也发现变革型领导力与员工忠诚度指标NPS（ Net Promoter Score ）也紧密关联。研究发现强的变革型领导所在的团队成员感到了更多的快乐和使命感，也更加的忠诚。变革型领导者对团队在技术实践和产品管理能力方面都有明显的影响。而这些正面或者负面的影响最终都会体现在组织的整体绩效上。

有趣的是，研究同时发现仅仅拥有强有力的变革型领导者还是不够的。通过对团队变革型领袖进行评比，在前10%的DevOps实践中，本来会以为着这团队整体应该都会表现地非常强劲有力，但是结果却并非如此，各种效能都有。因此，拥有变革型领导者很重要，但是这并非全部，仅靠这一点还是无法实现DevOps实践的成功。因为DevOps实践的成功还依赖于合适的架构，好的技术实践，精益管理原则的应用，以及其他很多一直在研究的因素。

总的来说，研究发现好的领导者通过使得团队对系统进行重构以及实施持续交付和精益管理实践，对创建强大的团队和组织以及技术产品起到间接的帮助。变革型领导力有助于实施那些与高效产出相关的必要实践，也能够协调和帮助不同团队的成员能够追逐组织目标时进行有效沟通。而这样的领导力构成了文化的基础，而在这中文化的氛围之中，持续的尝试和学习则成为了每个人日常工作的一部分。

研究中已然确认变革型领导者对实现价值改善流程和实践中的重要作用。但是变革型领导力不是孤立存在的行为或者一套新的实践方式，它只是放大了近些年来一直在研究的那些组织实践和技术实践的效果而已。

本次研究所采用的SEM模型（ structured equation model ）如下所示：

有五个维度构成的变革型领导力影响着持续集成和持续交付等实践不断实施，驱动精益产品管理实践进行团队尝试和反馈改善，从而正面影响团队IT高效能，进而预示着各种组织目标的实现。

IT效能和组织效能

如今，不管是为了增加业务利润还是创造社会效益，几乎每个组织都依赖与软件和IT去促进这些目标的实现。各种组织纷纷转向DevOps因为有越来越多的证据表明DevOps确实能够帮助软件更快跟稳更好（更少错误）的发布。

我们使用如下两个主要的维度来衡量IT效能：

• 吞吐量（throughput ）：用以衡量团队能够以一个怎样的频率实现从代码的提交到部署上线，这个是为了衡量多”快”
• 稳定性（stability）：用以衡量系统服务停止之后多就能够恢复以及变更成功率，这个是为了衡量多”稳”

这样DevOps混乱之源的开发(Dev)的”快”与运维(Ops)要求的”稳”都可以得到衡量。

在上一年的报告中，得到了高绩效者在吞吐量和稳定性方面都有着非常明显的优势。而在2017年，高绩效者的整体优势仍然存在：

• 吞吐量指标：部署频度：46倍优于低效者
• 吞吐量指标：代码提交到部署的交付时间：440倍优于低效者
• 稳定性指标：MMTR（mean time to recover from downtime ）：96倍优于低效者
• 稳定性指标：变更失败率：低效者的1/5

对比与2016年的研究结果，今年高效能者与低效者之间的吞吐量上的差距缩小,而稳定性指标的差距进一步拉大。研究认为偏重于提高速度而对质量和流程的重视和投入不够，而高绩效者理解而且在实施中两者兼顾，自然稳定和速度两者得兼。

2017年的比较数据如下所示：

只有与以前的数据相比进行分析才能真正了解到当前DevOps的实践现状。相比于2016年，部署频度的差距收窄，高绩效者保持着去年的水平，而低绩效者的水平明显提高。同样【代码提交到部署的交付时间】这项指标也是同样。这个变化不是说高绩效者做的没有以前好了，而是低绩效者在过去的一年中取得了长足的进展，是非常可喜的成绩。

与之相对的是稳定性指标，高绩效者在过去的一年中，在稳定性方面的优势不但没有缩小，反而进一步的扩大。这个优势使得他们更加地取悦于客户，能够花更多的时间在创新上，产品或服务投放市场更快，客户体验更好，对市场变化的反映能力更强。

吞吐量指标

部署频度

高绩效者今年与去年持平，而低绩效者大幅度提升，部署频度的差距收窄到46倍。但是值得一提的是像Etsy这样的公司平均每日部署80次而诸如Amazon和Netflix这样的公司每日部署上千次之多（生产环境中提供的服务有数百个结合而成）

代码提交到部署的交付时间

高绩效者今年与去年持平，而低绩效者大幅度提升，Lead Time的差距收窄到440倍。

稳定性指标

MMTR

MTTR： mean time to recover from downtime 。高绩效者的MTTR少于一个小时，而低绩效者则在一天到一周之间。相比去年，低绩效者的MTTR表现更差了。

变更失败率

高绩效者的变更失败率：0-15%，而低绩效者则为：31-45%。分贝取中间值分别为7.5%和38.5%，低绩效者变更失败的比率是高绩效者的5倍，此项指标的差距也进一步拉大。

自动化

在去年的报告中对重复作业以及计划外作业所花费时间的比较已经做了分析。今年，研究中又进行了细化，具体的确认了在各种实践中还有多少是手工作业多少是自动化完成的，比如在如下的实践中：

• 配置管理
• 测试
• 部署
• 变更评审

在分析中得到了一个很重要的结论，高绩效者的手工作业明显少于低绩效者，而自动化程度也明显高于后者。自动化是组织的一个重要红利，通过自动化，高绩效者的生产力更多地被解放用于实现那些能给组织带来更多价值的创新上，比如一个很好的例子是惠普公司的实践，他们通过DevOps实践，对自动化进行改善达到了非常好的结果。

高/中/低效能者手工作业的比率如下所示：

从中可以清楚地看到，无论是在配置管理和测试，还是在部署和变更审批流程上，高绩效者所进行地手工作业明显都低于低绩效者。

但是有一项研究数据稍微有点出乎意料地是中等绩效者却是比低绩效者做的手工作业还要多尤其是变更审核流程环节。而这一点同去年地一项研究数据也非常地合拍：中等绩效者比低绩效者在重复作业（rework）上花费更多地时间，尽管他们部署频度更高。到底这是怎么会发生的呢？

通过分析和研究，结论是：中等绩效者在加速自动化的过程中，可能会导致一个临时性的重复作业和手工作业都会增加的一个过渡性阶段。中等绩效者对自动化的投入已经很多也能看到效果，但是同时和会发现技术债务的积累也到了很高的程度，而正是这些技术债务在拖慢他们的节奏进入下一个更好的程度。结果就是加入了一些人工评审和手工作业进行弥补，而这些则明显拖慢了他们的速度。

增加这些非自动化的控制是能够理解的，但是这种诱惑这是希望组织能够去抵制的。这个阶段的最终目标是为了消除这些非自动环节带来的瓶颈。不过一旦这些技术债务得到偿还，更大程度的自动化便唾手可得。而中等绩效者的自动化改善环节自然能够提升到一个更好的程度。

组织绩效的附加衡量指标

多年以来，很多人都一直认为DevOps只是适合像Google/Amazon/Netflix这样的独角兽公司，而其他的并不一定合适。通过研究报告的共享，我们已经很大程度的改变了这种认知，现在主流的企业都认为DevOps能给给他们带来竞争上的优势。但是仍然有一种观念认为DevOps只是在那些以盈利为目标的企业（for-profit）中能够发挥作用，而那些非盈利（ not-for-profit）的机构诸如政府组织等的系统并不能发挥作用。

而今年的调查报告则显示高效精准地开发和交付软件的能力对包含非盈利企业地所有组织都是非常重要地一项指标。只要你想交付价值，不管你如何去衡量它，DevOps都是可以帮助到你的方法。

从2014年第一次开始发布研究报告以来，被问到的最多的问题就是如何把这些实践应用到诸如国防或者政府机构，大学等非盈利组织中去。因此，今年的调研报告关注更加在组织实现更为宽泛的组织目标上，也就是说，目标不在只限于利润和财务指标。而不管你是否去获得利润，每个组织都需要依靠技术去实现他们的目标：提供更加快速，更加可靠，更加安全的服务或者产品。研究则发现高绩效者在如下这些目标上能够取得两倍以上的优势：

• 产品或服务的数量
• 操作的效率
• 客户满意度
• 产品或服务的质量
• 组织和目标的实现
• 第三方参与者的衡量指标

研究发现这些不管实在什么样的组织和行业中都会发生。对任何类型的组织，不管所处那种行业，DevOps都能够帮助企业实现他们的目标，这是在今年的研究中所发现的。cloud.gov则提供了一个非盈利组织DevOps实践的案例。

技术实践

今天，DevOps已经被视作更快交付软件，获得更好的效率以及取得竞争优势的重要途径。而一些更加急切的用户则开始研究他们应该买什么样的工具，其实，更加重要的是这些技术上的实践，而这些实践才包涵着转向DevOps的初心所在。

而关于这些更为细致和共通的项目，研究也一直在继续：

• 版本控制实践
• 持续集成
• 基于Trunk的开发
• 自动化

而今年，增加了对技术架构和团队的结构的关注，同样会研究它们是如何影响组织开发和交付软件的能力的。

持续交付

去年，研究发现组成持续交付的实践：开发自动化，自动化测试，持续集成，基于Trunk的开发，所有构件的版本管理，这些对部署之痛，IT绩效以及变更失败率起到重要的作用。自然，最终会直接影响生产性/市场份额/利润等重要组织目标。

去年，研究使用上述实践组成了持续交付的模型。而今年的研究则使用了其产生的结果作为模型，在这个模型中，将会根据团队获取如下两项产出的能力对持续交付进行衡量的：

• 全生命期的按需部署： 团队能够在软件的全生命交付周期对产品或者最终的用户按需进行部署。
• 快速反馈回路： 团队的每一个成员都参与到对质量和系统的部署能力的快速反馈中，而对这些反馈所必须的应对则是最高的优先顺位。

而这些可以使得我们做两件很有意思的事情。第一，我们能够看出实现这些产出能够对IT绩效和部署之痛所带来的影响。其次，我们能看到那些要素最为影响这些产出，同时也能够研究一下诸如松耦合架构等所能带来的影响。

持续交付的五项影响要素

我们希望知道持续交付受那些影响要素的程度，研究发现如下五项要素都正面影响持续交付：

• 综合版本控制
• 持续集成和基于Trunk的开发
• 安全与软件交付的融合
• 测试自动化
• 部署自动化

在所有的要素之中，自动化测试则是最大贡献者。

另外，良好的架构对持续交付的影响也是今年重要的确认点之一，研究的结果也证实了架构对于实现高绩效的重要性。

架构

在过去的几年中，对架构与持续交付/IT绩效的关联已经做过了调查。而今年则进行了更深入的分析研究，发现创建松耦合的架构和团队对于驱动持续交付实践的能力有非常明显的作用。

通过如下两个方面来对服务和组件之间的耦合度进行判断：

• 可否做测试而不需要额外的集成环境
• 对象应用可否独立地部署或者发布而不必考虑其他的应用或服务

对于那些商用关联的COTS场景，对象环境中也确认了是否包涵COTS。

在2015年的调查报告中，就曾经发现高绩效团队的耦合度明显对于中低绩效团队。而这些对于应用程序的影响也是一样的。而今年，如下两项假定希望在研究中进行验证：

• 给予了更多权利，能够自主选择工具和实现的团队表现更好
• 松耦合的良好封装的架构能够驱动IT绩效

关于第一项假定，通过研究发现，相比较于强制地集中控制式的工具使用，能够自主选择工具的团队确实表现更佳。没有人比团队成员自身更清楚地了解什么样地工具能给他们带来更多地效率，给予团队自主选择的权利能够带来更好结果自然毫无意外。

第二项假定同样在研究中得到了印证。那些在IT和组织绩效上表现强劲的团队，大都使用了松耦合的系统架构，这样使得交付团队能够独立地进行测试/发布/系统变更而不必考虑和其他团队的额外工作/资源协调/审批等待/反复交流等，架构和团队的松耦合带来了确确实实的好处。

就像康威定律所描述的那样（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构），组织机构和软件架构的关系非常紧密，而在今年的研究之中，更多的则像是”逆向康威定律“：组织和团队从设计到部署都应该能够无需和其他团队进行过多牵扯精力的依赖而能够独立地完成他们地功能。

架构实践通过使用边界上下文（bounded context)和API作为Domain间解耦地重要策略，面向服务的架构应该注意解耦。实际上，有很多所谓的面向服务的架构都不能允许相互之间独立的测试和部署服务，因此团队无法获得高效率也是意料之中。

解耦非常重要，作为架构设计对持续交付的影响，出了前面提到的五大要素，在架构和团队解耦上有一些甚至比部署自动化等所起的作用都更大的要素存在，比如确认团队是否能做到诸如如下的事项：

• 对系统做大规模变更设计不需要团队外部某个人的批准
• 对系统做大规模变更设计不需要依靠其他系统或者为其他做很多特意的工作
• 无需和团队外的其他成员做细粒度的沟通和协调工作就能完成自己的工作
• 独立于其他服务或者产品，可以按需部署和发布自己的产品和服务
• 可以在业务时间内用可以忽略的系统downtime来完成部署

质量和安全

在去年的介绍中，发现高绩效者仅仅在重复作业和计划外作业就比低绩效者少花22%的时间，而他们能在新的特性开发等新的作业上多花29%的时间，而今年这个趋势和结果已然存在，而且新的作业上能够投入的时间的优势进一步加深，这两个数据分别变成了21%和44%。

基于Trunk的开发

去年，通过研究基于Trunk的开发在持续交付中所扮演的角色，我们的经验表明高绩效团队更多进行小批量的开发而不是长期存在的特性开发的分支。去年的调查结果表明如下开发实践对于提升交付绩效有好处：

• 每天合并代码到Trunk
• 使分支或者fork存在时间变短：通常为一天之内
• 少于三个同时实际进行的分支

同时研究也发现，团队不存在code lock也会对软件交付绩效有正向的影响。但是使用github推荐的workflow的一些开发者对此也稍微心怀疑虑，因为workflow推荐在分支上进行开发，而只需要阶段性的合并回Trunk。但是短时间存在的分支，及时合并回Trunk，至少以每日构件这样一个频度能使得持续集成的时间做地更加彻底。

而今天通过调查高中低绩效者所在团队分支存在时间，发现了如下情况：

• 高绩效者分支生命期最短，持续集成度也最高，分支存在和集成时间以小时计。
• 低绩效者分支生命期长，持续集成度也最低，分支存在和集成时间以天计。

而者也验证了去年地结果，作为推荐性地指导意见：团队应该避免分支活跃时间超过一天。如果需要花一天时间去合并和集成分支，这就是一个警示了，它提示你需要研究一下你的实践和架构了。

精益产品管理

去年关于产品管理的调查中，建立了一个从如下两方面的能力进行衡量精益产品管理模型：

• 将工作拆分为小块，而且使得其在整个交付流程中可视
• 收集，共享，改善客户的反馈

今年，研究将模型扩展到调查敏捷原则的影响：给予团队权利去创建和改变开发流程而不需要外部的审批。

将工作拆分为小块进行反馈和改善

精益产品管理实践会对IT绩效有着很好的促进作用，这其中就包含将工作拆分为小块，如何进行拆分，最小可用产品（MVP： minimum viable products）就是一个很好的实践，下面的这篇文章就介绍了相关的概念。

在软件开发组织中，拆分出最小可用产品非常重要，因为这样你可以最小的代价，使用诸如A/B测试之类的方法，在最小影响的范围内最快地进行用户信息收集和反馈。提供了软件进行精益实践的一个好的手段。

授权开发团队

很多号称敏捷开发的团队实际作业时遵从其他团队所做的需求而没有提出自己意见的权利，这个限制可能会带来很多实际的问题，而最终的结果则可能是产品不会取悦客户，也无法交付所期待的业务结果。

敏捷开发的一个重要目标是在整个开发的过程中都去寻求客户的真正需要，这使得开发团队能够得到重要的信息，但是如果不管开发团队发现了什么，他们都没有任何权利对需求进行改变，创新的能力将会被极大地阉割掉。

而今年地研究则发现团队试图使用新的Idea的能力是预测组织绩效的一个重要因素。

当然，授权不是让开发这可以做任何他们想做的Idea，而是需要和一直在不断改善的DevOps实践相结合才行。

总结

每一年的调查报告都会基于大量的数据给予DevOps的研究者以方向的指引。而在今年的报告中，通过数据，我们了解到DevOps不仅对追寻利润的企业有驱动作用，对政府型等非盈利的企业也同样有效。

而调查的结果也表明结论的一致和连贯性，在现在这个时代，软件对每个公司都变得越发地重要，而IT绩效也对组织地绩效变得愈加地重要，通过DevOps实践，更好地协调领导力，工具，自动化以及持续学习和改进地企业文化也变得越来越重要。

再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://www.cnblogs.com/captainbed

原文地址：https://www.cnblogs.com/firsttry/p/10243902.html