DevOps

软件产品上线的现状

现在很多的开发部门和运维部门之间存在的深刻矛盾。比如部署一款软件产品，这款产品被要求要使用最新的技术和平台，还要马上交付，于是开发部门每日每夜的加班、赶代码，当他们将代码交给运维部门的时候，运维部门没能完全接手，比如以下的原因：

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

当运维部门将安装过程中出现的各种问题反映给开发部门的时候，开发部门的回应基本上都是：

• 这不是我们的错–我们的代码非常完美–而是部署做的太差劲了；
• 运维部门比较笨，他们不懂新技术–为什么他们没办法实现最新的技术;
• 在我的机器上运行的没有问题

两个部门之间的交流很快就变成了一场暴风雨。最终这个项目以失败而告终。

DevOps简介

DevOps就是开发（Development）和运维（Operations）这两个领域的合并。它是一种框架，包含了很多优秀想法和原则，它鼓励开发部门和运维部门通力合作。在DevOps环境中，开发人员和系统管理人员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。

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

DevOps四大部分

简单

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

部门之间关系

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

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

工作中的流程

在产品的不同环境（开发环境、测试环境、发布环境和生产环境）中使用相同的工具（也叫end-to-end）。这样不但会在产品支持和管理方面带来经济效益，而且也可以在编写新代码的同时，进行产品的发布和管理。

持续改进

• 不要停止创新和学习。当今技术发展的很快，客户的需求也往往如此。把“持续改进和持续集成”加入到你的工具和流程中，这也是运维人员向开发人员学习的好途径。
• 不断总结教训。要积极主动的、在不同领域寻找错误的根源。一旦收到错误报告，就果断把开发小组和运维小组找来，一起解决这个问题。有时候开发人员很简单的几次代码重构，就可以很好的避免底层运行环境的改变，减少运维人员的负担。总之，遇到问题时，开发部门和运维部门要密切配合、共同解决、而不是相互推诿、踢皮球。