参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时，总是会有一个这样的论点出现：

DevOps不是一系列可以连贯起来的工具，你用了它们就可以说自己做的是DevOps。DevOps是一种方法论，让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分，实现更多成功的部署和更频繁的发布。

它完全正确。然而，话虽如此，祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景：你处在一个研发工作室，创业公司甚至是大型企业。你有很多开发人员，他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”，在企业中他们可能被称为“基础设施运营专家”（如果你们有更有趣的名字也可以在下方留言）。但不管怎样，他们的人使用开发团队所写的代码，并确保它们能够在生产级别的环境上可靠运行。

·         开发写代码并添加新特性

·         从开发到运维，一个传递发生了

·         现在它是运维的麻烦了……

·         运维挥动服务器魔法，把问题解决了！

听着很耳熟？主要的问题是什么呢？运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生，从此变成了一个问题。在技术团队中有服务器魔法师当然很棒，因为开发人员不用再担心如何处理服务器问题，但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务：开发人员需要它，运维也是

DevOps的目的是团队紧密工作，缩短反馈回路。

做一些改变，让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错？然后让新功能平滑地上生产，交到用户的手里。出现了问题？回滚一下，迅速地修复它，然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路，经常慢如爬行动物。

写代码的开发人员最适合做发布（在他们的计划中方便的时候），测试，监控性能，以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢？

很多情况下，服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置，但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白，发布和维护是你职责所在，如果出错了要在第一线调试它，通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢？（提示，通常和工具有关）。

你选择的工具可能重要，也可能无关紧要

在一天结束的时候，运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意，它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式，那么恭喜。

讲个故事。

在之前的一份工作里，我们采用了一种配置管理工具，插在Jenkins上，集成了很多开源系统，很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能，可以为每个变化进行完整测试。一切看起来都很好，除了一个大问题：我们构建了类似自助服务的东西，但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们，他们可以检查日志，查看图表，看各项性能，但是当碰到钉子的时候，就是我们的职责了。

所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作？我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

在过去几年的DevOps大会上，容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地，改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义，让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案，提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的？

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品，在前进的道路上，不管是从基础架构、还是人员管理和软件发布的角度，都会不可避免遇到可伸缩性的问题。随着团队的成长，和服务器的扩展，公司不仅需要关注产品线路图的执行，还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮，那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来，让公司更加专注于产品——

·         开发者能够通过友好的用户界面管理自己的服务器硬件需求

·         开发者可以减少一个数量级的反馈回路时间，这意味着更多的代码更快的发布

·         运维不用再尝试将一堆工具拢在一起做一个内部的PaaS，它很难做，很难管理，很难修补，很难保证安全

·         运维可以更进一步地专注在应用监控、性能表现上，给予开发一些有价值的反馈来快速提升产品

·         业务可以更灵活地延伸到全球范围，根据业务需求进行扩展，更新用户平台不需要时间和成本上的花费

·         更多的资金可以用来雇佣人才专注于产品研发

所以，拥有了容器技术的DevOps，是否有了新的定义？

当然小数要补充一句，容器不是万能的，用在适合的地方最好。（Phil Dougherty原创）

参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时，总是会有一个这样的论点出现：

DevOps不是一系列可以连贯起来的工具，你用了它们就可以说自己做的是DevOps。DevOps是一种方法论，让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分，实现更多成功的部署和更频繁的发布。

它完全正确。然而，话虽如此，祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景：你处在一个研发工作室，创业公司甚至是大型企业。你有很多开发人员，他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”，在企业中他们可能被称为“基础设施运营专家”（如果你们有更有趣的名字也可以在下方留言）。但不管怎样，他们的人使用开发团队所写的代码，并确保它们能够在生产级别的环境上可靠运行。

·         开发写代码并添加新特性

·         从开发到运维，一个传递发生了

·         现在它是运维的麻烦了……

·         运维挥动服务器魔法，把问题解决了！

听着很耳熟？主要的问题是什么呢？运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生，从此变成了一个问题。在技术团队中有服务器魔法师当然很棒，因为开发人员不用再担心如何处理服务器问题，但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务：开发人员需要它，运维也是

DevOps的目的是团队紧密工作，缩短反馈回路。

做一些改变，让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错？然后让新功能平滑地上生产，交到用户的手里。出现了问题？回滚一下，迅速地修复它，然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路，经常慢如爬行动物。

写代码的开发人员最适合做发布（在他们的计划中方便的时候），测试，监控性能，以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢？

很多情况下，服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置，但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白，发布和维护是你职责所在，如果出错了要在第一线调试它，通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢？（提示，通常和工具有关）。

你选择的工具可能重要，也可能无关紧要

在一天结束的时候，运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意，它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式，那么恭喜。

讲个故事。

在之前的一份工作里，我们采用了一种配置管理工具，插在Jenkins上，集成了很多开源系统，很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能，可以为每个变化进行完整测试。一切看起来都很好，除了一个大问题：我们构建了类似自助服务的东西，但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们，他们可以检查日志，查看图表，看各项性能，但是当碰到钉子的时候，就是我们的职责了。

所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作？我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

在过去几年的DevOps大会上，容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地，改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义，让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案，提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的？

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品，在前进的道路上，不管是从基础架构、还是人员管理和软件发布的角度，都会不可避免遇到可伸缩性的问题。随着团队的成长，和服务器的扩展，公司不仅需要关注产品线路图的执行，还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮，那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来，让公司更加专注于产品——

·         开发者能够通过友好的用户界面管理自己的服务器硬件需求

·         开发者可以减少一个数量级的反馈回路时间，这意味着更多的代码更快的发布

·         运维不用再尝试将一堆工具拢在一起做一个内部的PaaS，它很难做，很难管理，很难修补，很难保证安全

·         运维可以更进一步地专注在应用监控、性能表现上，给予开发一些有价值的反馈来快速提升产品

·         业务可以更灵活地延伸到全球范围，根据业务需求进行扩展，更新用户平台不需要时间和成本上的花费

·         更多的资金可以用来雇佣人才专注于产品研发

所以，拥有了容器技术的DevOps，是否有了新的定义？

当然小数要补充一句，容器不是万能的，用在适合的地方最好。（Phil Dougherty原创）