我国最大的IT项目管理门户网站,国内IT项目管理培训与咨询服务提供商

当前位置:首页 > 新闻资讯 > 正文

DevOps来临,ITIL是将覆灭,还是重生?

2018-12-18 来源:数字化观察
       近年来DevOps理念大行其道,由于DevOps切中了传统开发模式周期长、开发与运维团队难以协同、运维追求稳定并操控着“笨重的官僚流程”(通常就是ITIL流程)等全行业痛点,成为上到CIO,下到IT工程师追捧的潮流。不少布道者宣称:      DevOps+ 云,就是IT运作管理的未来;而相悖于DevOps宣言“重视个体与交互,重于过程和工具”的运维流程标准ITIL行将就木,必死无疑。这种论调,如同童话里最后一句:赶走了魔鬼的王子,和公主从此过上了幸福快乐的生活。
       然而现实呢?在经历过各种摸索、碰壁和爬坑之后,很多企业绝望的发现:DevOps对于IT运维来说,不仅不是银弹,而且根本就没有提供真正的系统化解决方案!如同王子和公主的婚后生活,远不会顺利的幸福快乐——日常生活的碰撞才刚刚开始。
       DevOps无法代替ITIL管理运维和服务
       (1)DevOps理论框架内没有提供运维和服务支持的方法论
       理论上,DevOps对于运维的重大建议就是将开发运维团队进行整合,消除组织壁垒,统一角色和职责。但是DevOps并没有就整合后的DevOps团队在运维方面应该如何运作和管理提供新的建议。显然对于任何一个关键业务应用运维来说,仅仅是人员角色的重新定义,或者是由开发者轮流值班运维,而缺乏相应的策略、规范和管理控制,运维管理又重新回到了ITIL称为“混乱Chaos”的状态,没有人为长期的服务质量负责;也没有管理框架有序组织团队内部协作、提升运行质量。DevOps来了,我们就招聘“DevOps工程师”、“全栈工程师”;但还是那些过去的软件开发工程师,技能没有变、学习能力没有变、对专业技术攻关的要求没有变,难道DevOps的称呼就是魔咒?人性没有变,分工协作的模式没有变,质量和稳定性要求没有变,难道DevOps就能消除操作规范、控制程序和管理过程这些基本管理方法?
       操作上,DevOps提倡实现CI(Continuous Integration持续集成,即持续代码提交编译)、CD(Continuous Delivery持续交付,即持续交付新的软件版本),即使很多人将CD解释为Continuous Deployment持续部署,也不过是新软件进入生产环境,启动运维的第一步。但是没有类似CO(Continuous Operation持续运营)的概念。
图:DevOps与传统开发运维模式的比较
        所以,DevOps在对于运维和服务支持方面,其实并没有涉及太多。
        (2)DevOps创始群体推荐ITIL作为运维的最佳实践
图:DevOps布道小说《凤凰项目》封面
       在广为流传的DevOps布道小说《The Phoenix Project》(中文版译名:《凤凰项目——一个运维的传奇故事》,人民邮电出版社出版)中,作者DevOps大师Gene Kim专门探讨了DevOps与ITIL的关系,他说:“ITIL和ITSM是支撑IT运维的最佳管理法典,实际上定义了很多IT运维需要的用来支持DevOps工作流方法的关键能力[1]”。
        (3)国际知名互联网公司仍然使用ITIL或者类似方法管理运维和服务
       在国际领先的知识分享网站Quroa(国内知乎就是参考它创办的),很多人提出了“Should ITIL Die”类似的问题,都是热帖。其中一个问题和高赞回答如下[2]:
       (4)国际标准认证机构将ITIL作为DevOps的核心模块
       国际标准培训认证机构EXIN近年推出了DevOps大师认证,其知识图谱中      ITIL/ISO20000是其中的核心模块之一[3]:
