我眼中的DevOps(转)

 过去一年以来，一批来自欧美的、不墨守陈规的系统管理员和开发人员一直在谈论一个新概念：DevOps。DevOps 就是开发（Development）和运维（Operations）这两个领域的合并。（若是没错的话，DevOps还包括产品管理、QA、*winces* 甚至销售等领域）

脱节(The Broken)

那么……为何要合并这两个领域？缘由不少，但首要缘由是：咱们目前的工做流程是脱节的。绝对的脱节。不少公司的开发部门和运维部门之间存在的深入矛盾，其实就是这个“脱节”形成的。（意译，求斧正）

下面是一个你们都基本熟悉的例子：部署软件产品。

 

开发部门要开发一款新产品。这款产品要使用最新最炫的技术，来保证客户的全部花俏的需求，从而给公司带来百万美圆的利润。这款产品被要求使用最新的技术和运行平台，还得立刻交付。因而开发部门没日没夜的加班、赶代码（cuts code like crazy），终于如期完成了任务。而后他们把本身的“杰做”一股脑的甩给了运维部门，后者还没能彻底接手，前者已经火烧眉毛的开始了庆功会。

接到产品后，运维部门每一个人的心中都充满了恐惧。

下面就是运维部门的恐惧之源：（{A.B.C}表示A或B或C之一）

• 这款优秀的产品在目前的底层平台上没法运行，由于这个平台{太古老了，空间不足，不支持某某版本}
• 这款产品的体系结构跟咱们的{存储，网络，部署，安全}模型不匹配。
• 这款产品的{ 报告，安全，监视，备份，服务提供} 咱们搞不懂 ，因此无法把它作成实际可用的产品。

尽管伴随着不绝于耳的抱怨和咒骂，运维部门最终仍是把这款产品安装好了。不幸的是，因为作了不少蹩脚的修改和不合理的强迫式运行，这款产品的性能最后被归结为：终极失败（Epic Fail）。

因而很是沮丧的运维部门开始记录各类问题，源源不断的给开发部门提Issue。而开发部门的回应基本上都是：

• 这不是咱们的错 —— 咱们的代码很是完美——而是（运维部门的）部署作的太差劲了。
• 运维部门比较笨，他们不懂新技术—— 为何他们无法实现最新的技术呢？为何他们这么落伍呢？
• 在个人机器上运行的没问题啊……

两个部门之间的交流很快变成了一场狂风暴雨。客户（以及股东、投资方和管理层）则成了蒙受损失的失败方。最终公司损失了无数的金钱，你们也都失业了。终极的失败。

DevOps 又有啥不一样？它有什么好处？

DevOps 就是千方百计的避免这种“终极失败”，同时让你们用更聪明更有效的方式去工做。它是一种框架，包含了不少优秀想法和原则，它鼓励开发部门和运维部门通力合做。在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。

DevOps 也不只仅是一种软件的部署方法。它经过一种全新的方式，来思考如何让软件的做者（开发部门）和运营者（运营部门）进行合做与协同。使用了DevOps模型以后，会使两个部门更好的交互，使二者的关系获得改善，从而让不少领域从中受益，例如：自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提供（provisioning）等等。

“对于DevOps是什么？” 这个问题，DevOps社区中的每一个人的回答都不尽相同。由于咱们的工做经验不一样，关注的问题也不一样。就我我的而言，DevOps分红四大部分：

简单

KISS（Keep it Simple and Stupid，简单就是美）原则是最重要的。因此本段文字也很简单。咱们要尽可能提供简单、可重用的解决方案。“简单”节约了书写文档、培训和提供支持的时间。“简单”增长了沟通的速度、避免混淆、减小了开发和运维出错时的风险。“简单”让人更快的发布产品。

部门之间关系

早参与，多参与。对于开发人员，要让运维人员常驻到开发部门，全程参与开发流程。邀请运维人员参与你的Scrum或者开发会议，与他们分享项目计划、分享新技术的点子和心得。搜集功能性需求（指开发人员用到的需求）的同时也要搜集运维方面的需求。把对于“发布、备份、监控、安全、配置管理和系统功能”的测试做为一项独立的项目流程。软件产品在开发时解决的问题越多，那么在使用时暴露给用户的问题就越少。给运维人员作培训，让他们弄清楚项目的体系结构和核心代码。若是运维人员在反馈bug时提供的信息越多，那么你花在排查问题（trouble-shooting) 的时间就越少，这个bug也就会更快的被解决掉。

对于运维人员，在遇到问题时须要把开发人员加进来，你们一块儿解决问题。邀请开发人员参与大家的会议，分享项目进度（roadmaps），而且共同修订工做计划。运维人员必定要了解开发部门下一步的工做方向，从而确保产品运行的底层平台可以良好的支持最新技术。开发人员也会带来相关的技术、知识和工做，帮助大家改善产品的运行环境，使其更加易于维护、简洁有效。

