DevOps，我们憧憬的研发乐园
发布时间:
2017-07-17
研发和运维似乎是两个不能分离却又剑拔弩张的兄弟，既密不可分，又矛盾重重，真的是剪不断理还乱~我们经常见到研发部门和运维部门的攻城狮兄弟们互相埋怨、指责，而且似乎已经是常态了。那么，这种凌乱的状态是否有解呢？
研发和运维似乎是两个不能分离却又剑拔弩张的兄弟，既密不可分，又矛盾重重，真的是剪不断理还乱~我们经常见到研发部门和运维部门的攻城狮兄弟们互相埋怨、指责，而且似乎已经是常态了。那么，这种凌乱的状态是否有解呢？
今天就要跟大家说说这样一个概念：DevOps。DevOps就是开发（Development）和运维（Operations）这两个领域的合并。广泛来说呢，DevOps还包含产品管理、QA甚至销售等领域。今天，小梦就从下面三个方面来跟大家聊聊DevOps。
1
为什么会有DevOps？
那么，为什么要合并"开发"和"运维"这两个领域？原因很多，但首要原因是：我们目前的工作流程是脱节的。很多公司的开发部门和运维部门之间存在的深刻矛盾，其实就是这个"脱节"造成的。
下面举一个大家都熟悉的例子：部署软件产品。
开发部门要开发一款新产品。这款产品要使用最新最炫的技术，来保证客户的所有花俏的需求，从而给公司带来百万美元的利润。这款产品被要求使用最新的技术和运行平台，还得马上交付。于是开发部门没日没夜的加班、赶代码，终于如期完成了任务。然后他们把自己的"杰作"一股脑儿的甩给了运维部门，后者还没能完全接手，前者已经迫不及待的开始了庆功会。
然而，问题来了。接到产品后，运维部门每个人的心中都充满了恐惧：
● 这款优秀的产品在目前的底层平台上无法运行，因为这个平台太古老了，空间不足，不支持某某版本。。。
● 这款产品的体系结构跟我们的存储，网络，部署，安全模型不匹配。。。
● 这款产品的报告、安全、监视、备份、服务提供我们搞不懂，所以没法把它做成实际可用的产品。。。
尽管伴随着不绝于耳的抱怨和咒骂，运维部门最终还是把这款产品安装好了。不幸的是，由于做了很多蹩脚的修改和不合理的强迫式运行，这款产品的性能最后被归结为：终极失败（Epic Fail）。
于是非常沮丧的运维部门开始记录各种问题，源源不断的给开发部门提Issue。而开发部门的回应基本上都是：
● 这不是我们的错——我们的代码非常完美——而是（运维部门的）部署做的太差劲了。
● 运维部门比较笨，他们不懂新技术——为什么他们没法实现最新的技术呢？为什么他们这么落伍呢？
● 在我的机器上运行的没问题啊……
两个部门之间的交流很快变成了一场暴风骤雨。客户（以及股东、投资方和管理层）则成了蒙受损失的失败方。最终公司损失了无数的金钱，大家也都失业了。终极的失败。
可是之前如果他们运用了DevOps进行开发和运维，结果也许完全不同。
2
DevOps有什么好处？
DevOps 就是想方设法的避免这种"终极失败"，同时让大家用更聪明更有效的方式去工作。它是一种框架，包含了很多优秀想法和原则，它鼓励开发部门和运维部门通力合作。在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。
DevOps也不仅仅是一种软件的部署方法。它通过一种全新的方式，来思考如何让软件的作者（开发部门）和运营者（运营部门）进行合作与协同。使用了DevOps模型之后，会使两个部门更好的交互，使两者的关系得到改善，从而让很多领域从中受益，例如：自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提供（provisioning）等等。
3
DevOps意味着什么？
用四个部分来解释DevOps应该最容易理解：
简单
KISS（Keep it Simple and Stupid，简单就是美）原则是最重要的。所以本段文字也很简单。我们要尽量提供简单、可重用的解决方案。"简单"节约了书写文档、培训和提供支持的时间。"简单"增加了沟通的速度、避免混淆、减少了开发和运维出错时的风险。"简单"让人更快的发布产品。
部门之间关系
早参与，多参与。对于开发人员，要让运维人员常驻到开发部门，全程参与开发流程。邀请运维人员参与你的Scrum或者开发会议，与他们分享项目计划、分享新技术的点子和心得。搜集功能性需求（指开发人员用到的需求）的同时也要搜集运维方面的需求。把对于"发布、备份、监控、安全、配置管理和系统功能"的测试作为一项独立的项目流程。软件产品在开发时解决的问题越多，那么在使用时暴露给用户的问题就越少。给运维人员做培训，让他们弄清楚项目的体系结 构和核心代码。如果运维人员在反馈bug时提供的信息越多，那么你花在排查问题（trouble-shooting) 的时间就越少，这个bug也就会更快的被解决掉。
不要惧怕新点子和新技术。我们可以随时随地的向他人学习，哪怕是一句"我们再也不要那样做了！"也会让我们从中获益。尽管处于不同的部门，但是我们要共同学习、共同成长，这样才能协同工作的更好！
按照从高到低的顺序，有效的沟通方式应该是：面对面交流 、视频会议、电话、即时通讯软件、Email。
工作中的流程
有自己的流程管理(process engineering)—— 从原始的笔录到 ISO9001。但它们都存在一个关键的缺陷：过于理想化，它要求每个步骤都必须成功执行。例如：为了搭建一台新主机，会有下列一套简单的流程：
步骤一：装机（把各个硬件组装到一起）。
步骤二：接线、通电。
步骤三：安装操作系统。
接下来还有步骤四、五、六。
如果一切顺利的话，第N步结束之后就会有一个功能完整、运行正常的新主机。但万一有个流程没跑通怎么办？比如说在某个步骤断了，走不下去了，或者在这一步得到了异常的输出，有没有另外的步骤来处理这个异常？
所以，流程绝对不会从头到尾一帆风顺，所以我们要把每一步流程都认真对待，找出所有潜在的问题和障碍。跟软件产品一样，在流程的管理中也要有异常处理。我们不必做到精确预见每一个问题，但一定要保证：即使流程出错，它还能往下走。
在构建流程和自动化时，要把KISS原则牢记于心。越复杂就越易错。只有简单的流程和工具才易于实现、易于管理和易于维护。
持续改进
不要停止创新和学习。当今技术发展的很快，客户的需求也往往如此。把"持续改进和持续集成" 加入到你的工具和流程中去，这也是运维人员向（优秀的）开发人员学习的好途径，可以学到诸如测试驱动开发等最佳实践。例如：可以向你的部署流程中加入单元测试。做监控时也应该增加些行为测试，提高交付质量。尝试用开发领域中的工具（例如Hudson）在运维领域中做些工作（例如浏览数据(explore）、测量性能（measure)等等）。
要不断的总结教训。要积极主动的、在不同领域寻找错误的根源。 一旦收到错误报告，就果断把开发小组和运维小组找来，一起解决这个问题。有时候开发人员很简单的几次代码重构，就可以很好的避免底层运行环境的改变，减少 运维人员的负担。总之，遇到问题时，开发部门和运维部门要密切配合、共同解决，而不是互相推诿、踢皮球。
DevOps最吸引人的地方就是致力于把不同部门不同分工的人召集到一起，共同努力解决问题。这样的工作环境，应该是所有研发及运维人员所憧憬的乐园吧~
关键词：
联系我们
服务热线：010-82435075
公司地址：北京市朝阳区望京街10号 望京SOHO T2-B座706
新浪微博：http://weibo.com/itdreamwork
定期分享技术干货
数字化转型落地实践萃取
PMI, PMP, PMBOK 和 OPM3 是 Project Management Institute, Inc. 的注册商标