图: EXIN DevOps认证知识图谱
       传统ITIL正在面临5宗“罪”
       尽管包括DevOps在内的很多新兴理念和模式还很难替代ITIL,但是随着业务创新对IT的倚重、软件开发快速迭代部署的兴盛、新技术架构的应用、自动化替代人工的趋势、用户友好使用体验的要求等,ITIL正在面临越来越多的挑战:
       (1) 不敏捷,难以适应快节奏的版本发布和业务变化
       企业的ITIL总体上审批环节越来越多,要求提交的文档越来越复杂,难免给业务部门和开发部门“官僚作风”和“流程笨重”的印象。当然这不是ITIL的问题,而是过去长时间由于各种原因导致流程加强管控,但只有单向增强,没人敢反向简化的原因造成的。需要一个机缘,重新审视所有ITIL流程和相关程序,进行精简优化。对于变更,考虑更细致的分层分类,去除不必要的审批,简化文档要求。充分利用自动化技术,将更多低风险的变更流程自动化。
       (2)体验差,ITIL工具难以使用
       很多传统的ITIL平台:
       在架构和支撑技术老旧,界面过时,不能很好的支持移动化、基于位置和社交的UX体验和终端;
       流程需要手工填写大量的字段;
       搜索历史工单信息特别困难费时;
       系统制作报表,还不如手工计算数据Excel画图快……
       这些对于85后90后的运维工程师、服务用户都制造了ITIL恐惧症。
       (3)维护难,ITIL流程难以修改和定制
       很多传统的ITIL平台流程的任何改动,哪怕是颜色字体调整,都需要修改代码,更不用提当前需要根据业务需要和领导要求随时调整流程、字段和KPI计算方式,以及越来越多的ITIL标准之外的其他需要电子化管理的流程定制了。
       (4)配置管理依赖手工输入和稽核
       随着运维对象数量快速增长、复杂度级数增加,运维团队都希望使用CMDB记录和管理配置信息,来支持故障影响分析、故障根源定位和变更风险评估等运维场景。但传统依靠人工维护CMDB的信息精准已经被证明是不可能完成的任务!
       (5)难以适应动态管理需求
       云、容器等技术的应用使得运维流程需要面对瞬时变化的对象和情景,不能依赖人工开启工单、触发操作等,需要ITIL流程工具支持自身和第三方的动态代码调用和实时驱动。
       敏捷ITIL:让运维流程敏捷化、自动化、友好化
       如果说DevOps无法替代ITIL,而传统ITIL本身又不能满足DevOps的要求,那么为什么不把ITIL变得敏捷化呢?
       敏捷ITIL具备哪些特征?
       让我们用DevOps的核心理念来推演和改造ITIL:
图:从DevOps推演敏捷ITIL
       敏捷ITIL关键点:1. 变更管理流程自动化与集成
       如下图所示,实现以变更发布自动化为核心的流程集成:
图:ITIL流程集成与自动化
       变更发布流程是敏捷ITIL实现敏捷化的核心:
       流程精简:评估现有变更分类包含的细分类别和场景,去除不必要的审批
       分类降级:评估精简后的流程,执行是否可以自动化、风险是否可控,尽可能将类别下降
       细化标准变更:扩展和细化标准变更的二级、三级分类,最终颗粒度为可对接可执行的自动化脚本(复杂的对应到可实现的自动化编排任务流)
       多流程向变更发布流程集成:
       故障流程集成:对于低风险低影响的标准故障,自动启动标准变更流程,自动化执行修复脚本
       服务请求流程:对于梳理好的标准化服务请求,从服务目录,经变更流程留痕,对接到服务请求自动化实现
       软件发布流程:来自DevOps团队开发人员的待部署版本,根据事先设定的规则通过变更流程自动发布,或者审批后发布
       作业管理流程:批处理等作业在明确批处理脚本维护责任左移(left shift)到开发人员后,可以通过调用Job as codeAPI生成作业任务,通过变更流程进行资源分配和排程后自动化执行……
       敏捷ITIL关键点:2. 配置管理流程自动化与集成
图:配置管理自动化场景
       将传统上需要手工维护的CMDB变成自动化维护:
       o   CMDB初始化:通过对被管理环境的自动化扫描,完成所有配置项的信息采集、关联关系发现和应用系统建模。非环境信息仍然需要外部输入;业务逻辑关系仍然需要基于发现结果修正完善
       o   日常扫描比对:启动CI自动发现定时扫描比对,能够自动比对配置基线数据和当前实际运行态数据差异,发现CI变化。可经人工确认后更新到CMDB中
       o   与变更流程集成:在变更实施前定向扫描作为基线,在变更实施后,再次扫描,经人工确认或自动直接入库
       自动发现功能的核心在于:支持的设备与软件数量(是否能够对业界常见种类、型号和版本实现尽可能全的覆盖)、发现速度(防止由于速度效率问题导致的CMDB信息冲突和操作可行性)和多数据中心、多云服务商的支持能力等。
        敏捷ITIL关键点:3. 与用户实现敏捷服务支持
       使用支持移动、基于位置、社交化等流行用户使用习惯的技术,通过多种渠道(App、即时通信、Web、短信等)为IT服务用户提供服务支持,不断提升用户数字化体验和满意度。
