我眼中的DevOps
过去一年来,一批不默守陈规的系统管理员和开发人员一直在谈论一个新概念: DevOps
DevOps就是开发(Development)和运维(Operations)这两个领域的合并
1.脱节
我们目前的工作流程是脱节的,很多公司的开发部门和运维部门之间存在深刻矛盾
2.例如–部署软件产品
1)开发部门要开发一个新产品,这个产品使用最新的技术,保证客户所有花哨的需求,从而给公司带来可观的利润,这个产品被要求使用最新的技术和平台,马上交付
2)开发部门没日没夜的加班,赶代码,终于如期完成,然后把自己的杰作一股脑的甩给了运维部门,
后者还没能完全接手,前者已经迫不及待的开庆功会了
3)接到产品后,运维部门每个人的心中都充满了恐惧
这个产品在底层平台无法运行(平台太古老了)
这个产品的体系结构跟模型(存储,网络,部署,安全)不匹配
这个产品(报告,安全,监视,备份)不懂
4)于是运维部门开始记录各种问题,源源不断给开发部门提Issue,而开发部门的回应基本都是:
部署太差了
部署部门不懂技术
在我的机器上没问题
最终两个部门之间相互推卸责任,客户蒙受损失,公司损失
3.DevOps
DevOps就是想方设法的避免这种失败,同时让大家用更聪明更有效的方式去工作,它是一种框架,包含了很多优秀的想法和原则,鼓励开发与运维通力合作,在DevOps环境中,开会人员和系统管理员会构建一些关系,流程和工具,从而更好的与客户互动,最终提供更好的性能,备份与恢复安全等等
4.DevOps是什么?
1)简单
KISS (Keep it Simple and Stupid,简单就是美),尽量提供简单,可重用的解决方案.简单节约了书写文档,培训和提供支持的时间,增加了沟通的速度,避免混淆,减少了开发和运维出错时的风险,更快的发布产品
2)部门之间关系
早参与,多参与,对于开发人员,要让运维人员常驻开发部门,全程参与开发流程,与他们共享项目计划,分享新技术,搜集功能性需求同时搜集运维方面的需求,把发布,备份,监控,安全等测试作为一项独立的项目流程,开发时解决的问题越多,在使用时暴露的问题就越少.如果运维反馈bug时提供的信息越多,你在排查问题的时间就越少
有效的沟通方式: 面对面,视频会议,电话,即时通讯软件,Email
3)工作中的流程
有自己的流程管理(process engineering),从原始的笔录到ISO9001,但它们都有关键的缺陷: 过于理想化,它要去每一步都必须成功,例如:搭建主机
装机
接线,通电
安装操作系统等
如果一切顺利,第N步结束就有一台运行正常的主机,如果有一步没炮筒,就走不下去了
流程绝对不会从头到尾一帆风顺,所以我们要把每一步流程都认真对待,找出所有潜在问题和障碍,我们不必做到精确预见每一个问题,但一定要保证: 即使流程出错,还能往下走.
4)持续改进
不要停止创新和学习,技术发展很快,客户的需求也往往如此,把持续改进和持续集成加入到你的工具和流程,这也是运维人员向优秀开发人员学习的途径.
不断总结教训,积极主动,在不同领域寻找错误的根源.
开发部门和运维部门要密切配合,共同解决,而不是相互推诿