DO分离、ITIL和DevOps

通常软件产品开发团队至少有两个环境:开发环境和外网正式运营环境(简称:运营环境),而在通常情况下运营环境是复杂的,对于互联网产品来说当用户量达到一定规模以后,一般都会采用包含很多低价服务器的集群来提供在线服务。在开始的时候,开发人员会包揽了程序开发和发布部署的工作,慢慢就会发现发布部署的工作越来越繁重,由于不规范的操作会导致影响在线服务的运营故障,而日常的运维工作(硬盘损坏更换、服务器问题定位、配置修改和调整等)也会影响和占用开发人员的时间,于是DO分离的呼声高涨。

所谓的DO分离就是把业务的开发和运维工作分开由不同的人员(或团队)负责,通常会收回开发人员访问运营环境的权限,由运维人员统筹对运营环境的管理。DO分离让团队能够工作更专业和更专注,开发和运维是两种需要大量工作量和长期建设的工作,对于一个优秀的开发人员来说要具备优秀的系统管理能力需要花费大量的时间投入和实践,很难把两者都做好,所以DO分离后,开发和运维都可以更专心地做自己的事情,也才可把工作做得更专业。
当DO分离开始实施后,产品的运维能力在不断专业化和增强,对于系统的可用性以及在线故障的处理也需要从救火队员转向到专业化管理,于是ITIL的呼声高涨。

所谓的ITIL是用来管理信息技术 (IT) 的架构设计,研发和操作的一整套概念和思想。最初是借由一套书籍发布。这套书籍的每一本都涵盖一个信息技术的领域。于是事件管理、问题管理、配置管理、发布管理、可用性管理被逐步的建立起来,运维工作更加的集中,流程规范也逐渐的多起来,开发同学慢慢的习惯填写各种申请单,通过这样的梳理,整个运维工作建立了规范化和体系化,一切似乎很美好,只是开发和运营之间视乎有了一层隔阂(这个隔阂还在不断加厚),开发关注快速的实现特性并交付,运营关注的是系统稳定性、可维护性,而在一个事业部,运营团队通常只有一个,它面对和服务的是多个产品开发团队,当产品开发团队的发布速度加快时,冲突就变得愈发多起来了,这个时候延续已有的思路和方法通常是规范产品业务团队的发布周期,似乎木有更好的方法了。

DO分离和ITIL确实解决了很多过去的顽疾,并且建立了一个规范和有序的世界,看起来很完美,然而Flickr的做法让人大跌眼镜:10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
对于互联网产品来说,如果每天部署10次以上,那就真的做到随时可部署了。DevOps的呼声现在还没有高涨起来,但是这个新名词的横空出世,确实是对已有思维的一个大冲击。

所谓的DevOps是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。在我的个人理解中DevOps本身不会降低运维工作复杂性,但是通过打破开发和运维之间的隔阂,让开发团队和运营团队一起在设计软件的时候充分的考虑快速部署、保持简单运维性,并在实践中通过不断快速部署(这也有一个新名词:持续部署),不断改进不断打磨软件本身,把运维的专业性和复杂性封装起来到基础框架中,从而使得一天多次的发布部署成为可能。一键部署是很多开发人员的梦想,在Flickr、Facebook、Google这已经成为现实。DevOps目前来说是一个新名词,但是我们需要快速学习并把持续部署变为能力的一部分,让我们的团队不在为了部署皱眉头,让发布变成喝杯茶一样轻松。

发表评论

电子邮件地址不会被公开。 必填项已用*标注