[译] 到底什么是DevOps？

简单历史回顾

为了更好地理解DevOps，咱们得穿越回到除了程序员外什么都没有的那个古老的年代。

正如道告诉咱们那样：

古老的程序员，神秘而又知识渊博。咱们难以揣测他们内在的思想，惟一能作的只是试着描述外在的样子：

• 有意识的（Aware），犹如一只在水中穿越的狐狸

• 警戒的（Alert），犹如一位驻立在战场上的将军

• 好心的（Kind），犹如一位接待来宾的东道主

• 简单的（Simple），犹如未经雕琢的木块

• 隐晦的（Opaque），犹如黑暗洞穴中的黑水池

程序员产生了机器语言。机器语言产生了汇编语言。汇编语言产生了编译器。到如今已经有了成千上万种语言。每一种语言，无论多么简陋，都有其各自的目的。每一种语言都解释着软件的阴和阳。每一种语言都在软件中有其一席之地。

在那个时候，软件开发办公室大部分被称为实验室，而程序员则称为科学家。为了更好地创造更好的应用，程序员不得不彻底理解应用正在解决的问题。他们须要知道这些应用将会用在哪里，以及运行在哪些类型的系统上。这也就意味着，程序员知道从应用到规格，从开发到部署再到维护之间的所有事情。

接着人类开始介入，而且但愿获得更多。更快的速度，更多的特性，更多的用户，更多的一切。

做为谦虚、低下而又安静的创造者，程序员只有不多机会去探索用户要求如此之多的欲望。要想取得胜利的最好机会就是开启对不一样领域方向的演进，以及创造一种层级关系。很快，程序员被称为开发人员、软件工程师、网络管理员、数据库开发人员、系统架构师、QA工程师和更多的种类取而代之。快速演进并适应来自外部世界的挑战成为了他们DNA的一部分。新的种类又能够在大约几周内进行演化。如网站开发人员又分为后端开发、前端开发、PHP开发、Ruby开发、Angular开发等等，一发不可收拾。

很快他们就忘了他们都来自同一个祖先：程序员。一位简单、安静、仅仅是想把世界更得更美好一些的科学家。他们开始互相争执，声称他们本身才是“程序员”真正的后裔而且比其余种类的血液更正统。

随着时光飞逝，他们将之间的相互协做降到了最低程序，只有当不得已的时候才会跟其余人说话。他们再也不为远方家庭成员的成功而庆祝，甚至最后一度连明信片也不发了。

若是留意他们的感觉，他们会发现他们的心里中，有一股程序员的星星之火，正等待着燎燃并准备着为这宇宙带来和平。

在他们自私，以自我为中心征服世界的途中，程序员的后裔忘记了他们工做的初心 -- 为他们的客户解决问题。客户开始感受到了诸如项目延期、太昂贵甚至失败的痛楚。

曾经一度，一颗闪亮之星光芒四射，让每一个人都受到了鼓舞去尝试和众多的后裔保护和平。它就是瀑布流。它真是一个杰出的想法，由于它利用了不一样的开发人群只有当他们须要时才沟通这一实事。当一个组完成了他们工做的那一部分，它就联系下一个组将工做流转下去并不再回过头来看一眼。

这种方式奏效了一段时间，但一如往常，人类（客户）又想获得更多。客户想在创造软件的过程当中参与更多，更频繁地给开发人员提供建议，而且即便是在后期也要求作出改变。

软件项目变得如此容易失败，以至这个现象都做为一个行业标准被接受。相关统计代表超过50%的项目是失败的，而且看起来咱们对此无能为力（ZDNet，CNet）。

每一代都有极少数具备远见的人深知，这些不一样群组的开发人员须要找到一种方式来共同工做、交流，并能让其相信他们客户能获得更好可能的解决方案。这些尝试最先可回溯到1957年，由约翰·冯·诺伊曼的同事提出的。然而直到2001年早期，敏捷宣言的12条原则面世后，咱们才开始此次变革。

