导读：5 月 6 日，优维科技与数人云主办了 [ DevOps&SRE 超越传统运维之道 · 深圳站] ，6 月北京站敬请关注~本文是优维科技 CEO 王津银关于 DevOps 与传统的融合落地实践的精彩分享
中国开放运维联盟发起人，精益运维”理论提出者，中国第一批 DevOps Master 授权讲师，持续交付专家，业内人称“老王”。“互联网运维杂谈”公众号创办者。致力于互联网运维整体解决方案的产品化能力提升，缩短企业到达互联网运维的路径。
一直觉得华南这一片技术沙龙太少了，在 DevOps、SRE 理念大热的今天，我们希望能把一些先进的经验分享出来，让更多的企业能够受益。华南有很多优秀的业界从业者，比如说今天邀请到的大梁，腾讯内部关于 DevOps 还是有很多的经验值得分享的。
今天活动主题是 DevOps&SRE，我来讲 DevOps，王璞分享 SRE，SRE 是谷歌的 DevOps 实践，大梁把 DevOps 最后一棒——持续反馈跟大家分享，希望把这些链条全部的打通。
今天的演讲主要分为以下三个部分：第一个是 DevOps 全局的理解以及 DevOps 与 ITIL 的对比融合，第二个是 DevOps 落地经验 14 则，第三个是案例的分析。
其实讲 DevOps 特别的多，官方里面给了一个框架图，从计划需求、设计、开发、部署、运营、宗旨，持续交付到 IT 运营管理、经营管理，后来扩展了一下，大家看到这个全景图的时候的确有概念的认知，我觉得不够。做了以下几点改动：
以前叫 IT 服务管理，因为 IT 服务管理带来很多 ITIL 的认知，今天看 IT 运营范畴变得很多了。面向 IT 运营管理的实践，ITIL 延伸出来的 IT 服务管理只是其中一部分，还有运营管理、性能管理、监控管理、分析管理等等。
同时给出一个从理念—工程与方法—过程—实践—工具的转换路径图。这样让我们更能清晰的看到 DevOps 的整体框架和落地实践及工具的关系。
今天看 DevOps 整体框架，其实也是一连串工程实践组合，包括敏捷工程、持续交付和 IT 运营管理及其精益实践等等。在过去 IT 组织中，或多或少都有敏捷管理和 IT 运营管理的实践，但 IT 的效率依然不高，为什么？今天似乎在持续交付中可以找到答案—— IT 如何成为业务的核心竞争力。
DevOps 跟 ITIL 对比，其实两个不属于同一个范畴，DevOps 是属于 IT 全局的，ITIL 是属于运维这块的，IT 服务管理的，其实聚焦的领域不一样，但是还是有必要做一个对比。
因为我觉得在运维的行业，我觉得还是要把这两个理念做一个清晰的划分，比如说今天讲的以 DevOps 整个理念做平台，到底以 ITIL 做这个平台有什么样的不同。这里面是做一个对比。
首先 ITIL 是面向管理的过程，以这个目标规范优先，DevOps 是面向 IT 运营过程，是执行的能力跟自动化，ITIL 是离线任务管理为主要特征，而 DevOps 是以在线服务的。
可以看这里面有关键的作用力，我自己的理解把云计算、上层的框架模式拆分出来之后你会发现越接近上层应用，其实 ITIL 对它的作用力越来越小。
比如说之前大梁给我的数据，他的部门两个星期发布 9000 次，这个不可能针对每一次的发布建立强流程，这样流程太多带来成本非常高，达不到那种的效率。
我们在底下可以看到，在底层基础设施这块的，硬件基础能力还没有达到软件定义这种 SDX 化，它的作用力依然存在的，但是未来随着软件定义化的能力越来越强，这波浪潮也会改变。NetDevOps 的兴起就是一个极好的例子。
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 工作变得越来越小，研发居多了，再往下看测试的工作量变得越来越少，变成自动化的工具。这是我们总结的数据，可以看到随着研发模式的变化，各个角色在里面承担了工作量的配比也在发生变化，研发越来越重要，很多工作也前置到研发阶段。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.