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

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做死了,我们一直讲这个数据的鲜活性,结果做不起来.

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

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!