相关文章: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等方法论。如果把这些概念应用在运维领域,同样会产生革命性的变革。
不要惧怕新点子和新技术。我们可以随时随地的向他人学习,哪怕是一句“我们再也不要那样做了!” 也会让我们从中获益。尽管处于不同的部门,但是我们要共同学习、共同成长,这样才能协同工作的更好!
按照从高到低的顺序,有效的沟通方式应该是:
1. 面对面交流
2. 视频会议
3. 电话
4. 即时通讯软件
5. Email
工作中的流程
不要低估流程和自动化的作用。很多公司都有自己的流程管理(process engineering)—— 从原始的笔录到 ISO9001。但它们都存在一个关键的缺陷:过于理想化,它要求每个步骤都必须成功执行。例如:为了搭建一台新主机,会有下列一套简单的流程:步骤一:装机(把各个硬件组装到一起)。步骤二:接线、通电。步骤三:安装操作系统。接下来还有步骤四、五、六。如果一切顺利的话,第N步结束之后就会有一个功能完整、运行正常的新主机。但万一有个流程没跑通怎么办?比如说在某个步骤断了,走不下去了,或者在这一步得到了异常的输出,有没有另外的步骤来处理这个异常?
所以,流程绝对不会从头到尾一帆风顺,所以我们要把每一步流程都认真对待,找出所有潜在的问题和障碍。跟软件产品一样,在流程的管理中也要有异常处理。我们不必做到精确预见每一个问题,但一定要保证:即使流程出错,它还能往下走。
把不同领域的所有流程串到一起。这些领域包括:部署、监控、能力计划(capacity planning) 等等。从逻辑上讲,“部署”是软件开发周期的最后一环,所以它应该属于“开发流程”,而非“运维流程”。另一个例子是度量和监控。在开发领域,如果不理解底线标准和估算,就什么评估都做不了。把开发部门和运维部门的流程衔接在一起,也会让两个部门更好的配合、相互理解、承担共同的责任。最后还有个优点:文档只需要一份而不是两份(开发一份、运维一份),从而节省了资金。
自动化,自动化,还是自动化。构建或使用简单、可扩展的工具(确保提供API, 机器可读的输入、输出 -- 参考 James White的文章:Infrastructure Manifesto)。使用Puppet一类的工具做配置管理。要扩展这些自动化工具,使其能够支持多个领域(开发领域和运维领域),并且在产品的不同环境(开发环境、测试环境、发布环境和生产环境)中使用相同的工具(也叫end-to-end)。这样不但会在产品支持和管理方面带来经济效益,而且也可以在编写新代码的同时,进行产品的发布和管理。
最后,在构建流程和自动化时,要把KISS原则牢记于心。越复杂就越易错。只有简单的流程和工具才易于实现、易于管理和易于维护。
持续改进
不要停止创新和学习。当今技术发展的很快,客户的需求也往往如此。把“持续改进和持续集成” 加入到你的工具和流程中去,这也是运维人员向(优秀的)开发人员学习的好途径,可以学到诸如测试驱动开发等最佳实践。例如:可以向你的部署流程中加入单元测试。做监控时也应该增加些行为测试,提高交付质量。尝试用开发领域中的工具(例如Hudson)在运维领域中做些工作(例如浏览数据(explore)、测量性能(measure)等等)。
要不断的总结教训。要积极主动的、在不同领域寻找错误的根源。 一旦收到错误报告,就果断把开发小组和运维小组找来,一起解决这个问题。有时候开发人员很简单的几次代码重构,就可以很好的避免底层运行环境的改变,减少运维人员的负担。总之,遇到问题时,开发部门和运维部门要密切配合、共同解决,而不是互相推诿、踢皮球。
对我来说...
最后,对我来说,DevOps 的主要内容是:跟谁共同工作、如何共同工作。它最吸引我的地方就是致力于把不同部门不同分工的人召集到一起,共同努力解决问题。这样的工作环境,是我所憧憬的乐园。