简单历史回顾
为了更好地理解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,发表于开源中国个人博客;欢迎转载,但请注明出处,谢谢!