中国第一份 DevOps 年度调查报告的发布，对于 DevOps 在中国的发展有着里程碑式的意义。一群有心人为中国 DevOps 社区做了这样有价值的事情，InfoQ 的编辑们觉得“推波助澜”一把是责无旁贷的事情。写在前面

每年一次的 DevOps 全球现状调查，Puppet Labs 已经做了超过 5 个年头。近年，DevOps 在中国也逐渐成为了一个热议的话题，但鲜有权威机构对其在中国的现状给出一个概览，这使得国内 DevOps 先行者们还处于摸着石头过河的状态。及至 2016 年下半年，DevOps 中国社区决心迈出第一步，利用科学的方法，经过了长达数月的问卷调研活动，遂有了中国的第一份 DevOps 年度调查报告《DevOps 中国·2017 年度调查报告》。

这对于 DevOps 在中国的发展有着里程碑式的意义。它像一座灯塔，既使 DevOps 的先行实践者们能够对自身的 DevOps 实践有一个明确定位，又为踌躇不前的观望者们指明了软件开发的发展方向。InfoQ 编辑整理了报告中的主要内容，分享给开发者们。同时，作为一个引子，也希望 DevOps 的实践者们能参与到 DevOps 中国的年度调研活动中。报告从受访对象、性能表现、实践活动、障碍和员工敬业度等 5 个方面对 DevOps 的中国现状进行了分析。

目前，《DevOps 中国·2018 年度调研》（devops/） 已经开始（戳 阅读原文 参加），前往参与问卷调查，您还将免费获得完整版的 2017 年度报告。

受访对象

从本次调研活动参与者所处行业的分布，我们可以发现，DevOps 在国内已渗透到了各个行业中。但是对比国外 DevOps 参与者的行业分布，不难发现，除了科技和互联网行业，国内其他行业的从业者对 DevOps 的了解稍显不足。

图 1 国内国外行业对比

从参与者所在的部门分布我们可以看出，DevOps 已经在部分企业内部得到了重视，13% 的参与者所在企业设立了专门的 DevOps 部门。但与国外还是有不小的差距，2017 年度 DevOps 全球现状调查报告显示，全球范围内，DevOps 部门的比例已经从 2014 年的 16％增长到了 2017 年的 27%。

大中型组织对 DevOps 的接纳度更高，39% 的参与者所在组织拥有超过 100 个服务器，43% 的参与者所在组织员工数量超过 500 人。

图 3 服务器个数

图 4 员工数

目前，软件开发团队中，男性依然占主导地位。本次受调查人员男性占 91%，远超女性 9% 的占比，这一结果恰巧与 2017 年度 DevOps 全球现状调查结果相同，说明这是一个全球普遍存在的问题。此外，根据团队性别比例等数据，16% 的团队中没有女性存在，团队中女性人数多于 1/4 的仅占 19%。

图 5 性别比和团队性别比

此外，我们还分别对被调查人员以及其所在团队和其所在组织的 DevOps 经验进行了数据分析，发现超过 50% 的团队及组织的 DevOps 实践经验都低于 1 年。

图 6 实践经验

性能表现

从商业层面上来说，我们说一个组织是高效的，意味着该组织不仅可以快速的向市场提供具有关键业务的应用，并且能够规避那些可能中断其商业价值的服务的能力。对于 IT 组织，在保持对市场需求的高敏感度的同时，它们还要提供稳定、安全并且可预测的 IT 服务。在此次调查中，为了更好的衡量 DevOps 对一个组织的生产活动的影响，从四个方面对性能表现进行了量化，即部署频率、交付周期、平均修复时长和变更失败比例。

维持较高的部署频率（即，固定时间内较多的迭代次数）使得一个组织在快速的将想法变成价值的同时可以进行多次尝试，加快了商业概念到业务价值的转变。高频率部署也意味着快速和持续的部署，这有利于组织对市场需求及时反应，使组织能够通过自动化的构建、测试和部署循环来快速交付高质量的软件。 报告显示，32.4% 的团队在一天之内进行多次部署，与部署频率超过一周的团队相比，他们对于市场变化和用户反馈反应更加迅速。

图 7 部署频率

