4.我眼中的DevOps

我眼中的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)持续改进

不要停止创新和学习,技术发展很快,客户的需求也往往如此,把持续改进和持续集成加入到你的工具和流程,这也是运维人员向优秀开发人员学习的途径.

不断总结教训,积极主动,在不同领域寻找错误的根源.

开发部门和运维部门要密切配合,共同解决,而不是相互推诿

来源张永光的博客