背景介绍

我认为细致阅读DevOps年度调查报告，是DevOps领域的从业者和企业的必修课之一。今年的报告尤为精彩，一方面通过调研反馈进一步证明了DevOps实践正在被更多企业应用，并且显著提升了企业的IT效能；另外一方面，也详细分析了取得这些成绩背后的管理、技术、文化等因素，包括变革领导力的建设、架构的解耦、技术实践的应用、精益管理的促进等。想打造高绩效的组织，就需要整合以上的各个层面，形成相互支撑和促进的正反馈循环，并紧跟业界最佳实践持续学习和改进。

正可谓他山之石可以攻玉，相信对调查报告的详细解读和理解，会对你有所启发和帮助。

以下内容根据2017年6月14日晚，我在微信群直播的DevOps2017年度调查报告解读分享会整理而成，特地分享给大家。

直播开始

今天我们的分享主要有三个部分：

1.首先我会做一个简单的介绍，为什么我们要做这次线上分享的活动。


2.其次会分享本次关键的内容，对现状调研报告做一下解读。


3.然后我也会分享在DevOps领域，对持续学习和发展有帮助的一些内容。

为什么要做这次线上的分享

大家知道，在几天之前由Puppet和DevOps的研究与评估机构共同发布了2017年的DevOps现状调查报告。这份年度报告可以认为是在DevOps业界发展状态的一个风向标，我认为去细致阅读这么一份年度调查报告是在DevOps领域的企业和从业人员的一个必修课。

今年的报告还是比较精彩的，也有非常多的内容，它一方面通过一些调研的反馈，说明了DevOps的实践正在被更多的企业所应用，也显著提升了企业的IT效能。另外一方面也详细分析了取得这些成绩背后的管理、技术、文化的因素，包括变革领导力的建设、架构的解耦、技术实践的应用，还有精益管理的相关内容。在上周末由高效运维社区和DevOps时代很多的DevOps爱好者共同做了这个翻译和编辑，我们产出了一个中文版的现状调研报告，也希望通过这个文本的制作，帮助大家实现DevOps的转型和落地，成就更多高效能组织。

报告的内容还是比较多的，英文版的大概有50多页式，所以我们在想是不是可以通过一次线上分享的活动，提取出这个报告中的一些精华，试图通过比较短的时间帮助大家去快速理解报告里的核心内容。我把报告的内容做了一个比较大的思维导图，这里面大概有十多个部分。下面我会分别把每一个部分做一个深入说明。

现状调研报告的解读

1. 概述

概述部分提纲挈领的说明了一下报告里面主要的研究发现。

这个现状调研报告已经持续6年时间了，大概在全球范围内累计做了27000份有效调研的反馈，也证明了DevOps的实践确实能带来更高的IT效能。高效能的IT组织也实现了在生产力、盈利能力和市场方面的增长。

报告中总结，DevOps可以帮助任何规模的组织来实现三个方面的能力：首先是缩短软件的发布周期，第二是提升软件的质量和安全性，第三是在产品开发的过程中能够快速获取反馈的能力。这也是大多数企业在推进DevOps的时候要去给领导说明的问题，我们投入做这么一个事情，到底给组织能够产生什么样的变化，我觉得这三个方面总结得也非常到位。

今年的报告里有四个重要的发现，这四个部分是比以往更明确提出来的。

1.DevOps发挥的影响不仅仅局限于财务的业绩，对于那商业的组织和非营利的机构，都能够帮助他们去实现目标。

2.今年明确提出了有效的领导者可以通过影响技术的实践和过程改进，去提高IT和组织的效能。之前很多人在问，DevOps的推广到底应该是自上而下的还是自下而上的，今年的报告特别明确提出了有效的领导者能够帮助我们去提升IT的效能，但是也需要在技术层面的很多实践，两者共同的叠加，才能把DevOps实施好。


3.自动化是带来组织效能差异关键的因素


4.应用架构和组织结构，也影响了软件研发和交付的能力。

关于这四个部分，我们在后面的深入解读中对会逐一的进行详细的阐释。

在报告的概述部分还提出了六个亮点。

1.变革型的领导，对提高组织的效能是有非常大影响的。通过一些调研的数据，他会发现高效能的团队践行这些领导力的特征，能够比不具备变革能力的团队工作效率提升一倍。


