我眼中的DevOps

《我眼中的DevOps》要点：
本文介绍了我眼中的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.但它们都存在一个关键的缺陷：过于理想化,它要求每个步骤都必须成功执行.例如：为了搭建一台新主机,会有下列一套简单的流程：

• 步骤一：装机(把各个硬件组装到一起).
• 步骤二：接线、通电.
• 步骤三：安装操作系统.
• 接下来还有步骤四、五、六.

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

（编辑：ASP站长网）