在交付周期这个衡量指标上，交付周期与团队 DevOps 经验之间没有显著相关性。DevOps 经验少于 1 年，经验 1～2 年和经验 3～5 年的团队，在交付周期的性能指标上没有显著差异，其中交付周期小于 1 天的团队占比几乎持平，分别为 23%，24%，25%。

图 8 交付周期

高效的团队在应对一些意外故障时，能够将恢复时间控制在几分钟之内，是低效团队（耗费一小时甚至更多的时间）恢复速度的 30 倍。

很多组织都无法忍受哪怕是几分钟的故障修复时间，这意味着数以百万计的利润的流失与用户满意度的下降。在这次调查中，13.5% 的组织能够将平均修复时长控制在 15 分钟之内，32.9% 的团队能够在一小时之内完成修复，这方面已接近国际水平。

图 9 平均修复时长

变更失败比例主要考虑变更导致的服务降级或随后的修复，比如导致服务受损、服务中断、需要热修复、回滚、打补丁等情况。变更失败的主要原因是开发、测试环境与生产环境的不匹配。

当一次变更失败后，组织需要花费时间和资源对其进行修复，可能对开发、发布、更新产品等阶段造成不同程度的恶劣影响。

目前，66.2% 的团队能够将比例控制在 0-15%，同时我们发现，变更失败比例超过 15% 的团队 DevOps 实践经验均小于两年。

图 10 变更失败比

综合考虑这四个指标，报告中定义了对于高性能和低性能团队的衡量标准。

图 11 性能表

由于在被调查的团队中只有 6.7% 的团队能够达到报告中所定义的高性能指标，无法得出其与团队实践活动之间准确的关系，为此，又定义了一个准高性能。按照放宽的标准，16.2% 的参与者处于准高性能团队，其余 83.8% 的团队被称之为非高性能团队。

图 12 准高性能表

在这次调查中，超过三分之一的公司实现了一天内多次部署，尽管这个指标与 DevOps 经验并无显著关系，我们却发现部署频率越高的团队在交付周期的表现上越好，这说明部署频率的提高确实有助于提高产品对市场需求变化做出快速反应的可能性。与此同时对于受访人员的部署感受，调查结果发现实现一半以上自动部署的团队对于代码部署是无痛的。

实践活动

团队性能的提升离不开具体的 DevOps 实践活动，它包含了自动化过程、质量保证、标准化实践、监控、敏捷五个方面。

自动化过程可以使得开发人员更关心软件的逻辑而不用与复杂的配置打交道。自动化也是提高可测试性、一致性、稳定性、部署频率和达到持续交付核心。

图 14 自动化过程

对于 QA 的调查我们发现，DevOps 的高部署频率通常会给 QA 带来很大的压力，传统的 QA 往往跟不上 DevOps 的部署频率，或者使得服务质量下降， 或者使得发布频率降低。

图 15 QA

将 QA 引入整个 DevOps 工作流需要我们去解决。良好的标准化实践可以提高软件可靠性、可维护性和可移植性，缩短软件的开发周期和降低运行维护成本。

图 16 标准化实践

同时，一个可靠和可持续的监控机制能够更好、更有效的保障服务的稳定运作，其产生的高频率反馈和缺陷也正好能在 DevOps 的高部署频率上得到很好的满足与解决。

图 17 监控手段

对于敏捷方面的调查结果显示 42.47% 的 DevOps 团队使用 Scrum，另外 12.33% 的 DevOps 团队使用看板方法。

图 18 敏捷方法

对于犹豫是否进行 DevOps 实践的团队，一个主要的疑虑是，转型 DevOps 需要大量的投入，但短期内很可能看不到任何收益。本次报告的结果将是对这一疑虑有效的回应。受访者的团队中，无论性能高低，经验多少，在自动化方面均实践得较为充分。这说明，对于一个从未实践过 DevOps 的团队，可以通过应用一些自动化工具，至少在交付周期上，快速缩小与 DevOps 经验丰富的团队之间的差距。当然，从另一个角度来说，这一结果可能也意味着中国的 DevOps 实践，目前还处于一个尚不成熟的阶段。

图 19 性能与实践活动

障    碍

