DevOps与传统的融合落地实践及案例分析（上）

《DevOps与传统的融合落地实践及案例分析（上）》要点：
本文介绍了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工作变得越来越小,研发居多了,再往下看测试的工作量变得越来越少,变成自动化的工具.这是我们总结的数据,可以看到随着研发模式的变化,各个角色在里面承担了工作量的配比也在发生变化,研发越来越重要,很多工作也前置到研发阶段.

DevOps落地经验十四则(上)

第一则：理念与价值先行

第一、二点

这里面一定不是简单谈文化的,一定谈工程实践落地的因素.

第三点：端到端持续服务交付流程的改革

这里面不是讲的结果而是讲的过程,process不是过去讲的IT服务流程,把过程的变革,一旦工具进来简化我的流程或者是自动化的流程都带来变革.

第四点：对新的应用和服务,加快且缩短实现价值交付的时间.

这里面讲的怎么样有一个想法,快速实现这个想法,把这个想法反馈回来,让我持续的改进,不影响安全性和持续性,这一点我觉得蛮有意思的,比如说在国内讲双态运维的理念,双态运维根源上有双态IT形态的存在,

但是运维的本身没有所谓的双态的差别,你使用的方法论、工具自动化套路都是一致的,因为我管理的IT都是从本质上干几件事情,把命令传过去、文件传过去、数据采集回来,就干这三件事情,本质上这个流程该形成有效的设计,兼容安全和性能的要素.

第二则：顶层设计、全局规划.

这个是之前给一个物流行业做咨询的时候提出来一个模型,DevOps运维的体系分成6个维度＋一个文化,这里面包括组织、过程、架构、工具、基础设施、度量＋文化.

第一点：组织

DevOps首先必须打破组织之间的隔阂,其实DevOps团队建立面向产品而非项目的协作文化.

第二点：过程

过程不是流程,轻量级流程和自动化的工具完美结合,确保企业的高度敏捷性、自动化为先、而后再流程.

第三点：架构

架构是应用的架构、基础的架构和数据的架构,数据的架构谈起来虚一点,应用的架构和基础的架构是比较明确的,应用的架构更多讲微服务的架构,基础架构是标准化的基础设施,像Saas、paas平台.

第四点：工具

强调的平台层面上,怎么样把IT能力平台化,从DevOps整个过程构建持续交付的平台,到运营构建IT运营管理的平台,都是很重要的,只有它们能够把所有的质量成本和效率几者维度兼顾起来,具备可落地化.

回到顶层设计和平台层面来说,IT运营管理平台到底应该怎么样的设计?这里面讲到的云数据平台和iaas平台.在上面面向不同的IT管理过程,我做一些域设计的细分,比如说ITIL,分成基础、高级的、运维服务平台、研发的服务平台.

第五点：基础设施

对应的IaaS、PaaS部分,怎么样做持续反馈?监控,端到端的监控,从底层的基础设施,到上层的应用服务组建,从基础设施到接口、用户测量的监控这个端到端的能力怎么构建?这个构建成数据采集的基础.

第六点：度量

今天看监控是面向数据化的思维做监控,今天数据的特征发生了变化,不仅仅是结构化还有非结构化的数据.比如说日志,怎么样把日志当成流式数据的处理?

有了这样的数据采集基础,这里面有分析的平台,结合运维的场景,容量、可用性、业务连续性等等进行分析,结合IT的规模形态发生变化,所要看到的指标也会不一样,比如说基于云端要看成本和费用分析都不一样的,需求也不一样的.

IT服务中心是把整个IT服务能力怎么样的目录化,同时结合自动化的工具两者衔接起来.这个讲的变更中心,有一个梳理的方法,现在的传统企业,比如说国信证券,结合CMDB管理的对象,把这个管理的对象整理出来,通过IT服务中心给变更能力目录化,同时表达标准化,最后对接工具自动化.

再往上可以提供各种的服务编排的能力,这种服务编排是跨越了各种工具的,再往上是构建运维的统一模库.这是顶层设计和全局规划.

第三则：Start Small,从小做起.

DevOps这么大的体系,大平台上又有这么多,是不是全都要落地?一定要Start Small,这个准则很好梳理,基于每个角色＋某个场景从小做起,一定要把IT部门的角色梳理出来,比如说到运维这边,有业务运维、系统管理员,网络运营.

第二可以基于每个系统和每个功能实施导入,比如说今天就做监控库,我看传统的企业很多做CMDB导入,切忌贪大求全,给你画的图景是很美好的,很多人说DevOps很好,怎么样落地呢?一定要Start Small.

第四则：构建元数据基础平台CMDB

