DevOps的核心目标很简单：频繁、可靠的发布软件更新，而且保证质量。这个目标有点完美无缺，是每个公司都认同并且想实现的。许多公司会告诉你他们已经在着手实施DevOps，通过模仿一些常用的框架例如CALMS。

然而只有少数公司对结果表示明确的满意。在和200多名在不同生命周期阶段的DevOps专业人员交流过后，我们发现企业一般分成3类：

我们对处于第二组和第三组的企业最感兴趣，因为他们正好处在DevOps进程的中间。当问到关于挑战和障碍更好的解释时，下面是我们所发现的：

• 68%的人说在他们的工具链中，各种DevOps工具之间缺少连接，这是非常让人沮丧的方面。
  
  

• 52%的人说，他们大部分的测试还是人工的，拖慢了他们的进度。
  
  

• 38%的存在原有环境和现代应用混合的情况，即棕色地带。这个情况增加了在部署阶段、端点等等的复杂性。
  
  

• 27%的仍然在与筒仓作战，无法如预期般的合作。
  
  

• 23%的在访问自服务的基础架构有限制。
  
  

• 其他值得注意的痛点包括寻找正确的DevOps技能组，管理复杂的多种服务和环境很困难，缺乏紧迫感/预算，和来自领导的支持比较有限。
  
  

1、DevOps 工具链之间缺乏连通

有许多DevOps工具能够帮助不同的任务自动化，像是CI，基础设施攻击，测试，部署，配置管理，发布管理等等。当这些工具产生惊人的用处时，企业开始采用DevOps进程，它们常常无法很好的协作。

作为一个经典例子，我们与Principal DevOps工程师交谈，他们团队使用Capistrano来部署。当问到他如何弄清楚新应用版本或配置变更时，他说测试和运维团队打开JIRA tickets和包括运行Capistrano需要的信息。他随后在运行它们前手动更新脚本。这个进程需要几个小时，而且需要非常小心的管理，因为所需的配置是手工传输两次，一次进入JIRA，第二次是复制到Capistrano。

这是个简单的例子，但是这个问题存在整个工具链中。在工具中执行依赖任务所需的传播状态和其他信息目前处理得非常糟糕。

小型企业通过写自定义脚本来绕过这个问题，把他们的工具链粘合到一起。这个办法对一些应用有用，但是很快升级到绝望地狱，因为这些脚本不是以标准方式写的。这些脚本很难维护，还包含tokens，key和其他敏感信息。最糟的是，这些脚本是为每个应用高度自定义的，无法再应用到扩展自动工作流上。

对于大多数严肃的企业来说，构建自产的“DevOps glue”是昂贵而又复杂的事，除非拥有Facebook和亚马逊的纪律和资源，不然它最终会成为DevOps进程的障碍。

当DevOps工具链中的工具不协作，并需要通过手动或自定义脚本管理依赖项的时候，持续交付是不可能实现的。

2、缺少测试自动化

尽管所有的焦点都集中在TDD上，但是大多数企业仍然在与自动化测试作斗争。如果测试是手动的，那么几乎不可能为每个提交都执行整个测试套件，成为持续交付的障碍。团队试图优化它，通过为每个提交运行一个核心的测试集，并且只在周期内运行完整的测试套件。这意味着大多数bug会在软件交付工作流程中发现，而且查找和修复的成本要高得多。

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

3、棕色地带环境

典型的IT投资组合在本质上是多样化的，跨越了几十年的技术，云平台供应商，实验室和数据中心的私有和公共云，所有这些都在同一时间。创建跨越这些方面的工作流是非常具有挑战性的，因为大多数工具都有特定的架构和技术。这导致了工具链的扩展，因为每个团队都用最有效的工具链来满足他们的需求。

Docker的兴起也鼓励了许多企业开发基于微服务的应用。这增加了DevOps自动化的复杂性，因为应用现在需要100个部署管道来为多样的微服务部署。微服务还会导致动态应用的生命周期，每个微服务都可以独立地部署和扩展，因此不同团队之间需要的调度和协调会以指数方式增长。

4、文化问题

应用跨越功能筒仓发展。开发人员制作软件，由QA稳定，然后由IT运营部署和操作。即使所有这些团队一起合作，也经常有利益冲突。