DevOps 模式的应用有助于更快的构建可靠性更高、质量更好的软件，但在实现 DevOps 的过程中有许多常见的阻碍, 其中不同部门的目标不一致、员工对于 DevOps 的概念不理解以及组织缺少 DevOps 专家是三个最普遍的阻碍。这三个障碍也正是中国 DevOps 现状的一个缩影。不仅仅这些障碍，我们还发现，大部分团队对于 DevOps 的概念理解上还有偏差，实践中也受到成本和资源的限制，没有办法较好的进行 DevOps 实践。

图 20 国内障碍

员工敬业度

员工敬业度是员工对公司投入的智慧、感情和承诺的程度的反映，行为上表现为乐意宣传，乐意留下，全力付出，因此在报告中将敬业度等价的看作是员工对公司的忠诚度。员工的忠诚度会体现在他们的工作中，即忠诚度高的员工参与工作的程度会更高，往往会以更高的标准要求自己，以提供更好的客户体验，这反过来会推动公司的绩效

在此次调查中，使用了员工净推荐值（eNPS）来了解员工在 DevOps 工作环境中的忠诚度。净推荐值，也叫口碑，是在许多行业中被广泛使用来测量消费者对生产者的忠诚度的指标。生产者可以是进行 NPS 调查的公司、雇主或其他任何实体，消费者则是进行打分的客户或员工。NPS 的计算基于一个直截了当的问题：“您愿意向您的朋友或同事推荐我们的公司 / 产品 / 服务吗”

根据愿意推荐的程度让员工在 0－10 之间来打分，然后根据得分情况来建立忠诚度的 3 个范畴：推荐者（得分在 8－10 之间），被动者（得分在 6－7 之间），贬损者（得分在 0－5 之间）。

图 21 净推荐值

相比 IT 性能高的团队，在 IT 性能低的团队中忠诚度低的员工占比更多。这是有一定道理的，因为忠诚度高的员工更愿意推荐他们的朋友来自己的团队工作，一个高效率的工作环境也会促进员工的参与度与敬业度。

调研向被访者询问了三个问题：

• 您愿意向您的朋友或过去的同事推荐，“我的组织不错，来我的组织工作吧”？

• 您愿意向您的朋友或同事推荐，“我的团队不错，来我的团队工作吧”？

• 您愿意向您的朋友或同事推荐我们的公司 / 产品 / 服务吗？

  
  

通过对 IT 性能和上述三个问题的结果进行敏感性分析，结果显示，问题 1，2 仅与平均修复时长相关，而问题 3 仅与变更失败比例相关。综合分析受访者对于组织、团队和产品的推荐值，结果显示，敬业度综合评分（3 项推荐值的平均值）仅与变更失败比例相关。实际上，修复和变更都是团队成员的计划外工作，计划外工作的比例和顺利程度对于员工的敬业度会产生重要影响。其中，修复的顺利程度会影响员工对于组织和团队的满意度，而变更失败比例会影响员工对于产品的信心。

下图展现了统计了平均修复时长性能从低到高的团队对于组织和团队的推荐值，变更失败比例性能从低到高的团队对于产品的推荐值。

图 22 员工敬业度

平均修复时长性能高的团队对于组织和团队的推荐值分别是性能低的团队的 1.64 倍和 1.55 倍；而变更失败比例性能高的团队对于产品的推荐值是性能低的团队的 2.57 倍，此外，没有发现非常满意自己团队产品的受访者。

进一步分析，还发现员工敬业度与以下因素显著相关：

• 团队的负责人可以有效的帮助团队：当团队负责人对团队产生了积极影响时， 例如可以做到明确的分工、合理的规划等，使员工有一个可预期的输出，对待工作也会更加投入。

• 促进开发人员与运营人员之间的沟通来达到技术共享：当开发人员和运维人员之间的矛盾被解决，员工就可以更加专注于自己的工作而不用频繁返工。

• 经常收集客户的反馈，并将这些反馈吸纳到产品的设计中：当员工看到他们所做的工作与对客户的积极影响之间的联系时，他们会更认同公司的目标。

  
  

