共计 3452 个字符，预计需要花费 9 分钟才能阅读完成。
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 打算都会遇到该组织特有的简单阻碍。然而，关注团队成员的单干和稳固能够缩小外部阻力，并将潜在的惰性起源转变为对领导层的改革，从而确保胜利。