开发人员被要求尽可能快地创建新东西。QA和发布管理团队被要求尽可能的彻底、确保没有软件错误被遗漏。这两个团队都经常受到SecOps和Infrastructure Ops的把关，他们受到激励，确保生产不中断。治理和合规也在减缓事情中发挥了作用。成本中心在压力下要做得更多，这导致了一种反对变革的文化，因为改变带来了风险并且带来了不稳定，这意味着需要更多的资金和资源来管理影响。

这种跨功能筒仓的故障导致了协作和协调的问题，减慢了应用变更的流程。

一些企业试图通过开发人员构建、测试和操作软件来解决这个问题。尽管这在理论上可行，但开发人员因生产问题而陷入困境，大部分时间都花在了运营他们上个月所做的工作上，而不是在新事物上进行创新。大多数企业都试图让所有的团队都参与到SDLC的各个阶段，但是这种方法仍然依赖于手工协作。

自动化是促成和平的最好方法，并帮助开发和运维团队协作。但正如我们在其他挑战中看到的那样，特殊的自动化本身可以降低速度并引入风险和错误。

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

虚拟机和云计算已经改变了按需获取基础设施的过程。以前花了几个月的时间的事现在可以在几分钟内完成。IaaS提供商(AWS)拥有数百台具有灵活配置和许多预安装操作系统和其他工具的选项。像Ansible, Chef, Puppet这些工具代表了基础设施即代码，这进一步加速了机器的供应和再供应。

然而，在许多企业中，获取基础设施仍然是一个问题，特别是那些运行他们自己的数据中心或还没有接受云计算的企业。

从DevOps中我们要学会更多

一个流行的DevOps框架描述了一个CALMS方法，包括文化、自动化、精益、度量和共享。DevOps运动最初是一种文化运动，即便在今天，大多数的实现还是集中在文化上。

虽然文化是任何DevOps的重要组成部分，但改变企业文化是最难的事。由于现实因素，文化需要一段时间形成。Ops团队不讨厌改变，因为他们是不理性的，或是想要成为阻拦者。在过去的几年里，他们每次都很热情，他们试图在不沿着流程的情况下快速地跟踪生产的变化。把它们和Devs放在一起，可能会让工作环境变得更加友好，但并没有解决根本原因。

原创：Manisha Sahasrabudhe　　翻译： 袁思思

DevOps的核心目标很简单：频繁、可靠的发布软件更新，而且保证质量。这个目标有点完美无缺，是每个公司都认同并且想实现的。许多公司会告诉你他们已经在着手实施DevOps，通过模仿一些常用的框架例如CALMS。

然而只有少数公司对结果表示明确的满意。在和200多名在不同生命周期阶段的DevOps专业人员交流过后，我们发现企业一般分成3类：

我们对处于第二组和第三组的企业最感兴趣，因为他们正好处在DevOps进程的中间。当问到关于挑战和障碍更好的解释时，下面是我们所发现的：

• 68%的人说在他们的工具链中，各种DevOps工具之间缺少连接，这是非常让人沮丧的方面。
  
  

• 52%的人说，他们大部分的测试还是人工的，拖慢了他们的进度。
  
  

• 38%的存在原有环境和现代应用混合的情况，即棕色地带。这个情况增加了在部署阶段、端点等等的复杂性。
  
  

• 27%的仍然在与筒仓作战，无法如预期般的合作。
  
  

• 23%的在访问自服务的基础架构有限制。
  
  

• 其他值得注意的痛点包括寻找正确的DevOps技能组，管理复杂的多种服务和环境很困难，缺乏紧迫感/预算，和来自领导的支持比较有限。
  
  

1、DevOps 工具链之间缺乏连通

有许多DevOps工具能够帮助不同的任务自动化，像是CI，基础设施攻击，测试，部署，配置管理，发布管理等等。当这些工具产生惊人的用处时，企业开始采用DevOps进程，它们常常无法很好的协作。

作为一个经典例子，我们与Principal DevOps工程师交谈，他们团队使用Capistrano来部署。当问到他如何弄清楚新应用版本或配置变更时，他说测试和运维团队打开JIRA tickets和包括运行Capistrano需要的信息。他随后在运行它们前手动更新脚本。这个进程需要几个小时，而且需要非常小心的管理，因为所需的配置是手工传输两次，一次进入JIRA，第二次是复制到Capistrano。

这是个简单的例子，但是这个问题存在整个工具链中。在工具中执行依赖任务所需的传播状态和其他信息目前处理得非常糟糕。

