企业如何完成DevOps转变:马太航CSDN研发频道推出了2014年DevOps实践调查活动，据活动报告显示：有60%的用户表示只知道Dev
Ops概念，但尚未使用；有37%的开发者听说过DevOps并且很感兴趣正准备使用；能够熟练使用的用户只占到19%。根据CSDN的数
据可以很明显发现DevOps依旧是一个很新鲜的概念，也势必在先进的开发—运维工具推动下变成当前软件开发的潮流，然而如何实施DevO
ps依旧困惑着企业管理者们。众所周知，推进DevOps应从文化、流程和工具三部分来实施DevOps，但是具体如何实施却一头雾水。突
然变革是不可能的，只会使开发人员和运维人员都无法适应新环境，从而怨声载道。DevOps的理念要求开发人员和运维人员在传统思维上改变
的同时，也在技术上互相了解彼此的工作方式。那么，从文化和技术上交替改变或许能让开发人员和运维人员更能欣然接受这种新的工作方式。实施
DevOps首先该做的事是在组织内对架构和应用层启用指标监控。当开发人员添加或修改代码以满足客户新的需求时，只会关注代码改变后的直
接结果——是否实现了某个功能。但是运维人员会在系统运行中获得内存利用率、CPU利用率等参数，以此来分析代码改变对系统运行的真实影响
,这种场景却是屡见不鲜的，可以通过在Graphite中监控系统指标，并提供开发人员相关的API来解决。运维人员搭建一个监控系统，同
时调用Statsd和Graphite的接口，开发人员在系统中增加几行代码，以此来获得CPU利用率、内存利用率等信息的图像表示，从而
实时监控代码改变后对系统的真实影响。在完成指标监控后，然后应对基础架构实施文档化。根据DevOps的思想，开发人员应该更加了解运维
系统人员的工作方式，加深对系统架构的认知。通过基本的高阶流程图来绘制请求流程，从而反映软件对请求的处理情况。同时，记录系统架构中每
个模块的具体作用及优势，并记录新服务器的上线过程、潜在故障和解决方案。通过这些记录来提高开发人员对系统架构的认知程度。指标监控和架
构文档化实现了开发人员对系统运行情况和系统架构的了解，并实现了开发和运维在监控和文档上的沟通、协作。接下来就要解决系统内部机制的问
题。开发环境和生产环境问题一直是系统稳定性的主要原因，通过引入Vagrant工具，来封装一个Linux开发环境，分发给团队成员，成
员可以在自己喜欢的桌面系统（Mac/Windows/Linux）上开发程序，代码却能统一在封装好的环境里运行。由于Vagrant使
用VirtualBox虚拟化系统，通过使用Chef创建自动化虚拟环境。这样就很容易解决开发环境与生产环境不尽相同的问题，并解决了开
发人员和运维人员手动配置脚本和文件所产生的一些BUG。在完成这些工具和流程的改变后就需要企业进行思维的改变了，缓慢而有效的进行De
vOps的文化改变。共同的办公地点和办公时间不失为一种行之有效的方法，降低开发—运维的敌意，增进彼此的团队精神，认知到彼此都只是软
件开发生命周期中的一部分。在完成这些思维和工具的改变后就要进行最后的改变——Pull请求、代码复审和持续集成。当开发人员需要满足新
的需求时，在Vagrant中配置好的虚拟机上进行变更，并更新发布一个Pull请求，提交到运维人员手中进行审查与完备性测试，从而反馈
结果，通过则Pull请求被合并，存在问题就可以直接删除Vagrant中的虚拟机以重新开发需求。同时，通过类似Jenkins的持续集
成服务器去验证运维人员用于创建容器环境的脚本是否正确，或者冒烟测试等方式。当企业完成这些部署后，就可以充分享受DevOps带来的快
捷开发的益处了。开发与运维的更多交流与协助，使得产品能够更高频率的部署交付，减少了因进行大规模升级变更的停机时间。开发对系统代码更加负责，运维对系统稳定的管理也变得更加轻松。 |
|