1.经过早期和连续型的高价值工做交付知足“客户”。
2.大工做分红能够迅速完成的较小组成部门。
3.识别最好的工做是从自我组织的团队中出现的，
4.为积极员工提供他们须要的环境和支持，并相信他们能够完成工做。
5.建立能够改善可持续工做的流程。
6.维持完整工做的不变的步调。
7.欢迎改变的需求，即时是在项目后期。
8.在项目期间天天与项目团队和业务全部者开会。
9.在按期修正期，让团队反映如何能高效，而后进行相应地行为调整。
10.经过完车的工做量计量工做进度。
11.不断地追求完善。
12.利用调整得到竞争优点。

对于为世界带来和平以及恢复平衡，敏捷宣言迈进伟大的第一步。历史上第一次，软件开发过程当中的所有干系人是基于文明和“人类”的方式链接起来，一如过程式和机械式的方式。人们开始一直相互交谈，平常会议，以及交换想法与评论。他们意识到他们的想法比他们想像中有更多的共同之处，客户也成为了团队中的一部分，而再也不仅仅是做为一些只发钱不提问的编外人员而存在。

依然还有一些障碍须要克服，但前途已经比以前显得更加光明。敏捷意味着开放、愿意适应一般的变化。然而，变化如此之多，以致很难专一于无限制的目标和交付。这就是为何精益软件开发诞生的缘由。

沉迷于LSD（双关语）和冒着被放逐和流浪的危险，一些后裔从他们的种类的软件行业以外寻找解决方案。他们从大量汽车制造商的工做中发现了解救方法。Toyota产品系统简单得让人如此惊讶以至明显地它的精益制造能够轻松地应用于软件开发。

如下精益中的7条原则：

1.避免浪费
2.创建质量
3.加强学习能力
4.延迟决策
5.快速发布
6.受权与尊重
7.系统思考

附添加在敏捷之上，精益原则支持其思想，在整个过程当中保持灵活的同时，关注于作正确的事情。

曾经敏捷和精益被软件开发团队所接受，只差一步就能够将整套原则做为一个总体应用到IT行业，而正是由于这样，咱们迎来了DevOps！

DevOps - 三车道高速公路

传统软件开发团队的视图包括业务需求分析，系统架构，前端开发人员，后端开发人员，测试人员等。拥有敏捷和精益原则，更完善的软件开发过程则大部分关注如下这些。一旦应用去到了“产品准备就绪”状态，它将传递给系统工程师，发布工程师，数据库管理员，网络工程师、安全专家等”操做人员“。消除Dev（开发）和Ops（操做）之间的巨大隔阂是DevOps的主要驱动力。

DevOps是把精益原则应用到整个IT价值流的结果。IT价值流包含了从开发到产品，并将从原始程序员演化出来的”远方亲戚“都融合起来。

对于DevOps最好的解释来自Gene Kim，若是你还没读过菲尼克斯项目，我建议你花一些时间去了解它。

你不该该招聘一位DevOps工程师，又或者为DevOps设立一个新的部门。DevOps是一种文化，一种观念，它应该是整个IT中的一部分。没有工具能够把你的IT变成一个DevOps组织，也没有自动化的东西能让你的团队把最大化的价值交付给你的客户。

DevOps一般涉及三种方法，但我则把这三种方法看做为同一条高速公路上的三条车道。你从车道一开始，而后加速并变到车道二，最后你继续加速直到你进入了车道三。

车道一，总体的系统性能是主要的焦点，并强调重视系统中的各个个体、各个元素。

车道二，确保与上流之间的持续反馈，没被忽视

车道三，现场参与，持续提升，快速失败

车道一 - 开始加速

当接受DevOps原则时，也许IT组织须要学习的第一件事就是明白总体系统的重要性，并工做细项按优先级进行排序。在整个IT价值流中，不容许任何一个工做流成为瓶颈，并且每个都是不可或缺的。

保证工做流不被中断是每一个参与此过程人员的终极目标。尽管每一个人或者团队都有其角色和位置，他们致力于作到对系统有深刻的了解 是很是有必要的。适应了这种思考的方式后，会对质量有着直接的影响，由于引发瓶颈的缺陷不会再流下去。

