欢迎您光临本站,如有问题请及时联系我们。

运维体系:从ITIL走向DevOps

  1、ITIL

  企业的技术架构的不断革新,推动着IT运维管理模式运维体系从稳态向敏态转变。

  随着企业信息化的深入,IT系统越来越多,企业IT运维人员也随之增加,不少企业信息部门专门成立运维团队进行IT系统运维工作。IT团队内部自然不可避免地需要对运维人员的各种活动进行管理。ITIL正是为企业的IT服务管理提供了一个客观、严谨、可量化的最佳实践的标准和规范。我认为正是ITIL提出的这些标准和规范在一段很长的时间为我国许多企业的运维体系建设起来指明了方向。

  ITIL强调流程:以ITIL理念为核心的各种ITSM系统无不将运维操作流程化。事件管理、问题管理、变更管理、配置管理,大家都按流程办事,杜绝一切拍脑袋决策和盲目操作。

  ITIL强调规范:运维人员按组织依据流程进行各种规范的运维操作,约束本身是为了确保大家的行为不要偏离方向,少犯错误。

  ITIL强调分工:运维人员按技能进行有效的分工,有人负责服务台的一线响应,有人负责二线的事件和问题处理,有人负责配置管理,有人负责变更审批等等。运维团队内部实现各司其职,分工协作。

  这种管理机制在IOE技术架构的年代是非常适合的。这种集中式的技术架构结构相对简单,显然需要更加稳妥运维操作,毕竟所有鸡蛋都放在这几个篮子里面;另外,在这种集中式的架构下面,业务变更也没有如此的频繁,需要动不动就走一个流程是有点麻烦,但是由于频率低,倒也可以接受。

  2、DevOps

  然而,在企业IT技术架构逐步进入互联网架构下,业务的迅速发展,强调IT更好地按需而变,强调更敏捷地响应业务的需求时,ITIL这个体系多少就有些与现实格格不入的感觉。这时,DevOps这个词汇走进人们的视野(见图1-2)。

IT运维发展趋势及运维人的转型升级

IT运维发展趋势及运维人的转型升级

IT运维发展趋势及运维人的转型升级

  图1-2 运维体系从ITIL走向DevOps

  DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。

  DevOps的思想跟ITIL有着天然的区别

  流程压缩,反应敏捷,效率大幅提升:

  ITIL强调流程,但是也带来了效率的下降。在IOE时代,企业业务的变更还并不是那么的频繁,这种效率的下降还并不明显。但到了互联网架构下,这种负面效应就会被无限放大。

  举个例子,某运营商发布新的系统版本,往往会经历源代码提交、编译、打包、发布到测试环境、UAT测试、修改bug、再测试、最后上线发布的流程,这个流程往往会经历3-4天。因此,该运营商的版本发布一般只能以月为单位,最快也只能以周为单位。相对于业务周期以天来计算的互联网行业,这套体系对业务变更的反应也就太迟钝了。

  所以,DevOps体系则更为强调效率,在持续集成、持续的自动化测试、持续部署平台、立体化监控、技术架构优化等多种自动化工具的加持下版本发布和运维的过程被大大压缩,效率被大幅提升。应用版本发布频率可以以天,甚至以小时为单位。这种为了效率有选择性地放弃一些有点拖沓的流程管理,是IT运维管理为适应IT更好地按需而变,强调更敏捷地响应业务需求的一种更好选择。

  自动化操作代替冗长流程控制下的规范性:

  从另一个方面来说,ITIL强调了规范性,但是这种以建筑于流程之上的规范性仍然有很多缺陷。

  再接着上面运营商的例子来说,即使是有再完善的流程加以控制和规范,仍然没有人能打包票说版本上线一定没有问题。在每次版本上线前后,运维团队成员仍然如临大敌,战战兢兢。

  原因在于,技术架构复杂程度发展到一定阶段,流程往往无济于事甚至流于形式。在大规模、多类型软硬件设施运维情况下,单纯依赖人的运维体系终将成为整个IT运维的瓶颈。在这种情况下,许多企业尝试将规范性操作细化为各种自动化操作场景,例如,上文就提及过的持续集成、持续自动化测试、持续部署、自动化监控和运维等等的工具和平台。这些高效率、规范化的自动化彻底解放了运维人员的压力,让运维人员的精力可以投入到真正有意义的工作中,而非总是在重复一些机械和重复的常规性事务当中。

  以谷歌为例,他们的SRE工程师强制规定他们只有30%的时间会花在on call这种事务型的工作当中,而70%的时间则花在各种自动化工具的开发之中,比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等,这些工具需要他们自己完成开发和维护。这种以自动化工具下高效率的自动化操作代替冗长流程控制下的规范性,也是DevOps体系的一个比较明显的特征。

  开发与运维的融合:

  同时,ITIL背景下的分工也带来许多负面问题。例如,运维团队感知和认同感很差。企业高层领导认为运维工作没有亮点和价值,是一个成本部门;运维团队也多半认为自己是“背锅侠”。以至于多年前做项目时曾听到合作某甲方运维团队核心成员的一句抱怨:“少壮不努力,老大干运维”。

  这可能也是大多数运维者的心声吧。诚然,这里面有运维工作成果难以量化,企业高层不够重视等因素,但是这种过于壁垒分明的开发与运维的分工也是重要原因之一。

  企业开发团队与运维团队形成的鸿沟,使开发团队在规划、设计和研发的过程中过于着重功能的实现,在一定程度上忽视了运维团队所关心的稳定性、性能、可用性等因素。

  同时,运维团队又无渠道将这些问题在开发前期予以反馈和修复。于是乎,运维团队不断沦为“救火队员”和“背锅侠”,团队士气下降人才流失,运维质量下降形成了恶性循环。

  所以,DevOps体系中强调的是开发与运维的融合。

  开发运维一体化使开发和运维的信息透明性,运维过程中遇到的问题更有效地反馈到开发团队中。同时,运维的责任主体从单一运维团队变化开发、运维团队共同承担。这使得开发团队也需要为运维中遇到的故障负责,让开发团队也需要将部分的精力和资源投放到与稳定性、性能和可用性等运维相关的研发中去。

  当然,并非说ITIL这套体系就已经完全过时,而是我们需要将两者与企业中的开发运维特点相结合,形成更有效的适合企业自身的开发运维体系。只有适合自己的才是最好的。

  E8运维是国内最早成立的IT运维技术社区,致力于为运维相关领域的工程师打造一个良好的学习交流平台。深度剖析国内运维业内动态,分享DevOps、自动化运维、智能运维等优秀实践,帮助运维人员提升技能和规划职业发展路线。


来源:本文由E8运维原创撰写,欢迎分享本文,转载请保留出处和链接!