采用 DevOps 的 7 个主要障碍，你一定不知道！

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、财务和其他方面必须承诺并建立信任。”

——Ian Willoughby，云解决方案副总裁兼首席架构师

6.无法扩展 DevOps

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

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

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

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

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

Qasim Khan，高级副总裁-商业信息官，美国银行

7.无法合并安全性

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

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

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

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