2.像往年一样，今年通过统计的数据，会发现对于高效能的团队在产品的快速迭代和稳定性上可以兼得。我们知道对于衡量IT的效能主要有两方面度量的因素，一方面是代码的生产能力，包括团队代码提交的频率，以及提交代码部署上线的Lead time。另外一方面是系统的稳定性，包括对于系统故障修复的速度和变更的失败率。这两部分IT的效能从统计数据来看，高效能的组织基本上既能快速发布，又可以稳定发布，所以效率和稳定是可以兼得的。我在去年GOPS的大会上也做过一个演讲，这跟当时的分享内容基本是一致的。


3.自动化给组织带来巨大的福利。高效能团队的显著特征就是把配置管理、测试部署、变更审批流程等等一切有可能自动化的都自动化掉，省出来的时间用在创新和快速反馈上，这样能够进一步去提升我们资源的利用率。


4.DevOps适合于所有的组织，无论是财务的指标还是非财务的指标，高效能组织都可以达到预期目标的两倍，无论是商业的软件还是我们云端部署的微服务，DevOps都能帮助他们达到高效能，这个我们在后面也会详细展开。


5.松耦合的架构和团队是持续交付有利的预测指标。松耦合的架构是指服务可以彼此独立的开发和发布，松耦合的团队是指授权团队可以对服务进行独立的升级，这样的优势是松耦合造就了更高的生产力、更高的质量，还有更可靠的稳定性。



6.精益产品管理是推动组织效能提升的关键部分，包括能够更频繁的交付客户实际需要的功能，以及更快的交付速度。大家知道其实在精益里面有句话：在软件开发里面最大的浪费就是制造没有人使用的东西。所以我们应该遵从精益管理相关的思路，每次用小步迭代的方式去发布我们的产品，快速获取用户的反馈做持续的改进。这对我们提高IT的绩效也是非常关键的因素。


2. 统计资料

上面这张图给出了一个统计的数据，从事DevOps的专业人员的比例实际上是在逐年增长的。2014年大概16%，2015年是19%，2016年是22%，2017年已经到了27%，这也说明DevOps其实可以给大家带来实际的效果，在这方面已经达成了共识，并且越来越多的组织在从传统模式转换到DevOps新的工作流程，DevOps可以说是业界的一个趋势。

3. 变革领导力

下面我们重点谈一下跟变革领导力相关的话题。

经常有同学问，我们做DevOps到底是不是需要领导的支持，从我们的调查报告来看，当然这个答案是肯定的。为什么需要领导支持呢，因为有上层领导的支持，他能够有权力和预算来做大规模的变革，并且在这个转型的过程中提供正向的支撑，改变工程师群体的激励的措施，并且领导者实际上定义了一个组织的基调，定义基本的文化规范。

尽管很多团队做DevOps变革的时候是自下而上的，比如县做一些技术的实践，然后取得一些效果，但是实际上如果有上层领导的支撑，对于我们成功的推广DevOps是更容易的。

Gartner也做了个预测，到2020年，近半数没有完成团队能力转型的CIO会从数字化的转型小组离开。DevOps的推进不仅仅是工程师、架构师这个级别的事情，更是一个领导应该重视的事情，如果领导不去重视，实际上它很快业界的趋势相背离的。

什么是变革领导力？变革领导力就是指领导者能够通过调动员工的价值观和使命感，来激发和鼓励团队，达到更高的效能。如果有比较好的变革领导力能够有助于建立起组织里面高度信任的文化，能够更好的去推动相关实践的实施，支持团队的创新，并且能够实现跨组织更好的协作和协同。

从图中可以看出，对于变革领导力有五个主要组成部分。

1.愿景，对组织的走向有明确的概念。五年之后，团队要达成什么样的目标是非常清楚的。


2.鼓舞型沟通，采用一种鼓励和激励的方式进行沟通，尤其是在一个不确定的环境里。


3.智力激发，鼓励员工以全新的视角去思考问题。


4.支持型领导，设身处地的关注员工的个人需求和感受。


5.个体认同，表彰目标达成和工作质量的改进，亲自祝贺那些做出杰出贡献的同事。

