我所经历的”DevOps“

DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间 沟通合作文化、运动或惯例。(DevOps的概念始于2008年Patrick Debois和Andrew Clay Shafer关于敏捷基础架构概念的讨论) “文化"这个说法非常有意思,因为单独从DevOps这个词来看,它是由两个角色词组合而成,软件开发中,这两者角色是缺一不可的(当然还是其它诸如:测试、产品、运营等等),每个角色都有各自的文化的,比如软件开发人员的文化可能是 talk is cheap, show me your code ,运维人员的文化可能是可用性要达到99.9999%, 测试的文化可能是:测出更多bug ……

文化是有一定隔离性,比如最近NBA的这些事,文化不一样结果就是互相不理解,所以达成共识很重要。而在软件开发领域,我觉得这个共识是:在有限的资源条件下,将软件产品做好。一个广受好评的软件产品,离不开前期设计、中期开发、后期运营等角色及人员的共同参与。这里的参与不是说在软件产品的整个生命周期的每个阶段都把所有参与者都拉到一起开大会,个人觉得这样非常不好,毕竟术业有专攻,这也是为什么有这么多角色的原因不是,不然所有事一个做就好了对不对?

有句话叫有人的地方就有江湖, 软件行业同样如些,不过,在KPI和OKR横行的软件行业,是可以求同存异的。先说说我个人的经历,自己没有经历远古时期的开发模式,入行的时候,开发与部署(仅限测试环境)都得自己来:

  1. coding
  2. push到仓库
  3. ssh到服务器并pull代码
  4. 重启服务
  5. 测试介入 ……

可以看到,每多一步都是一个中断流程,通常1和2由开发人员完成,3和4由运维完成,5由测试介入,当然这还算是正常一点的流程,至少做到了专业的人做专业的事,我遇到比较奇怪的情况是3、4、5都是由测试人员来做,这个就比较尴尬了,结果可想而知,效率自然低下。比如需要找一台资源相对充足的机器来部署服务、服务发现、上下游服务依赖、查看日志……低效的结果就是需要加班来弥补。

既然低效,就有人想法子提高效率,于是乘着敏捷开发的东风,DevOps应运而生,而我个人正式拥抱”DevOps“,还是在2016年末,可以说是相当落伍了。那时并没有意识到这是DevOps,当时团队服务已经容器化,代码托管在公司自建的GitLab上,运维会给我们一套Dockerfile以及.gitlab-ci.yml模板(后期并入到开发框架中),所以整个流程就变为:

  1. coding
  2. push到仓库
  3. ssh到服务器并pull代码
  4. 重启服务
  5. 测试介入 ……

因为GitLab Runner帮我们完成了pull代码(服务镜像打包)及部署的过程,后期通过环境名称作为分支tag来部署到不同的环境,测试同学可以很快的介入,效率提高了很多,加班也变少了。之后参与k8s基础设施建设的过程后,我才明白,这其实是基础设施即代码的一种方式。

“基础设施即代码是一种使用新的技术来构建和管理动态基础设施的方式。它把基础设施、工具和服务以及对基础设施的管理本身作为一个软件系统,采纳软件工程实践以结构化的安全的方式来管理对系统的变更。”

不妨这样设想:我原本只是一个开发,写好代码就好,现在我可以自定义服务如何部署配置:可以使用多少内存、CPU,起多少个实例……想想都觉得很酷,而这一切,因为有了k8s这个IaaS的存在,不必关注物理机了,开发也可以轻松拥有参与”运维“的体验。当然看似简单的背后是因为有k8s在”负重前行“。

应该明白,DevOps远不只以上我所描述的这些,但是,当自己站在DevOps拓荒者的时候,发现这件事真挺困难的。因为它需要去协调开发人员、测试人员、运维人员……,需要加强基础设置的建设,需要让大家理解这一套的运行机制并作演示(确实也这样做了),但是回到开头说的文化,这点是由上层决定的,文化需要自上而下,所谓上行下效也是这个道理,当彻底明白这一点的时候,我选择了辞职。

DevOps看起来真的美好,k8s也很棒,云原生应用的趋势也已明朗,开源社区一片热闹,这是潮流,其中也暗藏汹涌,打好基础方能自由逐浪。

参考:

comments powered by Disqus