DevOps的主要目标很简单即：频繁、可靠地发布软件更新，并提高质量，这个目标有点“十全十美”，每个企业都会赞同这个目标，很多人回告诉你，他们已经通过遵循一些常用的框架如：CALMS开始了DevOps的道路。

然而，很少人会对DevOps模式的结果表示满意，我们访问了使用生命周期的不同阶段的200多名DevOps专业人员，发现企业通常属于三大类：

最让人感兴趣的是第二和第三组，因为他们实际上已经开始实践DevOps模式，当被问及如何更好地解释这些挑战和障碍时，以下是我们的发现：

• 68%的人说，在工具链中，不同的DevOps工具之间的关联性让人十分苦恼。
  
• 52%的人说，大部分测试仍然以手动模式进行，速度反而降低。
• 38%的人混合了传统和现代的应用，比如Brownfield Environments，因此在部署策略和端点，工具链方面提高了复杂性。
• 27%的人仍苦苦挣扎于“Silo'ed”团队，无法按照预期进行合作。
• 23的人对自助服务基础设施的访问有限。
  
  

其他值得注意的痛点包括：DevOps相关技能，难以管理复杂多样的服务和环境，缺乏紧迫性和预算，领导层的支持。

接下来详细地了解这些挑战：

挑战1：DevOps的工具链缺少关联性

许多DevOps工具可以一些任务自动化，如CI、基础设施配置、测试、部署、配置管理、发布管理等，当企业开始采用DevOps，这些工具的帮助非常大，但它们尝尝不能很好地协同工作。

作为经典的例子之一，我们采访了一家公司的熟悉DevOps工程师，他的团队使用Capistrano进行部署，当被问及如何发现一个新的应用版本或配置变化时，他表示，测试和运维团队打开了JIRA Tickets，包括Capistrano所需的信息，在运行这些脚本之前手动更新脚本，这一过程花了几个小时，需要小心得管理，因为所需的配置需要两次手动传输，第一次是在JIRA中，第二次是将其复制到Capistrano时。

虽然这是一个简单的例子，但这个问题存在于整个工具联众，在工具中执行依赖任务所需的状态和其他信息处理地非常糟糕。

较小的企业通过编写自定义脚本将这些工具链粘合在一起解决问题，这对一些应用来说是可行的，但很快就会出现严重问题，因为这些脚本不是以标准方式编写的，会很难维护、常常包含令牌、密钥和其他敏感信息，更糟糕的是，这些脚本对于每个应用都是高度定制的，并且无法重用，方便地伸缩自动化工作流。

而当DevOps工具链中的工具无法协作，需要通过手动或自定义脚本管理依赖项时，持续交付也就无法实现。

挑战2：缺乏测试自动化

尽管所有的焦点都集中在TDD上，但多数的企业仍然在为自动化测试而努力，如果是人肉测试，那么几乎不可能为每个提交执行整个测试套件，这会成为持续交付的障碍，团队试图通过对每个提交运行一组核心测试来优化这一点，并且对整个测试套件进行周期性的运行，这意味着大多数BUG都在软件交付工作流程中被发现，并且会消耗大量的成本。

测试自动化是DevOps采用过程的一个重要部分，因此需要成为一个优先级。

挑战 3：Brownfield Environments

典型的IT组合在本质上是异构的，横跨数十年的技术、云平台供应商、实验室和数据中心、公有云和私有云，所有的这些都在同一时间节点，创建狂月这方面的工作流非常困难，因为大多数工具都与特定的体系结构和技术一起工作，导致了工具链的蔓延，因为每个团队都会使用工具链去满足需求。

Docker的兴起也鼓励了许多企业开发基于微服务的应用，这增加了DevOps自动化的复杂性，因为应用现在需要为异构的微服务提供100个部署通道，微服务还会带来动态的应用生命周期，每个微服务都是独立部署的具有独立性，因此跨团队的调度和协调需要指数级增长。

挑战4：文化问题

应用在功能的驱动中发展，开发者开发应用，有测试去检验，然后由运维部署和管理，尽管所有的团队都希望进行写作，但其之间往往是有冲突的。

开发者被要求尽快的开发新的应用，测试和发布管理团队被逼得尽可能彻底地确保应用没有BUG，这两个团队经常被SecOps和基础设施部门管控，确保生产不会中断，治理和遵从性也降低了速度，这导致了一种反变革的文化，因为变革会带来风险和不稳定性因素，因此需要更多的资源和预算来管

跨团队的协作。

跨团队的协作往往会出现一些问题，从而减缓应用更改的流程。

一些企业试图通过让开发人员去构建、测试、和运维应用来解决这个问题，尽管这可能在理论上行得通，但开发却因没有时间去生产陷入困境，而且大部分的时间都在运营上个月所做的事情上，无法进行创新，很多企业试图让所有的团队都参与到SDLC的各个阶段，但这种方法仍然依赖于手工协作。

自动化是团队间协作的最佳实践，但是正如在其他挑战中所见，自动化本身也会降低速度，并引入风险和BUG。

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

虚拟机和云计算已经改变了获取正确基础设施的过程，之前几个月时间的任务现在几分钟即可完成，如AWS这样的IaaS提供商拥有数百提灵活配置的机器，以及预装操作系统和其他工具供以选择如：Ansible、 Chef、Puppet，可以帮助代表基础设施代码，这进一步加速了机器的供应和重新配置。

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

DevOps作为一个新兴的概念，寓意着未来的发展趋势的同时，本身也有诸多挑战，但我们不能否认，如果在以后逐步克服了这些挑战与困难，将会产生巨大的收益。

来自：SRE与运维

