我眼中的DevOps(转)

最新推荐文章于 2024-01-23 01:41:06 发布

weixin_33901926

最新推荐文章于 2024-01-23 01:41:06 发布

阅读量66

点赞数 1

文章标签： devops 运维 java

过去一年以来，一批来自欧美的、不墨守陈规的系统管理员和开发人员一直在谈论一个新概念：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步结束之后就会有一个功能完整、运行正常的新主机。但万一有个流程没跑通怎么办？比如说在某个步骤断了，走不下去了，或者在这一步得到了异常的输出，有没有另外的步骤来处理这个异常？

所以，流程绝对不会从头到尾一帆风顺，所以我们要把每一步流程都认真对待，找出所有潜在的问题和障碍。跟软件产品一样，在流程的管理中也要有异常处理。我们不必做到精确预见每一个问题，但一定要保证：即使流程出错，它还能往下走。

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

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

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

持续改进

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

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