软件开发模式，DevOps

参考⽂献：历史回顾

为了能够更好的理解什么是DevOps，我们很有必要对当时还只有程序员(此前还没有派⽣出开发者，前台⼯程师，后台⼯程师之类)这个称号存在的历史进⾏⼀下回顾。如编程之道中所⾔：

⽼⼀辈的程序员是神秘且深奥的。我们没法揣摩他们的想法，我们所能做的只是描述⼀下他们的表象。清醒的像⼀只游过⽔⾯的狐狸警惕的像⼀位战场上的将军友善的像⼀位招待客⼈的⼥主⼈单纯的像⼀块未经雕琢的⽊头深邃的像⼀潭幽深洞⽳中漆⿊的池⽔

程序员开发了机器语⾔，机器语⾔⼜产⽣了汇编语⾔，汇编语⾔产⽣了编译器，如今的语⾔已经多不胜数。每⼀种语⾔都有其各⾃的谦卑⽤途。每⼀种语⾔都表达出软件的阴和阳。每⼀种语⾔都在此道之中有其⼀席之地。

遥想当年，软件程序员的⼤部分办公司那时还被称作实验室，程序员那时还叫做科学家。为了开发出⼀套优秀的软件，程序员们必须深⼊了解他们需要的应⽤相关的所有问题。他们必须清楚知道这个软件应⽤在什么场合，这个软件是必须在什么系统上运⾏。本质上说，程序员对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术⽀持。

过了不久，⼈类(客户)贪婪的特性就开始表现出来，他们开始不断的进⾏更多的索求。更快的速度，更多的功能，更多的⽤户，更多的所有所有。

作为⼀类谦虚、谦卑、且平静的⽣物，我们的⽼⼀辈程序员们将很难在这种爆发性的过度的需求索取中幸存。最好的取胜办法就是往不同的⽅向进化成不同的新物种。很快，程序员这个称号就开始绝迹于江湖，⽽那些叫做开发者、软件⼯程师、⽹络管理员、数据库开发者、⽹页开发者、系统架构师、测试⼯程师等等更多的新物种就开始诞⽣。快速进化和快速适应外界的挑战成为了他们的DNA的⼀部分。这些新的种族可以在⼏个星期内就完成进化。⽹页开发者很快就能进化成后台开发者，前台开发者，PHP开发者，Ruby开发者，Angular开发者…多得让⼈侧⽬。

很快他们就都忘却了他们都是起源于程序员这个共同的祖先的事实，忘却了曾经有过这么⼀个单纯且平静的，想要让这个世界变得更好的科学家。然后他们开始不断的剑拔弩张，都声称⾃⼰才是“程序员”的纯⾎统继承⼈。

随着时间的转移，各门各派开始独占⼭头，很少进⾏交流互动，只有在迫不得已的时刻才会进⾏沟通。他们开始不再为同源的遥远的同宗兄弟们的成功⽽欢呼雀跃，甚⾄再也不会时把的遥寄张明信⽚进⾏嘘寒问暖。

但是在深夜仰望星空的时候，他们还是会发现他们的⼼底深处的程序员基因还是会不停的闪烁着，期盼着这闪烁的⽕花能照亮整个银河系并带来和平。

在这场⾃私且以⾃我为中⼼的欲征服世界的赛跑旅程⾥，程序员的⼦孙们早把他们真正的⼯作⽬标置之脑后-为客户解决问题。⾯对⼀拖再拖的项⽬交付⽇期，昂贵的开发代价，甚⾄最终失败的项⽬，客户们开始对这种情况深恶痛绝。

偶尔，也会有⼀个闪亮的明星站出来，灵机⼀动的提供⼀种办法来尝试结束这种混乱并带来和平。所以瀑布开发流程就应运⽽⽣了。这是⼀个⾮常了不起的创意，因为它利⽤了不同团队的开发者们只在必须的时候才进⾏沟通的这个事实。当⼀个团队完成了他们的⼯作的时候，它就会和下游的团队进⾏交流并把任务进⾏往下传，如此⼀级接⼀级的传递下去，永不回⾸。