有一些开发领域的概念，例如：“要根据API而非封闭的interface来构建工具”，分布式版本控制，驱动测试开发，以及诸如敏捷开发、看板管理（Kanban）和Scrum等方法论。若是把这些概念应用在运维领域，一样会产生革命性的变革。

不要害怕新点子和新技术。咱们能够随时随地的向他人学习，哪怕是一句“咱们不再要那样作了！”也会让咱们从中获益。尽管处于不一样的部门，可是咱们要共同窗习、共同成长，这样才能协同工做的更好！

按照从高到低的顺序，有效的沟通方式应该是：面对面交流 、视频会议、电话、即时通信软件、Email。

工做中的流程

有本身的流程管理(process engineering)—— 从原始的笔录到 ISO9001。但它们都存在一个关键的缺陷：过于理想化，它要求每一个步骤都必须成功执行。例如：为了搭建一台新主机，会有下列一套简单的流程：

• 步骤一：装机（把各个硬件组装到一块儿）。
• 步骤二：接线、通电。
• 步骤三：安装操做系统。
• 接下来还有步骤4、5、六。

若是一切顺利的话，第N步结束以后就会有一个功能完整、运行正常的新主机。但万一有个流程没跑通怎么办？好比说在某个步骤断了，走不下去了，或者在这一步获得了异常的输出，有没有另外的步骤来处理这个异常？

因此，流程绝对不会从头至尾一路顺风，因此咱们要把每一步流程都认真对待，找出全部潜在的问题和障碍。跟软件产品同样，在流程的管理中也要有异常处理。咱们没必要作到精确预见每个问题，但必定要保证：即便流程出错，它还能往下走。

把不一样领域的全部流程串到一块儿。这些领域包括：部署、监控、能力计划(capacity planning) 等等。从逻辑上讲，“部署”是软件开发周期的最后一环，因此它应该属于“开发流程”，而非“运维流程”。另外一个例子是度量和监控。在开发领域，若是不理解底线标准和估算，就什么评估都作不了。把开发部门和运维部门的流程衔接在一块儿，也会让两个部门更好的配合、相互理解、承担共同的责任。最后还有个优势：文档只须要一份而不是两份（开发一份、运维一份），从而节省了资金。

自动化，自动化，仍是自动化。构建或使用简单、可扩展的工具（确保提供API, 机器可读的输入、输出 -- 参考 James White的文章：Infrastructure Manifesto）。使用Puppet一类的工具作配置管理。要扩展这些自动化工具，使其可以支持多个领域（开发领域和运维领域），而且在产品的不一样环境（开发环境、测试环境、发布环境和生产环境）中使用相同的工具（也叫end-to-end）。这样不但会在产品支持和管理方面带来经济效益，并且也能够在编写新代码的同时，进行产品的发布和管理。

最后，在构建流程和自动化时，要把KISS原则牢记于心。越复杂就越易错。只有简单的流程和工具才易于实现、易于管理和易于维护。

持续改进

不要中止创新和学习。当今技术发展的很快，客户的需求也每每如此。把“持续改进和持续集成” 加入到你的工具和流程中去，这也是运维人员向（优秀的）开发人员学习的好途径，能够学到诸如测试驱动开发等最佳实践。例如：能够向你的部署流程中加入单元测试。作监控时也应该增长些行为测试，提升交付质量。尝试用开发领域中的工具（例如Hudson）在运维领域中作些工做（例如浏览数据(explore）、测量性能（measure)等等）。

要不断的总结教训。要积极主动的、在不一样领域寻找错误的根源。 一旦收到错误报告，就果断把开发小组和运维小组找来，一块儿解决这个问题。有时候开发人员很简单的几回代码重构，就能够很好的避免底层运行环境的改变，减小运维人员的负担。总之，遇到问题时，开发部门和运维部门要密切配合、共同解决，而不是互相推诿、踢皮球。

对我来讲...

最后，对我来讲，DevOps 的主要内容是：跟谁共同工做、如何共同工做。它最吸引个人地方就是致力于把不一样部门不一样分工的人召集到一块儿，共同努力解决问题。这样的工做环境，是我所憧憬的乐园。

关于译者

申思惟，2005年本科毕业于华南理工大学计算机学院。一直从事Web领域的开发，3年多Java、2年多Ruby on Rails的工做经验。目前在摩托罗拉公司工做，一名普通的程序员。

声明：本文已获原创做者James Turnbull的许可。

原文连接：http://article.yeeyan.org/view/139924/170387

英文连接：http://www.kartar.net/2010/02/what-devops-means-to-me/