DevOps在2018年庆祝了它的十周年纪念日，在科技行业，这已经是足够漫长的生命周期了。尽管DevOps已经相对成熟，DevOps哲学仍然在回避甚至是最著名和最有资源的组织。一份令人震惊的Gartner报告显示，75%的DevOps项目未能实现其目标。

为什么DevOps的失败率如此之高？在实施DevOps理念时，组织面临的共同挑战是什么？如何克服这些挑战？

本篇文章将解决这些问题，并为企业提供可复制的策略，以提高DevOps计划的成功率。

1.资源配置不规范

资源分配是DevOps的一大挑战。仅仅集成开发和运维团队并不能产生一个高效的DevOps团队。极大数量的DevOps团队缺乏主题专家，这严重影响了团队实现DevOps承诺的能力。

首先，从事应用程序开发、优化和监控等不同技术的多面手不会像专家那样有效率。这样会浪费宝贵的时间，最终减慢DevOps的交付速度。

此外，当DevOps团队最小化计划外工作时，他们的工作效率最高。如果没有专门的资源来处理特定的DevOps问题，团队被迫将复杂的问题分配给非主题问题的专家。这将破坏他们的工作计划，并使整个团队效率低下。更重要的是，这类人才日益增加的工作量增加将导致员工筋疲力尽，并有可能使整个DevOps计划脱轨。

只有在有专门人才处理问题时，DevOps才能加快功能发布、更新和上市时间。因此，企业必须确定关键的应用程序技术和开发流程，这些技术和流程可以通过DevOps进行优化，并为这些特定领域分配专门的技能型人才。

最佳的资源分配对于DevOps计划的成功至关重要。

2.责任错位

DevOps将目标截然不同的团队聚集在一起，在一个“不稳定的”环境中工作。开发人员主要关心的是创新、稳定的运维团队、性能完美的QA团队等等。当然，这些团队之间必然会有摩擦和冲突。

更糟糕的是，高层往往不会明确定义DevOps团队的目标、职责和优先级。这给模棱两可留下了很大的空间。习惯于孤岛式工作而不担心依赖关系的团队会倒退到原来的工作方式，从而否定了所有实现无缝协作的努力。

在改变领导者之前，让团队走出思维定势是最大的挑战。因此，当团队由跨学科资源组成时，DevOps的工作效果最好。拥有运维思维的开发人员，他们不羞于经常走出自己的舒适区，这是引领DevOps计划走向成功的迫切需要。
 

组织通常通过清晰地描述DevOps的目标、优先级和职责来克服这些挑战。更重要的是，他们为DevOps任务的成功分配了完整的责任。每个团队成员都对DevOps端到端任务的成功负责。当他们的个人表现由团队的整体成功来衡量时，筒仓会自动分解，协作会迅速增加。

3.过程割裂

没有多少DevOps领导者意识到，或者至少意识到，DevOps是非常分散的。尽管DevOps已经成熟，但它并不是特别适用于中小企业软件开发和交付模式。DevOps长期以来主要是一个大型企业计划。由于这个原因，与DevOps接轨的中小企业发现自己陷入了困境。

DevOps通过自动化软件开发生命周期中涉及的大部分任务来工作。然而，没有一个工具、过程或资源可以实现这一点。DevOps团队必须使用不同的工具来自动化其操作的不同方面。有很好的工具可以自动化各个组件，比如持续集成、基础设施供应、测试、源代码控制等等。但是，这些工具之间彼此不能集成（当然，也可借助工具实现集成，如禅道ZTF打通了禅道和Jenkins之间的沟壑，贯穿DevOps持续集成、持续测试、持续部署等DevOps生命周期的不同阶段）。

使这些不同的工具相互通信需要大量的资源，而大多数组织无法或愿意分配这些资源。由于这个原因，DevOps团队经常被迫使用有限的自动化功能，这是DevOps的对立面。

高效的DevOps团队在执行任务和自动化任务之间分配时间。如果没有自动化，事务性工作会逐渐增加，导致员工精疲力尽、流程延迟、响应能力恶化和交付质量下降。

企业可以通过开发一个清晰的DevOps策略来避免这些问题，该策略指定组织的DevOps目标，确定可以自动化的流程，并部署资源来实现这些目标。这些目标应该与资源分配相匹配，这种解决碎片整理的现实方法将帮助企业简化和自动化对他们来说很重要的流程。

