演讲实录 | DevOps 与传统的融合落地实践

导读：5 月 6 日，优维科技与数人云主办了 [ DevOps&SRE 超越传统运维之道 · 深圳站] ，6 月北京站敬请关注~本文是优维科技 CEO 王津银关于 DevOps 与传统的融合落地实践的精彩分享

• ##王津银／优维科技创始人&CEO##

中国开放运维联盟发起人，精益运维”理论提出者，中国第一批 DevOps Master 授权讲师，持续交付专家，业内人称“老王”。“互联网运维杂谈”公众号创办者。致力于互联网运维整体解决方案的产品化能力提升，缩短企业到达互联网运维的路径。

一直觉得华南这一片技术沙龙太少了，在 DevOps、SRE 理念大热的今天，我们希望能把一些先进的经验分享出来，让更多的企业能够受益。华南有很多优秀的业界从业者，比如说今天邀请到的大梁，腾讯内部关于 DevOps 还是有很多的经验值得分享的。

今天活动主题是 DevOps&SRE，我来讲 DevOps，王璞分享 SRE，SRE 是谷歌的 DevOps 实践，大梁把 DevOps 最后一棒——持续反馈跟大家分享，希望把这些链条全部的打通。

今天的演讲主要分为以下三个部分：第一个是 DevOps 全局的理解以及 DevOps 与 ITIL 的对比融合，第二个是 DevOps 落地经验 14 则，第三个是案例的分析。

• ##DevOps 全局的理解##

其实讲 DevOps 特别的多，官方里面给了一个框架图，从计划需求、设计、开发、部署、运营、宗旨，持续交付到 IT 运营管理、经营管理，后来扩展了一下，大家看到这个全景图的时候的确有概念的认知，我觉得不够。做了以下几点改动：

• ###☆ 第一：IT 运营管理###

以前叫 IT 服务管理，因为 IT 服务管理带来很多 ITIL 的认知，今天看 IT 运营范畴变得很多了。面向 IT 运营管理的实践，ITIL 延伸出来的 IT 服务管理只是其中一部分，还有运营管理、性能管理、监控管理、分析管理等等。

• ###☆ 第二： 扩展上层的实践和工具部分###

同时给出一个从理念—工程与方法—过程—实践—工具的转换路径图。这样让我们更能清晰的看到 DevOps 的整体框架和落地实践及工具的关系。

今天看 DevOps 整体框架，其实也是一连串工程实践组合，包括敏捷工程、持续交付和 IT 运营管理及其精益实践等等。在过去 IT 组织中，或多或少都有敏捷管理和 IT 运营管理的实践，但 IT 的效率依然不高，为什么？今天似乎在持续交付中可以找到答案—— IT 如何成为业务的核心竞争力。

• ##DevOps 与 ITIL 的对比融合##

DevOps 跟 ITIL 对比，其实两个不属于同一个范畴，DevOps 是属于 IT 全局的，ITIL 是属于运维这块的，IT 服务管理的，其实聚焦的领域不一样，但是还是有必要做一个对比。

因为我觉得在运维的行业，我觉得还是要把这两个理念做一个清晰的划分，比如说今天讲的以 DevOps 整个理念做平台，到底以 ITIL 做这个平台有什么样的不同。这里面是做一个对比。

首先 ITIL 是面向管理的过程，以这个目标规范优先，DevOps 是面向 IT 运营过程，是执行的能力跟自动化，ITIL 是离线任务管理为主要特征，而 DevOps 是以在线服务的。

可以看这里面有关键的作用力，我自己的理解把云计算、上层的框架模式拆分出来之后你会发现越接近上层应用，其实 ITIL 对它的作用力越来越小。

比如说之前大梁给我的数据，他的部门两个星期发布 9000 次，这个不可能针对每一次的发布建立强流程，这样流程太多带来成本非常高，达不到那种的效率。

我们在底下可以看到，在底层基础设施这块的，硬件基础能力还没有达到软件定义这种 SDX 化，它的作用力依然存在的，但是未来随着软件定义化的能力越来越强，这波浪潮也会改变。NetDevOps 的兴起就是一个极好的例子。