我觉得变革领导力的很多部分还是非常有启发的，我经常讲，其实我们处在一个不确定性的环境里，周围的环境不确定，所以我们做事的方法实际上也是需要不断的改进和迭代的。尤其是DevOps是一个比较新兴的方法和技术，它会打破原有的我们做事的方法和习惯。如果在一个组织里所有的人都墨守成规，都是按原来的共事方式去工作，这样我们很难去获得一个有效的改进。所以对于一个领导来讲，他应该去鼓励『改进』的『行为』才能获得持续的提升。

从变革的角度来讲，有两种结果，有可能是成功，也有可能是失败的。但是我们在DevOps文化里面明确提出一点，免责的文化，建立要对失败相对宽松宽容的环境。我们其实不要惧怕失败，不要防止失败，而是说能够从失败中提取教训，优化我们的流程和方法，做持续的改进。所以说从领导力的另外一个角度来讲，要建立对失败的宽容的环境。

变革领导力是对领导的要求，我们要再问一个问题，是不是成功的转型只需要领导的一己之力就能完成？答案当然是否定的。我们知道DevOps很多的时候还是管理实践和工程实践的结合体，DevOps的成功还取决于很多技术性的工作，包括合适的架构设计，良好的技术实践，以及精益管理原则的善用等。这些东西共同的作用，才能真正做到自上而下和自下而上的良好结合，把DevOps推进下去。

这里我们补充一部分的内容，如何在大型企业里面推进DevOps的实施。

这张图显示了其中一种方式，首先是从企业级别认识到DevOps的重要性，开始要去立项做DevOps的事情，然后在工作组级和团队级开始采用一些实践，当这些实践逐步有些成果，成功之后，再把这些实践的成果总结提炼，变成组织级，以及最终向组织级做整体的推广。

这里面还有第二种推广的模式，先从团队级别做一个初始化的尝试，但是在做尝试的时候要通知我们的领导层知道我们在做DevOps的工作。然后在团队取得成功之后，逐步把成果做一个放大提炼，得到管理层的认可，最终完成整体的推广。

上面这个图是报告里提到的，经过反复验证得到的一个结构化的方程模型。最左边的方框指的是变革型领导力，刚才提到了五个因素。变革型领导力做得好，它可以促进我们中间部分的这些最佳实践，包括测试和部署的自动化、持续集成、主干开发、解耦架构和对团队授权等，是有促进的作用的。中间的实践部分，对持续交付和精益管理有促进的作用。精益管理又对我们IT的效能提升有促进的作用，IT效能提升最终会导致组织的效能提升。这个结构化方程基本解释了在报告里提到的很多要素，包括领导力、技术实践、精益管理、持续交付等等，说明了它们之间的联系和相互的关系。

4. IT效能和组织效能

从今年的调研报告来看，得出了一些结论，首先无论是企业还是公益型的组织，都依赖于软件和IT来实现他们的目标。事实表明，DevOps实践能够帮助他们更快更可靠和跟高质量的去交付软件。

我们看一下具体数据。衡量IT的效能，刚才强调有两部分因素，一部分是代码的生产能力，包括团队代码的提交频率，还有提交代码到部署上线的速度。另外一部分是系统的稳定性，包括系统故障的修复速度和变更的失败率。

我们从这个图中可以看出，对比2016年，2017年有很多数据指标发生了一些变化：

• 从部署频率的角度，高效能组织会比低效能组织快46倍；
  
  

• 从变更的前置时间来看，高效能组织会比低组织大概快440倍；
  
  

• 从故障恢复时间来看，高效能组织要快96倍；
  
  

• 从变更的失败率来看，高效能组织要少5倍。
  
  

对比2016年的数据其实还是有比较大的差别。首先，高效能组织和低效能组织在生产力方面的差距在缩小，高效能组织实际上依然还是在按这个业务的需求在交付代码，低效能组织部署的频率和变更的周期都会有相关的提升，证明其实所谓的低效能组织的IT交付的整体能力还是在不断前进的。但是从稳定性的角度来讲，两者的差距都在扩大，我们可以看到2016年大概是差24倍，2017年扩展到96倍。