4.缺乏适当的度量标准

缺少适当的度量标准既是一个过程挑战，也是一个人员挑战。KPI和指标在向DevOps团队传达组织的优先级和期望方面大有帮助。正如前面所讨论的，稳定性和部署时间在DevOps团队中持续存在冲突。是应该以牺牲稳定性为代价匆忙交付，还是注重稳定性延迟交付？是如何开始优先考虑一个目标而不是另一个目标的？

指标为团队提供了明确而精准的方向，以确定不同目标的优先级。尽管这些指标的价值可能会随着业务的不同而变化，但这些指标本身对所有DevOps团队都是普遍相关的。以下是企业在向团队传达DevOps目标时必须定义的一些指标：

● 部署频率
● 部署时间
● 更改故障率
● 自动测试通过率
● 每次发布后的故障数
● 缺陷逃逸率
● 检测的时间到
● 功能使用
● 终端用户体验
● 业务影响
● 部署失败

5.文化转变

对变革的抵制将是DevOps转型的最大障碍。DevOps试图将控制权从各自为政的团队及其负责人转移到组织内的单个多部门机构。自然，这样的尝试可以被解读为对决策权的侵蚀。

更进一步说，这不完全是关于控制。与传统的IT角色相比，DevOps的领导角色有很大的不同。一般来说，IT领导层必须具备在各种技术方面指导、支持和建议员工的专业技能。在DevOps环境中，情况并非如此。DevOps的员工工作在一个不稳定和快速发展的环境中。错误是常见的，而带来的后果可能是灾难性的。这样就不难理解为什么员工会担心DevOps流程。

因此，领导的首要作用是创造培养条件，给予员工更高的自由度，保护他们免受快速试验带来的挫折。此外，领导者的工作必须集中在确定DevOps的成功模式，并复制这些模式，以在整个组织中扩展转换。

一个自上而下的方法试图重新定义领导的角色，赋予DevOps团队更多的实验自由，并确保他们的稳定性，这对于克服文化惯性至关重要。

“无法实施文化变革——整个组织的相关方必须一致支持成功采用DevOps所需的必要文化变革。它包括不同组内的执行人员和领导。这不仅仅是技术上的采用。为了成功，业务、运营、IT、财务和其他方面必须承诺并建立信任。”

6.无法扩展DevOps

很多时候，早期DevOps计划的成功往往会变成失败。表现最好的DevOps团队被更多的项目淹没，这很快就会成为项目交付的瓶颈，更不用说随之而来的压力增加和生产力下降了。

解决这个问题的一个明显的方法是扩展DevOps团队。然而，这说起来容易做起来难。DevOps专家需要与开发人员或工程师截然不同的技能，因此雇佣起来既困难又昂贵。

一些组织通过在每个开发团队中嵌入一个DevOps专家来克服这个挑战。他们的职责是简化各自团队的交付链，同时与其他部门的DevOps专家进行协调。然而，这种方法经常会在团队之间滋生不一致和协作的麻烦。解决这些新问题的一种方法是借鉴开源实践，使用一种内部源代码方法。

团队必须拥有强大的协作工具，使他们能够从世界任何地方进行编码、发布和协作。最后，要用健壮的、去中心化的“以产品为中心”的交付模型取代传统的“以项目为中心”的方法。

“由DevOps驱动的改变首先需要有一个让人信服的目的。然后，要成功地衡量变化，需要整个组织的沟通、协作和承诺。”

7.无法合并安全性

纯粹从表面上看，DevOps和安全性似乎完全冲突。DevOps的核心是速度和持续交付，而安全性则强调广泛的测试和防误。然而，企业正慢慢意识到，与安全性集成的DevOps可以帮助他们修补漏洞、发布更新，并比以往更快地应对网络威胁。

目前，DevOps在将安全集成到其过程中面临三个障碍：缓慢的开发速度、无穷无尽的安全标准和对可见性的威胁。

最后，通过向所有团队成员提供安全数据并方便他们报告，可以提高威胁可见性。根据每个团队成员的角色和职责定制的SIEM仪表板可以在很大程度上为DevOps团队提供威胁可见性。为了使之有效，可以建立一个基于共同绩效目标的奖励体系。

每个组织的DevOps计划都会遇到该组织特有的复杂障碍。然而，关注团队成员的合作和稳定可以减少内部阻力，并将潜在的惰性来源转变为对领导层的变革，从而确保成功。