回到主页

干货 | 以CMDB为基础打造的DevOps平台

Jerry Huang

· 操作指南

背景

6月29日,DevOps国际峰会暨DevOps金融峰会(DOIS)在北京终于开幕。作为国内首个国内唯一的国际性 DevOps 技术峰会,DOIS (DevOps 国际峰会)由 OSCAR 联盟指导、DevOps 时代社区与高效运维社区联合主办,共邀全球80余名顶级专家畅谈 DevOps 体系与方法、过程与实践、工具与技术。

在会上,优维科技资深解决方案架构师Jerry Huang对传统行业DevOps落地方案中的《以CMDB为基础打造的DevOps平台》做了分享。

*Jerry是国内较早的EXIN DevOps Master之一,现任优维科技高级解决方案架构师。有丰富运维研发经验,负责多年中国移动运维架构以及敏捷转型工作,曾在电力、通信、金融行业Devops项目建设实践方面有丰富经验。

broken image

以下是Jerry Huang的演讲内容,经编辑整理删改:

今天主要的主题是我们要打造现在的DevOps平台为什么以CMDB基础来打造。在这个过程中主要分四各环节:(1)DEVOPS平台需要强CMDB(2)CMDB模型如何构建(3)CMDB平台如何建设(4)招商银行CMDB落地经验分享,前面主要讲DevOps平台,最后的环节是讲招商银行总部的CMDB分享,互相借鉴参考一些经验,希望可以跟大家讨论一下。

broken image

上面的四大块是我们平常工作中就涉及相关的比较多的,比如说我们前端的服务构建平台,服务构建平台包括我们的一些研发、研发过程、需求管理的过程,以及我们代码库,服务交互过程可能是我们持续交互的平台建设。后面是我们的服务运行平台,我们运维部门涉及更多的比如我们的一些监控或者巡检、维护还有告警事件。服务运营平台,就是所谓的一些运营分析,比如我们的APM,比如我们的一些分布式链路监控,比如我们的一些统计分析平台。

 

这个CMDB它不再像以前我们的所谓的ITIL提出来的资产管理的概念,我们现在互联网转型的过程,我们的CMDB建设的核心是围绕着一个应用的CMDB交付的过程,围绕着应用CMDB交付的过程围绕两层部分,第一是基层平台,第二是下面的黄色这一块,就是我们的IAAS的资源池,有计算、存储、网络、公有云的服务。上面这一块,这是我们基于下面的服务来建立一些类似CMP资源池管理。我们叫服务支撑平台,围绕着这所有的服务支撑平台,是为了上层四大块来提供一些实质性的、有效性的数据,做整个自动化的过程。

broken image

持续交付平台我把它划为三块,一块以应用可视化自动化部署为核心,所谓的CD,就是我们所谓的自动化部署。自动化部署包括一些容器等等。第二以应用场景化变更管理为核心的,比如一些日志分析、日志监控还有页面分析。第三是以应用流水线能力和持续改进为核心,这就是我们先做CD,我们再往上做一些OPS的持续反馈。再往前申到研发那一端,很多传统企业大部分是外包厂商,很难控制到我们的研发那一端。所以我为什么把CI放在最后面,这也是传统企业里面的很难的一步。

broken image

DevOps里面,我们CMDB它起到一个承上启下的过程,它往下就是我们的基础资源、基础设备层自动创建的能力,往上走就是我们运维平台的所谓的PaaS服务。运维的价值在于交付能力。要把自动化的能力最终可以形成按钮、平台直接可以交付给研发端的东西。

CMDB的释义是IT资源管理,我们是围绕着以应用为中心的价值交付,为什么以应用为中心?它有些什么样的能力?比如我这个应用它布在OS上面,操作系统是什么,还有系统配置是什么,它属于哪个业务,这一层互联网可能叫做服务树。服务树上面比如说这个应用属于哪个系统,这个系统属于哪个大业务架构。再往下拓,这个集群以及这台机器,它到底消费了哪些,比如它存储、数据库,往下到一些网络。