为什么在这个部分稳定性的差距会变大？这里面可能会有几方面的原因。首先是低效能团队为了提高部署的速度，可能在内建质量上的投入是不够的。对于内建质量的投入不够，虽然发布很快，但是它的质量是不高的。最终的结果就导致了更大的故障和更多的服务恢复的时间。这就给我们一个启示，我们不能单纯去追求效率而忽略了稳定性。举一个例子，我在前些年也做过很多自动化测试相关的事情，也研发了很长时间的自动化测试框架。我们会发现一个问题，如果你做了特别好特别炫的技术，有很好的自动化测试工具，但是你没有把你的校验点做得很完善，那么即使你的自动化测试通过了，可能还会有一些隐藏的缺陷没有被发现。这样从领导的角度来看，你可能所有做的事情就白费了，因为你表面上在做一个很有技术性的工作，但实际上没有解决真正的问题，我们一定要避免这种情况。我们做DevOps其实也是一样的，很多组织在拼命的追求速度，但是追求速度的时候我们不能以牺牲质量作为一个前提，我们应该通过内建质量来获得速度与质量的双赢。

这页图展示了2017年调研的数据，组织可以分为三种类型：高效能、中等效能和低效能组织，这是用聚类分析方法来做的分类。可以看到对于高效能组织，他的部署频率是按需的，每天可能有多次的发布，对于每次发布的变更前置时间基本是小于1个小时的，对于故障的恢复时间也是小于1个小时，变更的失败率大概是0-15%之间，也是比较低的数值。从这个角度进一步验证了对于一个高效能组织来讲，他的效率和质量是可以兼得的。

为什么能有这么高的效率，前面谈到了自动化是一个组织里面巨大的福利或者法宝。对于自动化来讲，通过调研很多高效能的组织，发现在这些组织里面对于配置管理、测试、部署和变更审批里面，手工的工作比率都是比较低的。像表里列举的，大概20%到30%之间是手工的，其他大部分的工作量已经变成自动化了。

这里面他给出了一个案例，是惠普打印机的一个例子，大家可以看到这个图，从2008年到2011年之间变化的关系。在2008年的时候，这个团队大部分的工作消耗在一些处理分支代码、处理手工测试、处理线上问题等等低效的环节上，只有5%的时间可以用来创新。但是经过了自动化测试的加强，代码分支策略的调整，以及敏捷的研发模式，在2011年的时候可以达到40%的时间是用于创新。可以看到中间的浪费和手工重复低效的工作已经非常少，这是一个比较成功的通过自动化改善IT效能的案例。大家如果对这个案例比较关注，后面有时间我会再详细展开讲解。

原创：张乐

背景介绍

我认为细致阅读DevOps年度调查报告，是DevOps领域的从业者和企业的必修课之一。今年的报告尤为精彩，一方面通过调研反馈进一步证明了DevOps实践正在被更多企业应用，并且显著提升了企业的IT效能；另外一方面，也详细分析了取得这些成绩背后的管理、技术、文化等因素，包括变革领导力的建设、架构的解耦、技术实践的应用、精益管理的促进等。想打造高绩效的组织，就需要整合以上的各个层面，形成相互支撑和促进的正反馈循环，并紧跟业界最佳实践持续学习和改进。

正可谓他山之石可以攻玉，相信对调查报告的详细解读和理解，会对你有所启发和帮助。

以下内容根据2017年6月14日晚，我在微信群直播的DevOps2017年度调查报告解读分享会整理而成，特地分享给大家。

直播开始

今天我们的分享主要有三个部分：

1.首先我会做一个简单的介绍，为什么我们要做这次线上分享的活动。


2.其次会分享本次关键的内容，对现状调研报告做一下解读。


3.然后我也会分享在DevOps领域，对持续学习和发展有帮助的一些内容。

为什么要做这次线上的分享

大家知道，在几天之前由Puppet和DevOps的研究与评估机构共同发布了2017年的DevOps现状调查报告。这份年度报告可以认为是在DevOps业界发展状态的一个风向标，我认为去细致阅读这么一份年度调查报告是在DevOps领域的企业和从业人员的一个必修课。

今年的报告还是比较精彩的，也有非常多的内容，它一方面通过一些调研的反馈，说明了DevOps的实践正在被更多的企业所应用，也显著提升了企业的IT效能。另外一方面也详细分析了取得这些成绩背后的管理、技术、文化的因素，包括变革领导力的建设、架构的解耦、技术实践的应用，还有精益管理的相关内容。在上周末由高效运维社区和DevOps时代很多的DevOps爱好者共同做了这个翻译和编辑，我们产出了一个中文版的现状调研报告，也希望通过这个文本的制作，帮助大家实现DevOps的转型和落地，成就更多高效能组织。

