如何启动公司内部的devops运动－－尤其是后端开发人员&运维

简单的总结一下DevOps让其讨厌的原因：

1. 没有时间专心写代码

2. 强迫开发人员进入一个庞大的知识领域（这里指就是需要成为一名“全栈”开发者）

3. 压力大，任务重，不堪重负

事实是否这样呢？其实不然。无论任何事物，存在即合理。再说哪个公司都不会蠢到让一个只会写代码的开发者去做QA，系统管理员或者DBA，所以我认为不能归到“DevOps”里面去。引用DevOps拥护者Jeff Roth的一句话，“专业知识、协作关系与知识共享之间需要找到合适的平衡点，只有这样才能人尽其才、物尽其用

因为DevOps可以利用云技术，自动化部署，自动化发布等技术。特别是测试，当敏捷做到一定规模时候，需要跨部门，开发人员可能会很主动，有啥新功能要加进去，运维就不干了，很可能就会说you can you up！

其实这个是能够理解的，开发人员把一个软件版本丢给运维人员后，其就会拿该版本产品开始准备将部署上线。这时有个问题出来了，他们需要修改配置文件来适应与开发环境大不相同的真实生产环境。一般情况来说他们是在重复之前在环境中已完成的部署工作；一旦出了问题，他们很可能引入新的漏洞。

这就是他们所担心的问题，如果不反复的测试，运维人员肯定不会上线。

在完成指标监控后，然后应对基础架构实施文档化。根据DevOps的思想，开发人员应该更加了解运维系统人员的工作方式，加深对系统架构的认知。通过基本的高阶流程图来绘制请求流程，从而反映软件对请求的处理情况。同时，记录系统架构中每个模块的具体作用及优势，并记录新服务器的上线过程、潜在故障和解决方案。通过这些记录来提高开发人员对系统架构的认知程度。

　　指标监控和架构文档化实现了开发人员对系统运行情况和系统架构的了解，并实现了开发和运维在监控和文档上的沟通、协作。接下来就要解决系统内部机制的问题。开发环境和生产环境问题一直是系统稳定性的主要原因，通过引入Vagrant工具，来封装一个Linux开发环境，分发给团队成员，成员可以在自己喜欢的桌面系统(Mac/Windows/Linux)上开发程序，代码却能统一在封装好的环境里运行。由于Vagrant使用VirtualBox虚拟化系统，通过使用Chef创建自动化虚拟环境。这样就很容易解决开发环境与生产环境不尽相同的问题，并解决了开发人员和运维人员手动配置脚本和文件所产生的一些BUG。

　　在完成这些工具和流程的改变后就需要企业进行思维的改变了，缓慢而有效的进行DevOps的文化改变。共同的办公地点和办公时间不失为一种行之有效的方法，降低开发—运维的敌意，增进彼此的团队精神，认知到彼此都只是软件开发生命周期中的一部分。

　　在完成这些思维和工具的改变后就要进行最后的改变——Pull请求、代码复审和持续集成。当开发人员需要满足新的需求时，在Vagrant中配置好的虚拟机上进行变更，并更新发布一个Pull请求，提交到运维人员手中进行审查与完备性测试，从而反馈结果，通过则Pull请求被合并，存在问题就可以直接删除Vagrant中的虚拟机以重新开发需求。同时，通过类似Jenkins的持续集成服务器去验证运维人员用于创建容器环境的脚本是否正确，或者冒烟测试等方式。

　　当企业完成这些部署后，就可以充分享受DevOps带来的快捷开发的益处了。开发与运维的更多交流与协助，使得产品能够更高频率的部署交付，减少了因进行大规模升级变更的停机时间。开发对系统代码更加负责，运维对系统稳定的管理也变得更加轻松