前言
10年前，DevOps这个名词出现，它从一个技术话题逐渐变成了IT界的文化运动。这一理论鼓励开发人员快速开发、试错、并且不断迭代。DevOps与数字化转型产生了不可分割的联系。但是当它变成了一个IT术语，十年已经是一个足够长的时间来让那些围绕DevOps究竟是什么所进行的不同定义、翻译和误解变得精确。
DevOps和敏捷是一样的意思吗？DevOps是一个方法论吗？亦或者，DevOps只是协作的另一种说法呢？
由于DevOps包括很多不同的概念（持续交付、持续集成、自动化，等等），所以对DevOps投入了极大热情的人们来说，尝试把DevOps浓缩成一个全面简短的解释就变成了非常困难的事情。但是，让我们回忆一下，每当你试图向上级推销自己的想法，或者在聚会中介绍自己工作时，言简意赅的解释都会起到至关重要的作用。因此，现在，让我们抛开特定DevOps词语间的细小差异，重点关注DevOps的大框架吧。
什么是DevOps？6个定义和比喻
我们问DevOps专家怎样用最短的、最简单的词语来解释DevOps，才能让每一个人都理解DevOps的价值，而不需要管他们的技术背景如何。看下面一些有力的定义和若干有帮助的比喻描述，将帮助你讲述你的DevOps故事。
1、DevOps是一种文化运动
“DevOps是一种文化运动，在这种文化中关键的利益相关群体（软件开发人员和IT运维人员）都认为软件在没有被消费者、客户及员工等人使用之前是没有真正的价值的。”DevOps研究所的首席研究分析师 Eveline Oehrlic 说，“由于这个原因，所以所有团队都是一起确保软件是快速且高质量交付的。”
2、DevOps赋能开发者
“DevOps赋能开发者负责、运营和管理一个应用程序的端对端交付。”
“一般来讲，DevOps通过实现及利用自动化流程让产品快速交付到生产。对于我来说，这是非常基础且重要的事情。”在 Liberty Mutual 的安全DevOps开发平台董事 Jai Schniepp说，“DevOps赋能开发者负责、运营和管理一个应用程序的端对端交付。这种方式解决了权责不清的问题，驱动开发团队向自动化及开发者托管的基本架构进化。”
3、DevOps是一个构建和交付软件的协作方法
“简单的说，DevOps是一种大家在一起，进行软件开发和交付的方法。”BMC的数字业务自动化总裁 Gur Steif 。
4、DevOps像一条组装流水线
“要想让一条流水线正常工作，组件之间必须设计配合得天衣无缝。”
“我将会把DevOps比作一条制造装配线。” Steif 说，“这个方式是首先设计和创造了所有的部件，然后再把部件全部组装起来。要想让一条流水线正常工作，组件之间必须设计配合得天衣无缝。设计和制造发动机的人必须考虑到底盘和发动机支架，制造刹车的人必须考虑到轮辋和轮胎等等。这也是软件开发需要的。编写业务逻辑或用户界面的开发人员必须考虑存储用户信息的数据库，保护用户数据安全，以及当这些服务开放给数百万用户时是如何操作运行的。”
“让人们去合作和思考其他人正在做的工作，而不是专注于自己的工作，这是需要克服的最大障碍。如果你成功地克服了它，那你就抓住了实现数字化转换的绝佳机会。”Steif 补充说道。
5、DevOps是一个”配方” – 结合了人、进程与自动化
Jayne Grol ，DevOps研究所的CEO，用一个非常好的烹饪类比来解释DevOps：“DevOps是一个配方，这个配方依赖的成分来自于三个主要的类别 -人、流程和自动化。”她说，“大部分成分能够改编自其他众所周知的方法和来源，例如精益、敏捷、上置权、CI/CD、ITIL、领导力、文化和工具。DevOps背后的秘密是为了增加客户的流量和价值，怎样让这些成分用正确的比例混合（像其他好的配方那样）。”
6、DevOps团队就像 NASCAR 竞赛
“竞赛的团队从头到尾都不会进行思考。他们翻转桌子来看比赛，从终点线往前看，一直看到开始。”
“当我谈论一项DevOps倡议的预期成果，我提到NASCAR 或者 F1 竞赛。” Red Hat Ansible 的首席产品经理和DevOps实时通讯的发布人 Chris Short 说。“竞赛团队的领导者有一个任务：当克服抛向他们的逆境时，要利用他们已有的资源，尽可能地在最好的时机完成。竞赛的团队从头到尾都不会进行思考，他们翻转桌子来看比赛，从终点线往前看，一直看到开始。他们设定一个目标，一个延伸目标，然后开始逆向工作，从这些目标出发思考确定怎样到达。在竞赛周内，工作是被委派给团队成员去推向靠近预期结果设置的这些目标。”
“竞赛团队在竞赛开始前整周停止练习。他们在这一周进行重量训练和有氧训练项目，以保证他们的身体为比赛那天的艰苦环境做好了准备。他们持续协作来解决可能发生的任何问题。同样地，软件团队应该经常练习发布。如果安全系统到位，以及实践运行已经非常好了，那发布产品就可以更频繁了。在这种状况下，速度使事情变得更安全。” Short 说。
“这并不是关于做正确的事情。”他补充道，“这是关于尽可能的应对很多可能使你远离你预期成果的事情，依据你观察到的真实反馈去不断与他人协作并自我调整。拥抱异常,然后朝着改善质量而努力,这样这些目标异常造成的冲击才能降至最低。这是DevOps世界里的每一个人的期望。”