• ##DevOps 自动化与 ITIL 规范之间的融合##

DevOps 可以看到在线服务管理里面，可以兼顾质量效率和成本规划，上图就是 DevOps 自动化与 ITIL 怎么融合，极力避免形成 OA 流程在 IT 部门的应用。这是按照优维的实践，在传统的行业做交付的过程中我们的产品怎么跟 ITIL 流程思想对接得出来的模式：

###☆ 第一种模式：申请 ITIL 流程的时候可以直接调动 DevOps 的工具###

典型的特征，比如说第一种在线服务开通流程，我要把我的防火墙开通了，这时候申请一个表单，审核通过了立马调用 DevOps 的工具执行。

但以前是离线的 IT 服务目录，我提一个表单、需求单，这个需求单审核通过同意之后，方案管理人员再跑去设备去开通，今天不一样，让流程变成立即可以执行的模式。

今天举例：资源申请流程，在 CMDB 整个资源申请里，这是国信证券的典型案例，比如说以前资源申请，我从库房拿一个设备，这个设备拿出来我要分配网络重组，以前是各个角色分配完了填写回复，今天不是这样的，把这个流程在线化，所有的资源通过 CMDB 资源层拿出来直接在表单里执行。

###☆ 第二种模式：重大变更的流程###

这个流程在华南很大的银行总结出来的案例，我们把所有的变更流程、审批流程做完之后，立马启动执行流，对于高稳定性服务保障流程非常的重要。

比如说对于银行基础设施的网络等等非常重要的，这里有一个问题，这个流程我在审批的时候是 A 方案，到审核之后方案有可能会被人为改变，怎么办？这种情形有改进的措施，我们把 DevOps 调度流作为审批流方案一部分，审批通过了这个流程可以去进行执行，这个保证了流程审批完了以后和在线的流程是一致的。

###☆ 第三种模式：敏捷发布的流程，或者是 DevOps 变更的流程###

因为今天很多的流程不再依赖 ITIL 完成的，比如说敏捷的发布流程 JIRA 管理，这是一个新的研发管理工具，不可能再回到 ITIL 提一个发布单，这里面我总结的是红绿灯机制。当我进入到某一个环节，比如说测试环节不符合的时候，我看到基于什么样的状态？如果通过了就开始的执行。

今天讲的 DevOps，还可以从另一个维度看，叫软件研发的模式去看。我们经历了几种模式的变化，第一种是 waterfall 的模式，比如说研发、测试、运维间彼此是割裂的，独立的，中间有一个墙存在的，这里面有严格的输入输出在进行传递。

往下面走就是敏捷研发的模式，这里面讲的 TDD 的测试研发，在每一次的版本可以做很多的小迭代，比如说今天我们做 easyops 平台，我们规定两个星期出一个小版本，这两个星期出一个小版本的时候，内部还经历一个小迭代，内部很多的小迭代做这个事情。

但是这里面依然有问题，研发跟测试是一体化的，测试驱动研发，这块运维、operation 还是被隔离在外了，但是随着新的业务形态出现后，比如说互联网的模式出现了之后，要强调端到端能力的整合。

DevOps 软件研发模式就出现了，在和客户交流的时候，不断的触发思考一个点，实施了敏捷和 IT 服务管理，为什么 IT 依然看成成本中心而不是业务的核心竞争力，为什么还是对业务需求响应很慢？在前面讲的持续交付就是来解决这个问题的。

可以看在几种研发模式中，比如说这个 Develop 以前测试的时候占的 70%，详细的设计占比重越来越大，但是到小迭代、小设计的时候 Design 工作变得越来越小，研发居多了，再往下看测试的工作量变得越来越少，变成自动化的工具。这是我们总结的数据，可以看到随着研发模式的变化，各个角色在里面承担了工作量的配比也在发生变化，研发越来越重要，很多工作也前置到研发阶段。