这种⽅式在⼀段时间内发挥了效⽤，但很快，⼀如既往，贪婪的⼈们(客户)⼜开始提出更多的诉求。他们希望能够更多地参加到整个软件的开发流程中来，不时的提出他们的建议，甚⾄在很晚的时候还提出改需求这种丧⼼病狂的事情来。

结果就是如⼤家有⽬共睹的事实⼀样，软件项⽬⾮常容易失败这个说法已经作为⼀个⾏业标准被⼈们所接受。数据表明超过50%的项⽬最终都是以失败告终的。更可悲的是，在当时看来，⼈们对这种情况是束⼿⽆策。

值得庆幸的是，每⼀个时代总会有那么⼏个思想开放的英雄如漆⿊中的萤⽕⾍般冒出来。他们知道这些不同团队的开发者们必须要找到⼀个可以协同⼯作、进⾏交流、并且能够弹性的向客户保证对⽅将会拿到最优的解决⽅案的⽅式。这种尝试最早可以追溯到1957年，伟⼤的约翰·冯·诺依曼和同⾏们的努⼒。但是我们最终却是等到2001年才收获到⾰命的果实，当时⾏业的⼗多个精英创造出了如今闻名世界的“敏捷宣⾔”。

敏捷宣⾔基于以下⼗⼆条原则：

我们的⾸要任务是通过尽早地、持续地交付可评价的软件来使客户满意。

乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从⽽为客户赢得竞争优势。频繁交付可使⽤的软件，交付间隔越短越好，可以从⼏个星期到⼏个⽉。

在整个项⽬开发期间，业务⼈员和开发⼈员必须朝⼣⼯作在⼀起。

围绕那些有推动⼒的⼈们来构建项⽬。给予他们所需的环境和⽀持，并且信任他们能够把⼯作完成好。与开发团队以及在开发团队内部最快速、有效的传递信息的⽅法就是，⾯对⾯的交谈。可使⽤的软件是进度的主要衡量指标。

敏捷过程提倡可持续发展。出资⼈、开发⼈员以及使⽤者应该总是共同维持稳定的开发速度。为了增强敏捷能⼒，应持续关注技术上的杰出成果和良好的设计。简洁——最⼤化不必要⼯作量的艺术——是⾄关重要的。最好的架构、需求和设计都源⾃⾃我组织的团队。

团队应该定期反思如何能变得更有战⽃⼒，然后相应地转变并调整其⾏为。

敏捷宣⾔是为银河系带来和平以及维护各⾃的平衡所迈出的很重要的第⼀步。在很长的时间⾥，相⽐此前基于流程和机械化的⽅式，这是第⼀次基于⽂化和“⼈性”来将不同的关键项⽬关系⼈连接在⼀起的⽅式。⼈们开始互相交流，进⾏基本的碰头会议，并开始不断的交流意见和看法。他们开始意识到他们是有着很多⽐想象中还多的共同点的，客户也开始成为他们之中的⼀员，⽽不再是像以往⼀样只是往项⽬砸钱然后开始求神拜佛祈求⼀切顺利如愿。

尽管前⾯还是有不少的障碍需要克服，但是未来已经光明了许多。敏捷意味着开放和拥抱(需求)改变。但是，如果改变过多的话，⼈们就很难专注到最终的⽬标和交付上来。此时精益软件开发就开始破⼟⽽出了。

因为对精益软件开发的着迷以及为了达成放逐和驱赶风险的⽬的，⼀些程序员的⼦孙们就开始探⾸窗外，开始向软件之外的⾏业进⾏取经。他们从⼀家主要的汽车⽣产商⾝上找到了救赎。丰⽥⽣产系统在精益上⾯的成就是不可思议的，同时它们的精益⽣产的经验也是很容易应⽤到软件开发上来的。精益有以下7个原则：杜绝浪费内建质量