小型企业通过写自定义脚本来绕过这个问题，把他们的工具链粘合到一起。这个办法对一些应用有用，但是很快升级到绝望地狱，因为这些脚本不是以标准方式写的。这些脚本很难维护，还包含tokens，key和其他敏感信息。最糟的是，这些脚本是为每个应用高度自定义的，无法再应用到扩展自动工作流上。

对于大多数严肃的企业来说，构建自产的“DevOps glue”是昂贵而又复杂的事，除非拥有Facebook和亚马逊的纪律和资源，不然它最终会成为DevOps进程的障碍。

当DevOps工具链中的工具不协作，并需要通过手动或自定义脚本管理依赖项的时候，持续交付是不可能实现的。

2、缺少测试自动化

尽管所有的焦点都集中在TDD上，但是大多数企业仍然在与自动化测试作斗争。如果测试是手动的，那么几乎不可能为每个提交都执行整个测试套件，成为持续交付的障碍。团队试图优化它，通过为每个提交运行一个核心的测试集，并且只在周期内运行完整的测试套件。这意味着大多数bug会在软件交付工作流程中发现，而且查找和修复的成本要高得多。

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

3、棕色地带环境

典型的IT投资组合在本质上是多样化的，跨越了几十年的技术，云平台供应商，实验室和数据中心的私有和公共云，所有这些都在同一时间。创建跨越这些方面的工作流是非常具有挑战性的，因为大多数工具都有特定的架构和技术。这导致了工具链的扩展，因为每个团队都用最有效的工具链来满足他们的需求。

Docker的兴起也鼓励了许多企业开发基于微服务的应用。这增加了DevOps自动化的复杂性，因为应用现在需要100个部署管道来为多样的微服务部署。微服务还会导致动态应用的生命周期，每个微服务都可以独立地部署和扩展，因此不同团队之间需要的调度和协调会以指数方式增长。

4、文化问题

应用跨越功能筒仓发展。开发人员制作软件，由QA稳定，然后由IT运营部署和操作。即使所有这些团队一起合作，也经常有利益冲突。

开发人员被要求尽可能快地创建新东西。QA和发布管理团队被要求尽可能的彻底、确保没有软件错误被遗漏。这两个团队都经常受到SecOps和Infrastructure Ops的把关，他们受到激励，确保生产不中断。治理和合规也在减缓事情中发挥了作用。成本中心在压力下要做得更多，这导致了一种反对变革的文化，因为改变带来了风险并且带来了不稳定，这意味着需要更多的资金和资源来管理影响。

这种跨功能筒仓的故障导致了协作和协调的问题，减慢了应用变更的流程。

一些企业试图通过开发人员构建、测试和操作软件来解决这个问题。尽管这在理论上可行，但开发人员因生产问题而陷入困境，大部分时间都花在了运营他们上个月所做的工作上，而不是在新事物上进行创新。大多数企业都试图让所有的团队都参与到SDLC的各个阶段，但是这种方法仍然依赖于手工协作。

自动化是促成和平的最好方法，并帮助开发和运维团队协作。但正如我们在其他挑战中看到的那样，特殊的自动化本身可以降低速度并引入风险和错误。

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

虚拟机和云计算已经改变了按需获取基础设施的过程。以前花了几个月的时间的事现在可以在几分钟内完成。IaaS提供商(AWS)拥有数百台具有灵活配置和许多预安装操作系统和其他工具的选项。像Ansible, Chef, Puppet这些工具代表了基础设施即代码，这进一步加速了机器的供应和再供应。

然而，在许多企业中，获取基础设施仍然是一个问题，特别是那些运行他们自己的数据中心或还没有接受云计算的企业。

从DevOps中我们要学会更多

一个流行的DevOps框架描述了一个CALMS方法，包括文化、自动化、精益、度量和共享。DevOps运动最初是一种文化运动，即便在今天，大多数的实现还是集中在文化上。

虽然文化是任何DevOps的重要组成部分，但改变企业文化是最难的事。由于现实因素，文化需要一段时间形成。Ops团队不讨厌改变，因为他们是不理性的，或是想要成为阻拦者。在过去的几年里，他们每次都很热情，他们试图在不沿着流程的情况下快速地跟踪生产的变化。把它们和Devs放在一起，可能会让工作环境变得更加友好，但并没有解决根本原因。

原创：Manisha Sahasrabudhe　　翻译： 袁思思