报告的内容还是比较多的，英文版的大概有50多页式，所以我们在想是不是可以通过一次线上分享的活动，提取出这个报告中的一些精华，试图通过比较短的时间帮助大家去快速理解报告里的核心内容。我把报告的内容做了一个比较大的思维导图，这里面大概有十多个部分。下面我会分别把每一个部分做一个深入说明。

现状调研报告的解读

1. 概述

概述部分提纲挈领的说明了一下报告里面主要的研究发现。

这个现状调研报告已经持续6年时间了，大概在全球范围内累计做了27000份有效调研的反馈，也证明了DevOps的实践确实能带来更高的IT效能。高效能的IT组织也实现了在生产力、盈利能力和市场方面的增长。

报告中总结，DevOps可以帮助任何规模的组织来实现三个方面的能力：首先是缩短软件的发布周期，第二是提升软件的质量和安全性，第三是在产品开发的过程中能够快速获取反馈的能力。这也是大多数企业在推进DevOps的时候要去给领导说明的问题，我们投入做这么一个事情，到底给组织能够产生什么样的变化，我觉得这三个方面总结得也非常到位。

今年的报告里有四个重要的发现，这四个部分是比以往更明确提出来的。

1.DevOps发挥的影响不仅仅局限于财务的业绩，对于那商业的组织和非营利的机构，都能够帮助他们去实现目标。

2.今年明确提出了有效的领导者可以通过影响技术的实践和过程改进，去提高IT和组织的效能。之前很多人在问，DevOps的推广到底应该是自上而下的还是自下而上的，今年的报告特别明确提出了有效的领导者能够帮助我们去提升IT的效能，但是也需要在技术层面的很多实践，两者共同的叠加，才能把DevOps实施好。


3.自动化是带来组织效能差异关键的因素


4.应用架构和组织结构，也影响了软件研发和交付的能力。

关于这四个部分，我们在后面的深入解读中对会逐一的进行详细的阐释。

在报告的概述部分还提出了六个亮点。

1.变革型的领导，对提高组织的效能是有非常大影响的。通过一些调研的数据，他会发现高效能的团队践行这些领导力的特征，能够比不具备变革能力的团队工作效率提升一倍。


2.像往年一样，今年通过统计的数据，会发现对于高效能的团队在产品的快速迭代和稳定性上可以兼得。我们知道对于衡量IT的效能主要有两方面度量的因素，一方面是代码的生产能力，包括团队代码提交的频率，以及提交代码部署上线的Lead time。另外一方面是系统的稳定性，包括对于系统故障修复的速度和变更的失败率。这两部分IT的效能从统计数据来看，高效能的组织基本上既能快速发布，又可以稳定发布，所以效率和稳定是可以兼得的。我在去年GOPS的大会上也做过一个演讲，这跟当时的分享内容基本是一致的。


3.自动化给组织带来巨大的福利。高效能团队的显著特征就是把配置管理、测试部署、变更审批流程等等一切有可能自动化的都自动化掉，省出来的时间用在创新和快速反馈上，这样能够进一步去提升我们资源的利用率。


4.DevOps适合于所有的组织，无论是财务的指标还是非财务的指标，高效能组织都可以达到预期目标的两倍，无论是商业的软件还是我们云端部署的微服务，DevOps都能帮助他们达到高效能，这个我们在后面也会详细展开。


5.松耦合的架构和团队是持续交付有利的预测指标。松耦合的架构是指服务可以彼此独立的开发和发布，松耦合的团队是指授权团队可以对服务进行独立的升级，这样的优势是松耦合造就了更高的生产力、更高的质量，还有更可靠的稳定性。



6.精益产品管理是推动组织效能提升的关键部分，包括能够更频繁的交付客户实际需要的功能，以及更快的交付速度。大家知道其实在精益里面有句话：在软件开发里面最大的浪费就是制造没有人使用的东西。所以我们应该遵从精益管理相关的思路，每次用小步迭代的方式去发布我们的产品，快速获取用户的反馈做持续的改进。这对我们提高IT的绩效也是非常关键的因素。


2. 统计资料

上面这张图给出了一个统计的数据，从事DevOps的专业人员的比例实际上是在逐年增长的。2014年大概16%，2015年是19%，2016年是22%，2017年已经到了27%，这也说明DevOps其实可以给大家带来实际的效果，在这方面已经达成了共识，并且越来越多的组织在从传统模式转换到DevOps新的工作流程，DevOps可以说是业界的一个趋势。