创建知识(放⼤学习)延迟决策(尽量延迟决定)快速交付

尊重⼈员(团队授权)全局优化

将这些放到敏捷上去的话，精益原则就能让⼈们在从精神上关注做正确的事情，同时还能够让整个开发流程拥有⾜够的弹性。

⼀旦敏捷和精益软件开发被软件开发团队采纳，那么下⼀步就是把这⼀套原则应⽤到IT团队上来。把IT也纳⼊到整体战略上，然后我们就来到了DevOps跟前了！

进⼊DevOps – ⾼速公路的三条车道

⽼⼀派的软件开发团队成员会包含业务分析员，系统架构师，前端开发者，后端开发者，测试员，等等。优化如敏捷和精益原则等的软件开发流程的关注点就在这些地⽅。⽐如，软件⼀旦达到”可以⽣产“的程度，就会发到系统⼯程师、发布⼯程师、DBA、⽹络⼯程师，安全专家这些“运维⼈员”的⼿上。这⾥该如何将横在Dev(开发)和Ops(运维)之间的鸿沟给填平，这就是DevOps的主要关注点了。

DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸⾄⽣产，将由程序员这个遥远的祖宗所繁衍的所有⼦孙给联合在⼀起。

这是来⾃Gene Kim的对DevOps的最好的解析，如果你还没有看过他的《凤凰项⽬》这本书的话，我建议你真的该好好花时间看看。你不应该重新招聘DevOps⼯程师，且DevOps也不应该是⼀个IT的新部门。DevOps是⼀种⽂化，⼀种理念，且是和IT糅合成⼀整体的。世间没有任何⼯具可以把你的IT变成⼀个DevOps组织，也没有任何⾃动化⽅式可以指引你该如何为你的客户提供最⼤化的效益。

DevOps通常作为下⾯这三个⽅式⽽为⼈所熟知，⽽在我眼⾥我是把它们看成是⼀条⾼速公路上的三条车道。你从第⼀条车道开始，然后加速进⼊到第⼆条车道，最终在第三车道上⾼速⾏驶。

车道1 – 系统级别的整体效率考量是最主要的关注点，这超过对系统中任何⼀个单独个体元素的考虑车道2 – 确保能提供持续不断的反馈循环，且这些反馈不被忽视。车道3 – 持续的学习和吸取经验，不停的进步，快速的失败。车道1 – 获取速度

要采纳DevOps的原则，理解整个运作系统的重要性并对⼯作事项进⾏合适的优先级排序是组织⾸先要学的事情。在整个价值流中不能允许任何⼈产⽣瓶颈并降低整个⼯作流程。

确保⼯作流程的不可中断是⾝处流程中的所有成员的终极⽬标。⽆论⼀个成员或者团队的⾓⾊是什么，他们都必须⼒图对整个系统进⾏深⼊的理解。这种思维⽅式对质量会有着直接的影响，因为缺陷永远不会被下放到“下游“中，这样做的话将会导致瓶颈的产⽣。

确保整个⼯作流程不会被瓶颈堵塞住还不够。⼀个⾼产的组织应该时常考虑该如何提升整个⼯作流程。有很多⽅法论可以做到这⼀点，你不妨去看下“约束理论”，“六西格玛”，精益，或者丰⽥⽣产系统。

DevOps原则不关⼼你⾝处哪个团队，你是否是系统架构师，DBA，QA，或者是⽹络管理员。相同的规则覆盖所有的成员，每个成员都应该遵循两个简单的原则：保持系统运作流程不可中断随时提升和优化⼯作流程车道2 – 换挡加速

不可中断的系统流程是定向的，且预期是从开发流向运维。在⼀个理想的世界中，这就意味着快速的开发出⾼质量的软件，部署，并为客户提供价值。

