DevOps的主要目标非常简单：让软件更新频繁可靠并且质量更好。然而宣传了这么久，很少有人对DevOps表示完全满意。通过与200多名DevOps专业人士交谈后，我们发现目前进展主要分为下述三类：

我们对第二组和第三组可能更感兴趣，因为这两组处于部署过程中：

• 68％的人表示，工具链中各种DevOps工具之间缺乏连接性是最令人沮丧的；

• 52％的人表示，大部分测试仍然是手动的，这放慢了速度；

• 38％的人指出，他们混合了传统和现代应用环境。这在部署策略和端点、工具链等方面产生了复杂性；

• 23％的自助服务基础设施有限。

• 其他显著痛点还包括找到正确的DevOps技能，难以管理多种服务和环境的复杂性，缺乏预算和时间紧迫性，以及执行领导层的有限支持。

让我们更详细地研究一下这些挑战。

1:DevOps工具链缺少连接

许多DevOps工具可以帮助自动化不同任务，如CI，基础设施配置，测试，部署，配置管理，发布管理等。虽然这些在企业开始采用DevOps流程时有很大帮助，但它们往往不能很好地协同工作。

作为一个典型例子，其团队使用Capistrano进行部署的首席DevOps工程师表示，只要需要部署新版本的应用程序，或者每当需要配置更改时，他仍然会通过JIRA tickets与Test and Ops团队进行通信其基础设施。

运行Capistrano脚本所需的所有信息都可以在JIRA tickets中使用，在运行之前需手动将其复制到脚本中。这个过程通常需要花费几个小时，需要仔细管理，因为所需的配置会被手动传输两次：一旦输入到JIRA，会再次复制到Capistrano。

这是一个简单的例子，但这个问题存在于整个工具链中。

通过编写较小的自定义脚本将工具链粘合在一起可以解决这个问题，这适用于几个应用程序，因为这些脚本通常不会以标准方式编写，并且也很难维护，当应用程序变得大且多时，这之中经常包含令牌、密钥和其他敏感信息。更糟糕的是，这些脚本对每个应用程序都是高度自定义的，不能重用以轻松扩展到自动化工作流程。

对于大多数企业来说，解决这一问题是昂贵而复杂的，除非拥有Facebook和亚马逊等公司的团队和资源，否则最终将成为DevOps进展的障碍。

当DevOps工具链中的工具无法协作并且需要手动或通过自定义脚本管理依赖关系时，持续交付将非常困难。

2：缺乏测试自动化

如果测试是手动的，每次提交几乎不可能执行整个测试套件，这成为持续交付的障碍。团队尝试通过为每个提交运行核心测试集并仅定期运行完整的测试套件来优化此功能。这意味着软件交付工作流程之后可能会出现错误，并且查找和修复成本要高得多。

自动化测试是DevOps过程的重要组成部分，因此需要成为首要任务。

3：Brownfield环境

典型的IT组合在本质上是异构的，经历了数十年的技术发展，云平台供应商、数据中心的私有云和公有云.......创建跨越这些方面的工作流是非常有挑战性的，因为大多数工具都可以使用特定的架构和技术。这导致工具链蔓延，因为每个团队都使用最适合他们需求的工具链。

Docker的兴起也鼓励许多企业开发基于微服务器的应用程序。这也增加了DevOps自动化的复杂性，因为应用程序现在需要数百个异构微服务的部署管道。

4：文化问题

应用程序的开发及开发通常需要多个部门的合作，开发商想要有质量保证的、体系稳定的软件，然后由IT运营部门部署和运营。尽管所有团队都希望能够携手合作，但往往会出现利益冲突。

开发人员可以尽可能快地移动，并建立新的东西。质量保证和发布管理团队尽可能的确保没有软件错误。

治理和遵守也在减缓事态中发挥作用，成本中心的压力越来越大，这导致了一种反对变革的文化，因为变革引发了风险，破坏了事物的稳定，这意味着需要更多的资金和资源来管理影响。

一些企业试图通过开发人员构建，测试和操作软件来解决这个问题。虽然这可能在理论上起作用，但是开发商们也受到生产问题的困扰，大部分时间都花在运营上，而不是创新新事物。大多数企业试图让所有团队参与SDLC的所有阶段，但这种方法仍然依赖于手动协作。

自动化是开发和运营协作的最佳方式。

5：有限的自助服务基础设施和环境访问

对于许多企业来说，虚拟机和云计算转变为按需获得，以前需要几个月的时间现在可以在几分钟内实现。像AWS这样的IaaS提供商拥有数百台具有灵活配置的机器以及预先安装的操作系统和其他工具选项。像Ansible、Chef、Puppet这样的工具有助于代表基础设施代码，从而进一步加快配置和重新配置机器。

然而，这在许多企业中仍然是一个问题，特别是那些运行自己数据中心或尚未接纳云端的组织。

结论

尽管这些问题很难克服，但我们需要更多时间来慢慢接纳DevOps，并逐渐走向成熟。