下一个阶段要把它名字改为IT资源管理平台,因为我觉得现在需要把CMDB的管理资源和职责范围缩小,其实在不同的阶段,我们管理也不能贪大求全,把所有的配置全部管理起来,最后发现自己转不动了.上面的场景又起不来,现在很难把场景构建起来,场景起不来的时候,结果把CMDB做死了,我们一直讲这个数据的鲜活性,结果做不起来.

今天我把范围缩小了,只管基础设施的资源和应用的资源,基础设施是属于目前应用的,这个资产状况管理起来我从应用的角度看,到底用了哪些资源?

把这两层的维度强关联起来,然后在应用上层构建应用的各种的管理场景,比如说应用的发布、应用的部署、应用的监控等等.应用的数据分析,由它来进行进一步的驱动CMDB的流转,因为在应用的维度上,才符合以前讲的高频的特征.

今天到任何一个组织,其变更的场景来说,应用是最频繁的,比顶层基础设施更频繁.如果符合高频的特征可以理解场景化的能力最强的,场景化的能力强那驱动力就是最强的,今天把CMDB转化成IT资源管理,以应用的视角看资源.这个平台里它的核心作用是毋庸置疑的,应用是CMDB平台的元数据.

这里面怎么样的上层联动?CMDB这么多的数据,其实就是一类的实例的数据.比如说这里面到底有多少服务器、服务器有多少的虚拟机?这是实例的数据,然后就是拓扑的数据.我的服务摆在机柜上,介入的上面数据是什么.同样是根据顶层的资源拆出来的,一个基础资源一个是应用的资源,分成实例管理和拓扑管理.

今天很多人讲自动化,其实资源有生命周期的状态,一定不能通过自动化来替代的.比如说这个IP地址从资源池里面分配出来给业务池使用,一定要通过一个流程申请出来,无论是自动化的还是以前离线流程的,这是一个生命周期的状态,IT地址退还不能保留业务使用,这个一定要有流程控制的,这里面自动化不能代替人工的流程,流程是聚焦在事前的管理.

再往上是场景应用,要找各种的场景应用,构建出来这一层做的形象的比喻就相当于今天的地图一样的,比如说百度地图,这个地图可以在不同的场景用,大众点评可以用,滴滴也可以用,今天的CMDB也起到这样的作用.这么多场景建设的时候,事件平台是一个很好的入口.

因为今天看到传统的行业太多的监控系统,这个监控系统都要进行收敛,怎么收敛?把所有的监控实践发到统一事件系统,由统一事件系统根据底层的IT对象关系自己来进行收敛,现在老的监控系统基于CMDB收敛是很难的,基本上找不到监控厂商来修改,提一个需求要带来大量的成本.

为什么一直在讲CMDB核心的管理模型是应用的管理模型,IT形态发生变化了,这个模型不用改变的,不用调整的,比如说是公有云.CMDB模型的扩展力是把所有的资源管理起来,这个资源分成本地资源和第三方的资源,本地资源是应用部署在同一主机上的资源,比如说程序包、操作系统的版本,使用的内存,或者是这里面的配置的版本等等,甚至在本机占用了端口甚至是接口服务都是我们的资源.第三方资源如阿里云,这些资源都可以通过应用管理维度集中起来.

第五则：痛苦的事情优先解决

基于角色和产品如何梳理管理能力?运维的复杂度为什么复杂?在这儿,因为运维角色太多了,管理的对象太多了,产品太多了,最终出来的能力管理流程也可以太多.开发测试没有如此复杂,开发就开发,测试就测试.这里面一定要通过角色＋场景,最后导出我应该构建什么样的能力管理的平台出来,一定要有这样的思路.

今天讲的运维自动化,最后我变成配置管理或者是工具的自动化或者是调度的自动化,这个远远不够,其实运维自动化弥漫在每一个角色、每一个场景里,今天说的基于容量的自动扩容不算自动化吗?CMDB的自动发现不算自动化?基于监控事件故障自愈不算自动化吗?都算.基于这个图把自动化的场景收敛一样,作业和调度的能力是底层平台化的能力,在各个子系统使用.

第六则：工具也是一种文化

这里面讲的作业管理和调度的管理应该是平台级的能力,不需要进行场景化的理解.在自动化的构成要素里有一个原子化的事务,同时有调度编排原子化的事务,有两个要素有够了.再往上是面向角色的场景化收敛和归类,工具可以把我们的能力拼装起来,在各个场景下使用.工具是真正推动变革的有效手段,好的经验一定是通过自动化的手段沉淀管理过程.

文章来自微信公众号：优维科技EasyOps

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4124.html