但是，DevOps并⾮乌托邦式的理想国。如果单向的交付⽅式是可⾏的话，我们的瀑布模式早就能胜任了。评估可交付产品和整个流程中的交流对确保质量是⾄关重要的。这⾥⾸个必须实现的”⾯向上游”的交流通道是从Ops到Dev。

我们独⾃意淫是件⾮常容易的事情，但是获取别⼈的反馈和提供反馈给别⼈才是探究事实真相的正确⽅法。下游的每⼀步(反馈)都必须紧跟着有⼀个上游的确定。

你如何建⽴反馈循环机制并不重要。你可以邀请开发⼈员加⼊技术⽀持团队的会议，或者将⽹络管理员放到Sprint计划会议中去。⼀旦你的反馈机制就绪，反馈能够被接收并被处理，你就已经可以说是⾛到了DevOps⾼速车道上来了。车道3 – 飞速前进

DevOps这条快速车道并不适合意志脆弱的⼈。为了进⼊这条车道，你的组织必须要⾜够的成熟。这⾥充满了冒险和对失败教训的学习，不断的尝试，并认同屡败屡战和不断的实践是⾛向成功这条康庄⼤道的前提条件。在这⾥你应该会经常听到”套路“这个词，这是有原因的。不断的训练和重复所以能培养出⼤师，是因为其让复杂的动作常规化。

但是在你要将这些复杂的动作连接起来之前，你很有必要先去掌握好每⼀个单独步骤。“适合⼤师的动作并不适合新⼿，脱胎换⾻之前你必须先要明⽩道的真谛。“

DevOps的第三个⽅式/快速车道包括每天分配时间来持续的进⾏试验，时常的奖励敢于冒险的团队，并将缺陷特意引⼊到运作系统上来以增加系统的抗击打能⼒。

为了确保你的组织能够消化好这些⽅法，你必须在每个团队之间建⽴好频繁的反馈循环，同时需要确保所有的瓶颈都能够及时的被清理掉，并确保整个系统的运作流程是不可中断的。

实施好这些措施可以让你的组织时刻保持警惕，并能够快速且⾼效的应对挑战。概要 – DevOps清单

下⾯是⼀张你可以⽤来检验你的组织对DevOps的应⽤情况的清单。当然你也可以在⽂章评论后⾯给出你的观点。开发团队和运维团队之间没有障碍。两者皆是DevOps统⼀流程的⼀部分。从⼀个团队流到另⼀个团队的⼯作都能够得到⾼质量的验证⼯作没有堆积，所有的瓶颈都已经被处理好。

开发团队没有占⽤运维团队的时间，因为部署和维护都是处于同⼀个时间盒⾥⾯的。

开发团队不会在周五下午5点后把代码交付进⾏部署，剩下运维团队周末加班加点来给他们擦屁股开发环境标准化，运维⼈员可以很容易將之扩展并进⾏部署

开发团队可以找到合适的⽅式交付新版本，且运维团队可以轻易的进⾏部署。每个团队之间的通信线路都很明确

所有的团队成员都有时间去为改善系统进⾏试验和实践

常规性的引⼊(或者模拟)缺陷到系统中来并得到处理。每次学习到的经验都应该⽂档化下来并分享给相关⼈员。事故处理成为⽇常⼯作的⼀部分，且处理⽅式是已知的总结

使⽤现代化的DevOps⼯具，如Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS等，并不代表你就在正确的应⽤DevOps的原则。DevOps是⼀种思维⽅式。我们所有⼈都是该系统流程的⼀部分，我们⼀起分享共同的时光和交付价值。每个参加到这个软件交付流程上来的成员都能够加速或减缓整个系统的运作速度。系统出现的⼀个缺陷，以及错误配置的团队之间的“防⽕墙”，都可能会使得整个系统瘫痪，

所有的⼈都是DevOps的⼀部分，⼀旦你的组织明⽩了这⼀点，能够帮你管理好这些的⼯具和技术栈就⾃然⽽然的会出现在你眼前了。