3. 变革领导力

下面我们重点谈一下跟变革领导力相关的话题。

经常有同学问，我们做DevOps到底是不是需要领导的支持，从我们的调查报告来看，当然这个答案是肯定的。为什么需要领导支持呢，因为有上层领导的支持，他能够有权力和预算来做大规模的变革，并且在这个转型的过程中提供正向的支撑，改变工程师群体的激励的措施，并且领导者实际上定义了一个组织的基调，定义基本的文化规范。

尽管很多团队做DevOps变革的时候是自下而上的，比如县做一些技术的实践，然后取得一些效果，但是实际上如果有上层领导的支撑，对于我们成功的推广DevOps是更容易的。

Gartner也做了个预测，到2020年，近半数没有完成团队能力转型的CIO会从数字化的转型小组离开。DevOps的推进不仅仅是工程师、架构师这个级别的事情，更是一个领导应该重视的事情，如果领导不去重视，实际上它很快业界的趋势相背离的。

什么是变革领导力？变革领导力就是指领导者能够通过调动员工的价值观和使命感，来激发和鼓励团队，达到更高的效能。如果有比较好的变革领导力能够有助于建立起组织里面高度信任的文化，能够更好的去推动相关实践的实施，支持团队的创新，并且能够实现跨组织更好的协作和协同。

从图中可以看出，对于变革领导力有五个主要组成部分。

1.愿景，对组织的走向有明确的概念。五年之后，团队要达成什么样的目标是非常清楚的。


2.鼓舞型沟通，采用一种鼓励和激励的方式进行沟通，尤其是在一个不确定的环境里。


3.智力激发，鼓励员工以全新的视角去思考问题。


4.支持型领导，设身处地的关注员工的个人需求和感受。


5.个体认同，表彰目标达成和工作质量的改进，亲自祝贺那些做出杰出贡献的同事。

我觉得变革领导力的很多部分还是非常有启发的，我经常讲，其实我们处在一个不确定性的环境里，周围的环境不确定，所以我们做事的方法实际上也是需要不断的改进和迭代的。尤其是DevOps是一个比较新兴的方法和技术，它会打破原有的我们做事的方法和习惯。如果在一个组织里所有的人都墨守成规，都是按原来的共事方式去工作，这样我们很难去获得一个有效的改进。所以对于一个领导来讲，他应该去鼓励『改进』的『行为』才能获得持续的提升。

从变革的角度来讲，有两种结果，有可能是成功，也有可能是失败的。但是我们在DevOps文化里面明确提出一点，免责的文化，建立要对失败相对宽松宽容的环境。我们其实不要惧怕失败，不要防止失败，而是说能够从失败中提取教训，优化我们的流程和方法，做持续的改进。所以说从领导力的另外一个角度来讲，要建立对失败的宽容的环境。

变革领导力是对领导的要求，我们要再问一个问题，是不是成功的转型只需要领导的一己之力就能完成？答案当然是否定的。我们知道DevOps很多的时候还是管理实践和工程实践的结合体，DevOps的成功还取决于很多技术性的工作，包括合适的架构设计，良好的技术实践，以及精益管理原则的善用等。这些东西共同的作用，才能真正做到自上而下和自下而上的良好结合，把DevOps推进下去。

这里我们补充一部分的内容，如何在大型企业里面推进DevOps的实施。

这张图显示了其中一种方式，首先是从企业级别认识到DevOps的重要性，开始要去立项做DevOps的事情，然后在工作组级和团队级开始采用一些实践，当这些实践逐步有些成果，成功之后，再把这些实践的成果总结提炼，变成组织级，以及最终向组织级做整体的推广。

这里面还有第二种推广的模式，先从团队级别做一个初始化的尝试，但是在做尝试的时候要通知我们的领导层知道我们在做DevOps的工作。然后在团队取得成功之后，逐步把成果做一个放大提炼，得到管理层的认可，最终完成整体的推广。

上面这个图是报告里提到的，经过反复验证得到的一个结构化的方程模型。最左边的方框指的是变革型领导力，刚才提到了五个因素。变革型领导力做得好，它可以促进我们中间部分的这些最佳实践，包括测试和部署的自动化、持续集成、主干开发、解耦架构和对团队授权等，是有促进的作用的。中间的实践部分，对持续交付和精益管理有促进的作用。精益管理又对我们IT的效能提升有促进的作用，IT效能提升最终会导致组织的效能提升。这个结构化方程基本解释了在报告里提到的很多要素，包括领导力、技术实践、精益管理、持续交付等等，说明了它们之间的联系和相互的关系。