DevOps 概念早在 2009 年就被提出来, 伴随着越来越多的新技术 (如微服务、容器) 和自动 化工具的普及, 近两年才逐渐受到企业重视并开始被广泛实践。2016 年末，DevOps 中国社区，参考 Puppet Lab 历年发布的调查报告和大量的文献，设计了一份共 39 个问题的在线问卷，涵盖了受访对象、性能表现、实践活动、阻碍和员工敬业度等五个方面，通过社区渠道进行推广，最终有 74 名 DevOps 相关从业人员参与其中，经过数据的统计和分析，最终发布了《DevOps 中国·2016 年度调查报告》。

从 2016 年度中国的调查结果及与 Puppet Lab 发布的全球现状的对比来看，目前 DevOps 在中国的发展还处于起步阶段，在普及程度、性能表现等方面，仅达到 2 到 3 年前的国际水平。目前，在 DevOps 实践上，国内团队多停留在单纯的工具使用上，这一方面说明了对 DevOps 的理解和实践还不足，另一方面，在 DevOps 经验不足的情况下，通过工具的使用，迅速实现过程自动化，团队确实可以显著提高 IT 性能。这对还未展开 DevOps 实践的团队是一个好消息，从工具使用开始向 DevOps 转型是一种能看到短期收益的平滑转型方式。但工具的使用等实践还是需要落实到过程的改进，并最终回到组织层面，甚至是文化层面，如何逐步深入是想要进一步提高性能的团队和组织们无法绕开的问题。

此外，由于是第一次调查，且问卷的推广存在明显不足，导致参与人数较少，这份报告是否能够准确描绘出现状还存疑。但考虑到参与者多为 DevOps 社区的活跃者，他们所表现出的概念模糊、经验不足等问题还是非常具有代表性。

技术社区总有这样一群不为人知的人，默默地做着一些不为人知，却意义非常的事情。这样的人和团队，值得我们的敬佩。InfoQ 诚挚地恳求您，参与到这个调查中来，成为这个有意义事情中的一个样本，共同构成这一份伟大。只需要您花几分钟时间，戳 阅读原文 参与 DevOps 中国·2018 年度调查问卷，感谢您的支持。

作者｜DevOps 中国社区编辑｜InfoQ

中国第一份 DevOps 年度调查报告的发布，对于 DevOps 在中国的发展有着里程碑式的意义。一群有心人为中国 DevOps 社区做了这样有价值的事情，InfoQ 的编辑们觉得“推波助澜”一把是责无旁贷的事情。写在前面

每年一次的 DevOps 全球现状调查，Puppet Labs 已经做了超过 5 个年头。近年，DevOps 在中国也逐渐成为了一个热议的话题，但鲜有权威机构对其在中国的现状给出一个概览，这使得国内 DevOps 先行者们还处于摸着石头过河的状态。及至 2016 年下半年，DevOps 中国社区决心迈出第一步，利用科学的方法，经过了长达数月的问卷调研活动，遂有了中国的第一份 DevOps 年度调查报告《DevOps 中国·2017 年度调查报告》。

这对于 DevOps 在中国的发展有着里程碑式的意义。它像一座灯塔，既使 DevOps 的先行实践者们能够对自身的 DevOps 实践有一个明确定位，又为踌躇不前的观望者们指明了软件开发的发展方向。InfoQ 编辑整理了报告中的主要内容，分享给开发者们。同时，作为一个引子，也希望 DevOps 的实践者们能参与到 DevOps 中国的年度调研活动中。报告从受访对象、性能表现、实践活动、障碍和员工敬业度等 5 个方面对 DevOps 的中国现状进行了分析。

目前，《DevOps 中国·2018 年度调研》（devops/） 已经开始（戳 阅读原文 参加），前往参与问卷调查，您还将免费获得完整版的 2017 年度报告。

受访对象

从本次调研活动参与者所处行业的分布，我们可以发现，DevOps 在国内已渗透到了各个行业中。但是对比国外 DevOps 参与者的行业分布，不难发现，除了科技和互联网行业，国内其他行业的从业者对 DevOps 的了解稍显不足。

图 1 国内国外行业对比

从参与者所在的部门分布我们可以看出，DevOps 已经在部分企业内部得到了重视，13% 的参与者所在企业设立了专门的 DevOps 部门。但与国外还是有不小的差距，2017 年度 DevOps 全球现状调查报告显示，全球范围内，DevOps 部门的比例已经从 2014 年的 16％增长到了 2017 年的 27%。