DevOps的主要目标很简单即：频繁、可靠地发布软件更新，并提高质量，这个目标有点“十全十美”，每个企业都会赞同这个目标，很多人回告诉你，他们已经通过遵循一些常用的框架如：CALMS开始了DevOps的道路。

然而，很少人会对DevOps模式的结果表示满意，我们访问了使用生命周期的不同阶段的200多名DevOps专业人员，发现企业通常属于三大类：

最让人感兴趣的是第二和第三组，因为他们实际上已经开始实践DevOps模式，当被问及如何更好地解释这些挑战和障碍时，以下是我们的发现：

• 68%的人说，在工具链中，不同的DevOps工具之间的关联性让人十分苦恼。
  
• 52%的人说，大部分测试仍然以手动模式进行，速度反而降低。
• 38%的人混合了传统和现代的应用，比如Brownfield Environments，因此在部署策略和端点，工具链方面提高了复杂性。
• 27%的人仍苦苦挣扎于“Silo'ed”团队，无法按照预期进行合作。
• 23的人对自助服务基础设施的访问有限。
  
  

其他值得注意的痛点包括：DevOps相关技能，难以管理复杂多样的服务和环境，缺乏紧迫性和预算，领导层的支持。

接下来详细地了解这些挑战：

挑战1：DevOps的工具链缺少关联性

许多DevOps工具可以一些任务自动化，如CI、基础设施配置、测试、部署、配置管理、发布管理等，当企业开始采用DevOps，这些工具的帮助非常大，但它们尝尝不能很好地协同工作。

作为经典的例子之一，我们采访了一家公司的熟悉DevOps工程师，他的团队使用Capistrano进行部署，当被问及如何发现一个新的应用版本或配置变化时，他表示，测试和运维团队打开了JIRA Tickets，包括Capistrano所需的信息，在运行这些脚本之前手动更新脚本，这一过程花了几个小时，需要小心得管理，因为所需的配置需要两次手动传输，第一次是在JIRA中，第二次是将其复制到Capistrano时。

虽然这是一个简单的例子，但这个问题存在于整个工具联众，在工具中执行依赖任务所需的状态和其他信息处理地非常糟糕。

较小的企业通过编写自定义脚本将这些工具链粘合在一起解决问题，这对一些应用来说是可行的，但很快就会出现严重问题，因为这些脚本不是以标准方式编写的，会很难维护、常常包含令牌、密钥和其他敏感信息，更糟糕的是，这些脚本对于每个应用都是高度定制的，并且无法重用，方便地伸缩自动化工作流。

而当DevOps工具链中的工具无法协作，需要通过手动或自定义脚本管理依赖项时，持续交付也就无法实现。

挑战2：缺乏测试自动化

尽管所有的焦点都集中在TDD上，但多数的企业仍然在为自动化测试而努力，如果是人肉测试，那么几乎不可能为每个提交执行整个测试套件，这会成为持续交付的障碍，团队试图通过对每个提交运行一组核心测试来优化这一点，并且对整个测试套件进行周期性的运行，这意味着大多数BUG都在软件交付工作流程中被发现，并且会消耗大量的成本。

测试自动化是DevOps采用过程的一个重要部分，因此需要成为一个优先级。

挑战 3：Brownfield Environments

典型的IT组合在本质上是异构的，横跨数十年的技术、云平台供应商、实验室和数据中心、公有云和私有云，所有的这些都在同一时间节点，创建狂月这方面的工作流非常困难，因为大多数工具都与特定的体系结构和技术一起工作，导致了工具链的蔓延，因为每个团队都会使用工具链去满足需求。

Docker的兴起也鼓励了许多企业开发基于微服务的应用，这增加了DevOps自动化的复杂性，因为应用现在需要为异构的微服务提供100个部署通道，微服务还会带来动态的应用生命周期，每个微服务都是独立部署的具有独立性，因此跨团队的调度和协调需要指数级增长。

挑战4：文化问题

应用在功能的驱动中发展，开发者开发应用，有测试去检验，然后由运维部署和管理，尽管所有的团队都希望进行写作，但其之间往往是有冲突的。

开发者被要求尽快的开发新的应用，测试和发布管理团队被逼得尽可能彻底地确保应用没有BUG，这两个团队经常被SecOps和基础设施部门管控，确保生产不会中断，治理和遵从性也降低了速度，这导致了一种反变革的文化，因为变革会带来风险和不稳定性因素，因此需要更多的资源和预算来管

跨团队的协作。

跨团队的协作往往会出现一些问题，从而减缓应用更改的流程。

一些企业试图通过让开发人员去构建、测试、和运维应用来解决这个问题，尽管这可能在理论上行得通，但开发却因没有时间去生产陷入困境，而且大部分的时间都在运营上个月所做的事情上，无法进行创新，很多企业试图让所有的团队都参与到SDLC的各个阶段，但这种方法仍然依赖于手工协作。

自动化是团队间协作的最佳实践，但是正如在其他挑战中所见，自动化本身也会降低速度，并引入风险和BUG。

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

虚拟机和云计算已经改变了获取正确基础设施的过程，之前几个月时间的任务现在几分钟即可完成，如AWS这样的IaaS提供商拥有数百提灵活配置的机器，以及预装操作系统和其他工具供以选择如：Ansible、 Chef、Puppet，可以帮助代表基础设施代码，这进一步加速了机器的供应和重新配置。

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

DevOps作为一个新兴的概念，寓意着未来的发展趋势的同时，本身也有诸多挑战，但我们不能否认，如果在以后逐步克服了这些挑战与困难，将会产生巨大的收益。

来自：SRE与运维