图:敏捷客户沟通渠道与形式示意
        进一步的,可以利用智能客服为更多的用户提供更加人性化的服务支持。
图:智能IT客服原理
        敏捷ITIL关键点:4. 流程定制的图形化支持
       流程及其实现平台必须具备敏捷性,能够支持快速的优化和迭代,才能不断满足IT运维和服务支持的需求。提供图形化流程定制的流程平台将能够降低流程创建和修改的成本、时间和风险,更快的为生产运维服务。而必须通过修改代码的流程实现,已经成为历史遗产。
图:流程图形化创建示意
        敏捷ITIL关键点:5. Ops as code运维代码化
       Ops as code已经成为运维工具的发展趋势。考虑到运维对象的规模、架构复杂性、场景动态性和实时管理的要求,所有运维管理工具必须提供外部可调用的API,由第三方进行集成和管理逻辑编排,实现动态实时运维管理。
图:Ops as code架构示意
        敏捷ITIL的实现架构
       为了实现上述的敏捷ITIL,更好的实现DevOps风格的敏捷运维,一个可能的实现架构如下图所示:
图:敏捷ITIL的逻辑架构
       系统可分为4层,包括:
       o   用户层:敏捷服务与沟通渠道,支持移动、位置、社交等技术的多种服务支持方式,引入AI支持的智能客服,以更高效、更快速、更友好体验的方式支持服务
       o   展示层:敏捷运维仪表盘,制定敏捷运维的KPI,通过多种方式展示KPI实时和历史数据,为相关协作部门、领导层等展示敏捷运维的效率、价值和控制能力
       o   流程管理层:以变更发布管理流程为核心,以多流程向变更流程集成为主线,并与自动化层连接。CMDB配置管理基于CI信息自动发现实现自动化信息采集、建模和差异比对
       o   自动化层:自动化层将变更发布流程的发布过程进行自动化执行落地,包括:
企业级统一自动化编排与调度器:实现变更发布任务的逻辑编排、变更窗口指定或变更时间、资源分配、过程监督、结果向流程反馈等,能够全程实现图形化配置
       自动化部署工具:将自动化脚本动态的下发到目标对象中,为自动化脚本提供运行环境,作为自动化脚本和编排调度器的连通渠道
       自动化脚本库:提供低耦合的、细颗粒度的常用脚本库,便于复杂自动化任务的编排
       定制化脚本:用户为难以通过已有自动化脚本库实现的特殊需求定制开发
       代码化接口:其他第三方工具或脚本提供的REST API接口,通过脚本或者编排器调用
       敏捷ITIL总结
       为了适应数字化时代业务快速变化和DevOps开发模式的运维要求,可以将传统ITIL敏捷化改造,通过流程精简、集成和变更自动化等,实现敏捷ITIL落地。
图:敏捷ITIL的特点与预期收益
 
分享到:

免责声明:
  1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的,并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请浏览者仅作参考,并请自行核实相关内容。
  2、本站部分内容转载于其他网站和媒体,版权归原作者或原发布媒体所有。如文章涉及版权等问题,请联系本站,我们将在两个工作日内进行删除或修改处理。敬请谅解!

延伸阅读:

more

会议活动

more

公开课

more

PMO

Copyright © 2021 IT项目管理界 版权所有 京ICP备17062359号-4 如转载本站文章,请注明原作者和原发布媒体

本着互联网分享精神,本站部分内容转载于其他网站和媒体,如稿件涉及版权等问题,请联系本站进行删除或修改处理

客服电话:010-89506650 89504891 非工作时间可联系:18701278071(微信) QQ在线:511524637

新闻与原创文章投稿:tougao#cpmta.com 客服邮箱:info#cpmta.com(请将#换成@)

IT项目管理界——我国最大的IT项目管理门户网站,隶属卓橡公司

IT项目管理界官方微信

IT项目管理界官方微信

PMO大会官方微信

PMO大会官方微信