大中型组织对 DevOps 的接纳度更高，39% 的参与者所在组织拥有超过 100 个服务器，43% 的参与者所在组织员工数量超过 500 人。

图 3 服务器个数

图 4 员工数

目前，软件开发团队中，男性依然占主导地位。本次受调查人员男性占 91%，远超女性 9% 的占比，这一结果恰巧与 2017 年度 DevOps 全球现状调查结果相同，说明这是一个全球普遍存在的问题。此外，根据团队性别比例等数据，16% 的团队中没有女性存在，团队中女性人数多于 1/4 的仅占 19%。

图 5 性别比和团队性别比

此外，我们还分别对被调查人员以及其所在团队和其所在组织的 DevOps 经验进行了数据分析，发现超过 50% 的团队及组织的 DevOps 实践经验都低于 1 年。

图 6 实践经验

性能表现

从商业层面上来说，我们说一个组织是高效的，意味着该组织不仅可以快速的向市场提供具有关键业务的应用，并且能够规避那些可能中断其商业价值的服务的能力。对于 IT 组织，在保持对市场需求的高敏感度的同时，它们还要提供稳定、安全并且可预测的 IT 服务。在此次调查中，为了更好的衡量 DevOps 对一个组织的生产活动的影响，从四个方面对性能表现进行了量化，即部署频率、交付周期、平均修复时长和变更失败比例。

维持较高的部署频率（即，固定时间内较多的迭代次数）使得一个组织在快速的将想法变成价值的同时可以进行多次尝试，加快了商业概念到业务价值的转变。高频率部署也意味着快速和持续的部署，这有利于组织对市场需求及时反应，使组织能够通过自动化的构建、测试和部署循环来快速交付高质量的软件。 报告显示，32.4% 的团队在一天之内进行多次部署，与部署频率超过一周的团队相比，他们对于市场变化和用户反馈反应更加迅速。

图 7 部署频率

在交付周期这个衡量指标上，交付周期与团队 DevOps 经验之间没有显著相关性。DevOps 经验少于 1 年，经验 1～2 年和经验 3～5 年的团队，在交付周期的性能指标上没有显著差异，其中交付周期小于 1 天的团队占比几乎持平，分别为 23%，24%，25%。

图 8 交付周期

高效的团队在应对一些意外故障时，能够将恢复时间控制在几分钟之内，是低效团队（耗费一小时甚至更多的时间）恢复速度的 30 倍。

很多组织都无法忍受哪怕是几分钟的故障修复时间，这意味着数以百万计的利润的流失与用户满意度的下降。在这次调查中，13.5% 的组织能够将平均修复时长控制在 15 分钟之内，32.9% 的团队能够在一小时之内完成修复，这方面已接近国际水平。

图 9 平均修复时长

变更失败比例主要考虑变更导致的服务降级或随后的修复，比如导致服务受损、服务中断、需要热修复、回滚、打补丁等情况。变更失败的主要原因是开发、测试环境与生产环境的不匹配。

当一次变更失败后，组织需要花费时间和资源对其进行修复，可能对开发、发布、更新产品等阶段造成不同程度的恶劣影响。

目前，66.2% 的团队能够将比例控制在 0-15%，同时我们发现，变更失败比例超过 15% 的团队 DevOps 实践经验均小于两年。

图 10 变更失败比

综合考虑这四个指标，报告中定义了对于高性能和低性能团队的衡量标准。

图 11 性能表

由于在被调查的团队中只有 6.7% 的团队能够达到报告中所定义的高性能指标，无法得出其与团队实践活动之间准确的关系，为此，又定义了一个准高性能。按照放宽的标准，16.2% 的参与者处于准高性能团队，其余 83.8% 的团队被称之为非高性能团队。

图 12 准高性能表

在这次调查中，超过三分之一的公司实现了一天内多次部署，尽管这个指标与 DevOps 经验并无显著关系，我们却发现部署频率越高的团队在交付周期的表现上越好，这说明部署频率的提高确实有助于提高产品对市场需求变化做出快速反应的可能性。与此同时对于受访人员的部署感受，调查结果发现实现一半以上自动部署的团队对于代码部署是无痛的。

