DevOps来临，ITIL是将覆灭，还是重生？（全文）
Posted 数字化观察
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了DevOps来临，ITIL是将覆灭，还是重生？（全文）相关的知识，希望对你有一定的参考价值。
写在前面：
据报道，ITIL 4即将在2018年底或2019年初发布，老z邀请大家猜猜ITIL 4新理念有哪些和本文重合，或者相似！私信我，如果正确，老z给你发红包哈
近年来DevOps理念大行其道，由于DevOps切中了传统开发模式周期长、开发与运维团队难以协同、运维追求稳定并操控着“笨重的官僚流程”（通常就是ITIL流程）等全行业痛点，成为上到CIO，下到IT工程师追捧的潮流。不少布道者宣称：DevOps+ 云，就是IT运作管理的未来；而相悖于DevOps宣言“重视个体与交互，重于过程和工具”的运维流程标准ITIL行将就木，必死无疑。这种论调，如同童话里最后一句：赶走了魔鬼的王子，和公主从此过上了幸福快乐的生活。
然而现实呢？在经历过各种摸索、碰壁和爬坑之后，很多企业绝望的发现：DevOps对于IT运维来说，不仅不是银弹，而且根本就没有提供真正的系统化解决方案！如同王子和公主的婚后生活，远不会顺利的幸福快乐——日常生活的碰撞才刚刚开始。
（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认证知识图谱
尽管包括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流程工具支持自身和第三方的动态代码调用和实时驱动。
如果说DevOps无法替代ITIL，而传统ITIL本身又不能满足DevOps的要求，那么为什么不把ITIL变得敏捷化呢？
敏捷ITIL具备哪些特征？
让我们用DevOps的核心理念来推演和改造ITIL：
图：从DevOps推演敏捷ITIL
如下图所示，实现以变更发布自动化为核心的流程集成：
图：ITIL流程集成与自动化
变更发布流程是敏捷ITIL实现敏捷化的核心：
流程精简：评估现有变更分类包含的细分类别和场景，去除不必要的审批
分类降级：评估精简后的流程，执行是否可以自动化、风险是否可控，尽可能将类别下降
细化标准变更：扩展和细化标准变更的二级、三级分类，最终颗粒度为可对接可执行的自动化脚本（复杂的对应到可实现的自动化编排任务流）
多流程向变更发布流程集成：
故障流程集成：对于低风险低影响的标准故障，自动启动标准变更流程，自动化执行修复脚本
服务请求流程：对于梳理好的标准化服务请求，从服务目录，经变更流程留痕，对接到服务请求自动化实现
软件发布流程：来自DevOps团队开发人员的待部署版本，根据事先设定的规则通过变更流程自动发布，或者审批后发布
作业管理流程：批处理等作业在明确批处理脚本维护责任左移（left shift）到开发人员后，可以通过调用Job as codeAPI生成作业任务，通过变更流程进行资源分配和排程后自动化执行……
图：配置管理自动化场景
将传统上需要手工维护的CMDB变成自动化维护：
o CMDB初始化：通过对被管理环境的自动化扫描，完成所有配置项的信息采集、关联关系发现和应用系统建模。非环境信息仍然需要外部输入；业务逻辑关系仍然需要基于发现结果修正完善
o 日常扫描比对：启动CI自动发现定时扫描比对，能够自动比对配置基线数据和当前实际运行态数据差异，发现CI变化。可经人工确认后更新到CMDB中
o 与变更流程集成：在变更实施前定向扫描作为基线，在变更实施后，再次扫描，经人工确认或自动直接入库
自动发现功能的核心在于：支持的设备与软件数量（是否能够对业界常见种类、型号和版本实现尽可能全的覆盖）、发现速度（防止由于速度效率问题导致的CMDB信息冲突和操作可行性）和多数据中心、多云服务商的支持能力等。
使用支持移动、基于位置、社交化等流行用户使用习惯的技术，通过多种渠道（App、即时通信、Web、短信等）为IT服务用户提供服务支持，不断提升用户数字化体验和满意度。
图：敏捷客户沟通渠道与形式示意
进一步的，可以利用智能客服为更多的用户提供更加人性化的服务支持。
图：智能IT客服原理
流程及其实现平台必须具备敏捷性，能够支持快速的优化和迭代，才能不断满足IT运维和服务支持的需求。提供图形化流程定制的流程平台将能够降低流程创建和修改的成本、时间和风险，更快的为生产运维服务。而必须通过修改代码的流程实现，已经成为历史遗产。
图：流程图形化创建示意
Ops as code已经成为运维工具的发展趋势。考虑到运维对象的规模、架构复杂性、场景动态性和实时管理的要求，所有运维管理工具必须提供外部可调用的API，由第三方进行集成和管理逻辑编排，实现动态实时运维管理。
图：Ops as code架构示意
为了实现上述的敏捷ITIL，更好的实现DevOps风格的敏捷运维，一个可能的实现架构如下图所示：
图：敏捷ITIL的逻辑架构
系统可分为4层，包括：
o 用户层：敏捷服务与沟通渠道，支持移动、位置、社交等技术的多种服务支持方式，引入AI支持的智能客服，以更高效、更快速、更友好体验的方式支持服务
o 展示层：敏捷运维仪表盘，制定敏捷运维的KPI，通过多种方式展示KPI实时和历史数据，为相关协作部门、领导层等展示敏捷运维的效率、价值和控制能力
o 流程管理层：以变更发布管理流程为核心，以多流程向变更流程集成为主线，并与自动化层连接。CMDB配置管理基于CI信息自动发现实现自动化信息采集、建模和差异比对
o 自动化层：自动化层将变更发布流程的发布过程进行自动化执行落地，包括：
企业级统一自动化编排与调度器：实现变更发布任务的逻辑编排、变更窗口指定或变更时间、资源分配、过程监督、结果向流程反馈等，能够全程实现图形化配置
自动化部署工具：将自动化脚本动态的下发到目标对象中，为自动化脚本提供运行环境，作为自动化脚本和编排调度器的连通渠道
自动化脚本库：提供低耦合的、细颗粒度的常用脚本库，便于复杂自动化任务的编排
定制化脚本：用户为难以通过已有自动化脚本库实现的特殊需求定制开发
代码化接口：其他第三方工具或脚本提供的REST API接口，通过脚本或者编排器调用
为了适应数字化时代业务快速变化和DevOps开发模式的运维要求，可以将传统ITIL敏捷化改造，通过流程精简、集成和变更自动化等，实现敏捷ITIL落地。
图：敏捷ITIL的特点与预期收益
—END—
尾注：
[1] 《凤凰项目——一个运维的传奇故事》，人民邮电出版社出版，373页
[2] https://www.quora.com/Is-ITIL-used-at-companies-such-as-Amazon-Google-Facebook-Why
[3] https://www.exin.com/en/certifications/exin-devops-master-exam
以上是关于DevOps来临，ITIL是将覆灭，还是重生？（全文）的主要内容，如果未能解决你的问题，请参考以下文章