broken image

为什么要围绕以应用为中心呢?因为这样会产生非常多场景可以做,比如持续交付、自动化作业变更、版本上线,只要运维人员做了变更,数据状态就能实时反馈到CMDB, 比如说我现在加了一台机器,那我加的这台机器按以前的路线可能只有用户才知道。现在很多互联网化架构里面的业务,有部分企业做到一些灰色发布。做到这些发布的能力过程中,你要明确地知道哪些IP上面布了新版本,哪些IP还没有更新。这块是谁来做呢?CMDB,只有监控变更才做得到。所以我们为什么说是一个IT资源管理,就是面向应用的IT资源管理,它是全生命周期的管理。

broken image

CMDB里面CI维护主要分为两层,一层是最早的基础层,一层是应用层,这个角度是我们需要新建的。目前来说,各个平台现在大家都是独立的,我们要通过什么样的方式去影响呢?比如说我故障影响分析,我现在已经监控到了我有故障了,那现在大家的做法是发一个告警邮件,发给相关的负责人,他看到邮件之后人工去做定位,定位完了人工在变更平台中去做修复动作。

为什么一些简单的动作不能做到自愈呢?比如我的监控平台监控到表空间使用不足了。变更平台里是不是有自动扩表空间脚本呢?这里完全可以通过CMDB关联起来做自愈动作的,相关负责人知道这个被修复了就可以了。DevOps建设要有对象关系的维护,而且是非常准的前提,你才能支撑上层的自动化的能力。

broken image

平常的一些场景包括上线、下线、故障自愈、持续部署等等都是需要强CMDB的过程,这里面很强调了我们CMDB里面都是以对象为基础来去支撑的,比如说我们是面向一个应用为对象的,或者我面向一个设备为对象,那么我针对这个对象或者针对这个应用,我要对它上层能够散发出什么样的自动化的能力。

broken image

下面来说一下,IP应用的生命周期为什么是靠CMDB能力来支撑的。比如上一个新的业务系统:从流程开始去申请一个资源变更的单,领导申请通过后线上管理人员能够接收到工单。通知系统部署的能力。系统部署的能力,我们现在大部分做到了虚拟化,比如CMP的一些接口,完全可以做到自动化创建的能力。往下走,带外监控机器是否创建成功。到自动化运维平台,从CMDB里面拉取这个新OS需要部署什么中间件以及依赖包等的一键安装。IT变更中心再往下走是应用构建与测试环境,我们在构建的过程中,这个环境准备好了,要去布包了,这个包是现机编译的还是什么直接发布制品包?我们有2条线,在发布过程中启动发布流程,发布流程会自动去CMDB拉取我们维护的这套数据,具体到拉取哪个包哪个版本,以及这个包的维护脚本是什么,推到我们的系统上部署成功之后,去跑我们的自动化回归测试案例。再往下走这个业务验证通过之后,CMDB获取到这个状态,那我监控平台可以往上做监控Agent部署了。这是我们非常标准的上线流程,完全可以做到一键自动化,比如一键扩容,容灾切换等场景。

最后说一下再招行的CMDB建设过程,现在在招行建的首先是建设一个应用的CMDB,然后在CMDB基础上建设流水线的能力。这里面关键点的原则,这个原则其实是当初分析非常多的时间才总结出来的。

1)应用CMDB必须提供统一的应用元数据管理能力,和应用类型无关

2)应用CMDB建设的核心诉求是应用生命周期管理

3)应用CMDB必须以应用为中心,而非以基础资源为中心

4)应用CMDB必须要从应用的角度构建起与IT资源的弹性关系

5)应用CMDB是为应用资源、动作、状态的统一管理提供支撑

6)应用CMDB要有统一的基础资源层CMDB作为基础

7)应用CMDB的核心场景就是持续交付

本次演讲内容分享就到这里结束,若是想下载PPT,可以在“优维科技EasyOps”公众号回复关键字“DOISPPT”即可获得。