实践活动

团队性能的提升离不开具体的 DevOps 实践活动，它包含了自动化过程、质量保证、标准化实践、监控、敏捷五个方面。

自动化过程可以使得开发人员更关心软件的逻辑而不用与复杂的配置打交道。自动化也是提高可测试性、一致性、稳定性、部署频率和达到持续交付核心。

图 14 自动化过程

对于 QA 的调查我们发现，DevOps 的高部署频率通常会给 QA 带来很大的压力，传统的 QA 往往跟不上 DevOps 的部署频率，或者使得服务质量下降， 或者使得发布频率降低。

图 15 QA

将 QA 引入整个 DevOps 工作流需要我们去解决。良好的标准化实践可以提高软件可靠性、可维护性和可移植性，缩短软件的开发周期和降低运行维护成本。

图 16 标准化实践

同时，一个可靠和可持续的监控机制能够更好、更有效的保障服务的稳定运作，其产生的高频率反馈和缺陷也正好能在 DevOps 的高部署频率上得到很好的满足与解决。

图 17 监控手段

对于敏捷方面的调查结果显示 42.47% 的 DevOps 团队使用 Scrum，另外 12.33% 的 DevOps 团队使用看板方法。

图 18 敏捷方法

对于犹豫是否进行 DevOps 实践的团队，一个主要的疑虑是，转型 DevOps 需要大量的投入，但短期内很可能看不到任何收益。本次报告的结果将是对这一疑虑有效的回应。受访者的团队中，无论性能高低，经验多少，在自动化方面均实践得较为充分。这说明，对于一个从未实践过 DevOps 的团队，可以通过应用一些自动化工具，至少在交付周期上，快速缩小与 DevOps 经验丰富的团队之间的差距。当然，从另一个角度来说，这一结果可能也意味着中国的 DevOps 实践，目前还处于一个尚不成熟的阶段。

图 19 性能与实践活动

障    碍

DevOps 模式的应用有助于更快的构建可靠性更高、质量更好的软件，但在实现 DevOps 的过程中有许多常见的阻碍, 其中不同部门的目标不一致、员工对于 DevOps 的概念不理解以及组织缺少 DevOps 专家是三个最普遍的阻碍。这三个障碍也正是中国 DevOps 现状的一个缩影。不仅仅这些障碍，我们还发现，大部分团队对于 DevOps 的概念理解上还有偏差，实践中也受到成本和资源的限制，没有办法较好的进行 DevOps 实践。

图 20 国内障碍

员工敬业度

员工敬业度是员工对公司投入的智慧、感情和承诺的程度的反映，行为上表现为乐意宣传，乐意留下，全力付出，因此在报告中将敬业度等价的看作是员工对公司的忠诚度。员工的忠诚度会体现在他们的工作中，即忠诚度高的员工参与工作的程度会更高，往往会以更高的标准要求自己，以提供更好的客户体验，这反过来会推动公司的绩效

在此次调查中，使用了员工净推荐值（eNPS）来了解员工在 DevOps 工作环境中的忠诚度。净推荐值，也叫口碑，是在许多行业中被广泛使用来测量消费者对生产者的忠诚度的指标。生产者可以是进行 NPS 调查的公司、雇主或其他任何实体，消费者则是进行打分的客户或员工。NPS 的计算基于一个直截了当的问题：“您愿意向您的朋友或同事推荐我们的公司 / 产品 / 服务吗”

根据愿意推荐的程度让员工在 0－10 之间来打分，然后根据得分情况来建立忠诚度的 3 个范畴：推荐者（得分在 8－10 之间），被动者（得分在 6－7 之间），贬损者（得分在 0－5 之间）。

图 21 净推荐值

相比 IT 性能高的团队，在 IT 性能低的团队中忠诚度低的员工占比更多。这是有一定道理的，因为忠诚度高的员工更愿意推荐他们的朋友来自己的团队工作，一个高效率的工作环境也会促进员工的参与度与敬业度。

调研向被访者询问了三个问题：

• 您愿意向您的朋友或过去的同事推荐，“我的组织不错，来我的组织工作吧”？