4. IT效能和组织效能

从今年的调研报告来看，得出了一些结论，首先无论是企业还是公益型的组织，都依赖于软件和IT来实现他们的目标。事实表明，DevOps实践能够帮助他们更快更可靠和跟高质量的去交付软件。

我们看一下具体数据。衡量IT的效能，刚才强调有两部分因素，一部分是代码的生产能力，包括团队代码的提交频率，还有提交代码到部署上线的速度。另外一部分是系统的稳定性，包括系统故障的修复速度和变更的失败率。

我们从这个图中可以看出，对比2016年，2017年有很多数据指标发生了一些变化：

• 从部署频率的角度，高效能组织会比低效能组织快46倍；
  
  

• 从变更的前置时间来看，高效能组织会比低组织大概快440倍；
  
  

• 从故障恢复时间来看，高效能组织要快96倍；
  
  

• 从变更的失败率来看，高效能组织要少5倍。
  
  

对比2016年的数据其实还是有比较大的差别。首先，高效能组织和低效能组织在生产力方面的差距在缩小，高效能组织实际上依然还是在按这个业务的需求在交付代码，低效能组织部署的频率和变更的周期都会有相关的提升，证明其实所谓的低效能组织的IT交付的整体能力还是在不断前进的。但是从稳定性的角度来讲，两者的差距都在扩大，我们可以看到2016年大概是差24倍，2017年扩展到96倍。

为什么在这个部分稳定性的差距会变大？这里面可能会有几方面的原因。首先是低效能团队为了提高部署的速度，可能在内建质量上的投入是不够的。对于内建质量的投入不够，虽然发布很快，但是它的质量是不高的。最终的结果就导致了更大的故障和更多的服务恢复的时间。这就给我们一个启示，我们不能单纯去追求效率而忽略了稳定性。举一个例子，我在前些年也做过很多自动化测试相关的事情，也研发了很长时间的自动化测试框架。我们会发现一个问题，如果你做了特别好特别炫的技术，有很好的自动化测试工具，但是你没有把你的校验点做得很完善，那么即使你的自动化测试通过了，可能还会有一些隐藏的缺陷没有被发现。这样从领导的角度来看，你可能所有做的事情就白费了，因为你表面上在做一个很有技术性的工作，但实际上没有解决真正的问题，我们一定要避免这种情况。我们做DevOps其实也是一样的，很多组织在拼命的追求速度，但是追求速度的时候我们不能以牺牲质量作为一个前提，我们应该通过内建质量来获得速度与质量的双赢。

这页图展示了2017年调研的数据，组织可以分为三种类型：高效能、中等效能和低效能组织，这是用聚类分析方法来做的分类。可以看到对于高效能组织，他的部署频率是按需的，每天可能有多次的发布，对于每次发布的变更前置时间基本是小于1个小时的，对于故障的恢复时间也是小于1个小时，变更的失败率大概是0-15%之间，也是比较低的数值。从这个角度进一步验证了对于一个高效能组织来讲，他的效率和质量是可以兼得的。

为什么能有这么高的效率，前面谈到了自动化是一个组织里面巨大的福利或者法宝。对于自动化来讲，通过调研很多高效能的组织，发现在这些组织里面对于配置管理、测试、部署和变更审批里面，手工的工作比率都是比较低的。像表里列举的，大概20%到30%之间是手工的，其他大部分的工作量已经变成自动化了。

这里面他给出了一个案例，是惠普打印机的一个例子，大家可以看到这个图，从2008年到2011年之间变化的关系。在2008年的时候，这个团队大部分的工作消耗在一些处理分支代码、处理手工测试、处理线上问题等等低效的环节上，只有5%的时间可以用来创新。但是经过了自动化测试的加强，代码分支策略的调整，以及敏捷的研发模式，在2011年的时候可以达到40%的时间是用于创新。可以看到中间的浪费和手工重复低效的工作已经非常少，这是一个比较成功的通过自动化改善IT效能的案例。大家如果对这个案例比较关注，后面有时间我会再详细展开讲解。

原创：张乐