在定义上，DevOps是一个涵盖着几条线的领域。它既非常实用又贴近实践。但与此同时，你需要了解的不仅有技术背景，还有非技术的文化方面。中培教育专家指出，DevOps最佳实践的动手和软技能两个部分。

DevOps由开发(developments)和运维(operations)两个单词组成。这个双关语已经揭示了DevOps的本意，那就是鼓励不同的软件开发部门共同协作。

DevOps这个词的起源和DevOps运动的早期还是很清晰的：Patrick Debois是一名在IT行业的许多领域里很有经验的软件开发工程师兼顾问。他本人对于开发和运维之间的对立感到相当不爽。他试图在会议中引起大家对这个问题的兴趣，但是一开始并没有什么效果。

在2009年，O’Reilly Velocity大会上有个深得好评的演讲：“每日至少十次部署：开发和运维在Flickr的合作”。Patrick随即决定在比利时根特市组织一场名为DevOps之日的活动。这次，感兴趣的人变多了，这场大会获得了成功。“DevOps之日”这个名字引起了共鸣，而这场大会也延续了下来。在Twitter和大多数论坛里，DevOps之日被简称为DevOps。

DevOps运动的根源写在了敏捷软件开发原则里。在2001年，有些人想要改进一成不变的软件开发模式，并寻找新的工作方法，他们编写了敏捷宣言。下面是敏捷宣言里被奉为经典的摘录，可以在http://agilemanifesto.org/上阅读“个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值。”

由此可见，DevOps可以说是与第一条原则密切相关的--“个体和互动高于流程和工具。”显然这能够给工作带来好处——那为什么我们还要强调这么明显的事呢？如果你在大型企业里工作过，你就会知道事实上经常是反着来的。哪怕是看起来没什么障碍的小企业，里面的各个部门也很容易就筑起高墙。

DevOps，想要强调个体和互动是非常重要的，并且这个技术很可能有助于拆除企业里的部门墙。看起来可能有点儿反直觉，因为第一条原则更青睐于交互而不是工具。但是我认为使用任何工具都能起到多种效果。只要工具用得适当，就能帮我们得到所有想要在敏捷中获得的东西。

举个非常简单的例子，一个选择系统过去经常有缺陷。通常，开发团队和测试团队会用不同的系统来处理任务和缺陷。这样的事不仅在团队中导致了不必要的摩擦，并且把本应一起工作的双方隔离开了。而运维团队很可能又会用第三种系统来处理服务器的部署请求。

另一方面，有DevOps观念的工程师，会立即意识到所有的三个系统都是相似的工作流程。三个囡队里的每个人应该都有使用一个相同系统的可能性，也许只需要为不同的角色展示不同的界面就可以了。因为三个系统变成了一个，所以会带来减少维护成本的长期利益。

DevOps的另一个核心目标是自动化和持续交付。简单来说，自动化一切可重复的乏味的工作，把更多时间留给人与人之间的交流，这才能产生真实的价值。

想了解更多IT资讯，请访问中培教育官网：中培教育