• 您愿意向您的朋友或同事推荐，“我的团队不错，来我的团队工作吧”？

• 您愿意向您的朋友或同事推荐我们的公司 / 产品 / 服务吗？

  
  

通过对 IT 性能和上述三个问题的结果进行敏感性分析，结果显示，问题 1，2 仅与平均修复时长相关，而问题 3 仅与变更失败比例相关。综合分析受访者对于组织、团队和产品的推荐值，结果显示，敬业度综合评分（3 项推荐值的平均值）仅与变更失败比例相关。实际上，修复和变更都是团队成员的计划外工作，计划外工作的比例和顺利程度对于员工的敬业度会产生重要影响。其中，修复的顺利程度会影响员工对于组织和团队的满意度，而变更失败比例会影响员工对于产品的信心。

下图展现了统计了平均修复时长性能从低到高的团队对于组织和团队的推荐值，变更失败比例性能从低到高的团队对于产品的推荐值。

图 22 员工敬业度

平均修复时长性能高的团队对于组织和团队的推荐值分别是性能低的团队的 1.64 倍和 1.55 倍；而变更失败比例性能高的团队对于产品的推荐值是性能低的团队的 2.57 倍，此外，没有发现非常满意自己团队产品的受访者。

进一步分析，还发现员工敬业度与以下因素显著相关：

• 团队的负责人可以有效的帮助团队：当团队负责人对团队产生了积极影响时， 例如可以做到明确的分工、合理的规划等，使员工有一个可预期的输出，对待工作也会更加投入。

• 促进开发人员与运营人员之间的沟通来达到技术共享：当开发人员和运维人员之间的矛盾被解决，员工就可以更加专注于自己的工作而不用频繁返工。

• 经常收集客户的反馈，并将这些反馈吸纳到产品的设计中：当员工看到他们所做的工作与对客户的积极影响之间的联系时，他们会更认同公司的目标。

  
  

DevOps 概念早在 2009 年就被提出来, 伴随着越来越多的新技术 (如微服务、容器) 和自动 化工具的普及, 近两年才逐渐受到企业重视并开始被广泛实践。2016 年末，DevOps 中国社区，参考 Puppet Lab 历年发布的调查报告和大量的文献，设计了一份共 39 个问题的在线问卷，涵盖了受访对象、性能表现、实践活动、阻碍和员工敬业度等五个方面，通过社区渠道进行推广，最终有 74 名 DevOps 相关从业人员参与其中，经过数据的统计和分析，最终发布了《DevOps 中国·2016 年度调查报告》。

从 2016 年度中国的调查结果及与 Puppet Lab 发布的全球现状的对比来看，目前 DevOps 在中国的发展还处于起步阶段，在普及程度、性能表现等方面，仅达到 2 到 3 年前的国际水平。目前，在 DevOps 实践上，国内团队多停留在单纯的工具使用上，这一方面说明了对 DevOps 的理解和实践还不足，另一方面，在 DevOps 经验不足的情况下，通过工具的使用，迅速实现过程自动化，团队确实可以显著提高 IT 性能。这对还未展开 DevOps 实践的团队是一个好消息，从工具使用开始向 DevOps 转型是一种能看到短期收益的平滑转型方式。但工具的使用等实践还是需要落实到过程的改进，并最终回到组织层面，甚至是文化层面，如何逐步深入是想要进一步提高性能的团队和组织们无法绕开的问题。

此外，由于是第一次调查，且问卷的推广存在明显不足，导致参与人数较少，这份报告是否能够准确描绘出现状还存疑。但考虑到参与者多为 DevOps 社区的活跃者，他们所表现出的概念模糊、经验不足等问题还是非常具有代表性。

技术社区总有这样一群不为人知的人，默默地做着一些不为人知，却意义非常的事情。这样的人和团队，值得我们的敬佩。InfoQ 诚挚地恳求您，参与到这个调查中来，成为这个有意义事情中的一个样本，共同构成这一份伟大。只需要您花几分钟时间，戳 阅读原文 参与 DevOps 中国·2018 年度调查问卷，感谢您的支持。

作者｜DevOps 中国社区编辑｜InfoQ