确保了工做不被拖延还不够。一个产品化的组织应该不断寻找能够提升整个工做流的方法。这里有许多能够提升工做流的方法。你能够自由地进行选取，构想你本身的，或者把他们结合起来。

• 保持系统工做流不被中断

• 不断提升和优化工做流
  

车道二 - 换档加速

非中断的系统流是其中一个方向，它指望从开发到操做。在一个想法的国度里，这意味着高质量的软件能快速创造，部署上线，为客户交付价值。

然而，DevOps并不是乌托邦，没有任何一个方向能够充当整个瀑布流的方法。评估可交付性以及将工做流联系起来对于保证质量是很是重要的。首先须要实现与”上流“的沟通渠道就是从Ops到Dev。

给本身一个举手鼓掌是容易的，但要求反馈并提供反馈是看到本质的途径。每个被下流跟进的小步骤被上游持续确认是有必要的。

无论你用什么方式来展现你的反馈环。你能够邀请开发人员加入进来支持团队的会议，或者在每周冲刺会议中把网络管理拉进来。只要你有了你的反馈，评论就会随之而来而且是可控的，你的组织也就加速进入了DevOps车道。

车道三 - 柔道十段

DevOps最后一个车道不是针对于薄弱的头脑。为了能够进入DevOps的最后一条车道，你的组织必须是足够成熟的。与此相关的是勇于冒险的勇气，从失败中学习，持续试验，而且接受重复与实践是达到精通的必要条件。这也正是为何你会常常不断听到空手道的缘由。持续训练和重复能通往精通是由于它能把复杂的步骤变得平常化。

但在你开始合并这些步骤以前，首先你有必要掌握每个独立的步骤。

”适合师傅的不必定适合于徒弟。在超越以前，你得明白什么是道。“

DevOps第三条车道/最后一条车道包括为在平常基础上进行持续试验，持续奖励团队进行冒险，和将失败介绍进系统以提升容错性之间分派时间。

为了确保你的组织在实现这些测量时不暴露出过多的问题，你必须在确保所有的瓶颈都透明，系统流没有中断的同时，也确保全部的团队之间创建反馈环。

实现这些方法可使得你的组织在任什么时候候都保持警戒，能够在面对各类挑战时做出快速有效的响应。

总结 - DevOps组织清单

如下是一份能够用于验证你的组织是否符合DevOps的清单。欢迎请对此文章进行评论以及添加你本身的观点。

• 开发团队与操做团队之间没有隔阂。他们都是相同流程中的一部分。

• 从一个团队派发到另外一个团队的工做老是经过验证的，以及是高质量的。

• 没有”堆积“的工做，所有的瓶颈在掌控之中

• 开发团队不使用操做团队的时间做为其活动时间，由于部署和维护都是同一时间箱的一部分

• 开发团队不会在星期五下午5点后把代码提交到部署环境，而让操做团队整个周末都在作善后处理

• 开发环境是标准化的，而且操做团队能够轻易进行复制、扩展到生产环境

• 当发现合适时开发团队能够交付新的版本，而操做团队能轻易部署到生产环境

• 全部的团队之间的沟通途径是清晰的

• 团队的所有成员都有时间尝试和致力于提高系统

• 系统中的缺陷会在平常的事项中提出（或模拟）并处理掌控之中。从每一个实验中学习到的课程都纪录到文档，而且分享给所有相关人员。事故处理是一个例程，而且大部分都以一种熟悉的方式处理

结论

使用现代化的DevOps工具，如Chef，Docker，Ansible，Packer，Troposphere，Consul，Jenkins，SonarQube，AWS等，并不意味着你正在应用DevOps原则。DevOps是一种思惟方式。咱们是同一流程中的一部分，咱们分享着相同的时间，一块儿交付有价值的产品。每个参与到软件交付流程的人均可以加快或下降整个系统的速度。和错误的防火墙配置同样，开发过程当中的一个bug可让系统崩溃。

全部的人都是DevOps中的一部分，一旦你的组织明白了这一点，能帮助你进行管理的工具和技术将会奇迹般地出现。

本文翻译做者为：dogstar，发表于开源中国我的博客；欢迎转载，但请注明出处，谢谢！