【干货·案例】金融行业应用型CMDB建设实录

前言

GOPS全球运维大会暨首届金牌运维峰会于11月17日-18日在上海圆满举行。国信证券负责运维平台建设，具有此类丰富经验的讲师张浩水受邀出席大会，并在DevOps道法术器专场带来针对证券及金融行业的精彩分享《证券行业DevOps第一步：IT资源自动化管理》。本文根据此分享整理而来。

券商行业DevOps三步走

DevOps在我们证券业其实才刚刚起步。我们内部经过大量的研习和讨论，结合自身特点，把DevOps称为三个阶段：

1. 需求管理阶段；

2. 持续交付阶段，这个阶段与研发相关；

3. 运维管理阶段；

两个运维对外核心能力

基础资源交付是一个基础，如果脱离基础单纯讲应用交付能力，实际上也没有办法进入到应用全周期管理这个能力圈：

1. 基础资源的交付能力；

2. 应用的交付能力；

讲师张浩水自我介绍

自我介绍一下。我08年在中科院自动化研究所毕业，08年到15年做了招商银行系统运维及基础设施运维，2015年至今是在国信证券做运维架构师，负责运维平台建设。

02

证券行业的特点

可能上海的小伙伴对国信证券不是很了解，国信证券是一个立足于深圳的券商，有158家营业部分布在112个城市。在业务创新这块也有很多突出贡献，比如我们金太阳手机是券商行业第一家推出的手机APP，同时我们也推出了内存交易系统，专门为量化的客户做服务。

总结来说，国信证券业务创新应该是处于整个券商行业的前列。这种业务创新就需要我们IT运维能力给以支持，这也是现在我们IT运维能力迫切需要提升的一个重要原因。

我们现在最重要的待办内容就是整合运维平台，因为我们既有传统运维管理平台，也有新理念下的运维管理平台。怎么将它们整合交给我们IT人员使用，已经是我们现在面对一个很重要的课题。

证券行业有它自己的特点:

1. 跟金融行业很像，是稳态和敏态的并存。因为证券行业有114家券商，所以对业务的创新非常迫切，所以我们在敏态上对证券行业是有要求的，但是我们在稳态上还要满足证监会的合规的要求。

2. 证券行业它的运维组织架构已经做到了双纬度，更进一步说，就是基础架构和应用运维的双纬度管理。

3. 流程上绝大部分券商都实现了流程落地，这两个实际上和运维规模有关系，一般规模达到四五十亿以上都会会有人员的操作规范化等都要求这样。

4. 物理机和虚拟化的并存，这个就不多解释了。

03

券商们的挑战

在这种场景下我们在未来的几年都会看到我们的稳态业务继续保持这个态势，这样的情况下，对运维管理来说就很难做到统一管理，也就是很难用统一平台管理所有IT资源。

我们说什么叫稳态业务？就是我们的业务需求变更比较少，开发周期比较长的就是属于稳态业务。在国信来说为什么说稳态业务同质化严重呢？这个说起来很复杂，至少说明我们证券行业开发商很少，大概也就是三到五家，主要就是两家。新进来的这些竞争对手很难在这个行业里面立足，所以就会发生稳态业务ITSM同质化非常严重。以纯流程管理为主，这样就有一个问题，就是我们线上和线下的流程是脱节的，运维的效率低是因为本身只要做线下就可以了，现在还要专门做线上的填表和填单。其次我们以GUI的操作为主，这张图是我们以前的图，大家可以看到这是填的所有的内容，这个里面所有的内容跟我们监控都没有做任何对接，所以这个最后的用途只是用于审计。这样就会产生一个问题：人员的产出和收入是不一致，也就是说我们运维的人费了半天劲做出来这个单，最后没有和自动化对接。导致产出非常低下。

什么叫敏态业务呢？就是有点偏向互联网的业务，我们说到Fintech，证券创新Fintech推动运维也要同步创新，现在我们的直接竞争对手有xx、xxxx，所以这块对我们的创新要求非常高。敏态业务的特点就是开发周期在两周到一个月之内，这里就有一个问题了，如果我是传统运维，我这个时候就会说你等我三个月，我去买一个物理机回来……这个就很危险了，因为我这个业务等你三个月，别的竞争对手就起来了，所以这个时候运维怎么支撑这个敏态业务就变得非常重要了，要思考下运维以什么方式去支撑它做到快速交付。国信证券每两年业务规模会增长一倍，包括主机规模和发布数量，所以在这种情况下完全依靠人去堆，去作流程非常不现实。券商行业还是用鼠标点，到最后出现事故都没有办法做审计。

传统CMDB有什么局限，为什么不足以支撑运维体系构建？首先最近十年由于IT的推广，传统CMDB通用性不是很好，也没有针对性，就造成了运维人员还是喜欢用Excel表去维护，因为你IPE，让你去配，肯定不如Excel来的方便。其二，数据中心以基础资源管理为主，就是我们这个CMDB是以优先服务我自己，但是没有想到过CMDB要对运维进行服务，要对开发进行服务，结果做出来的CMDB也只有我来用，可能大的公司还可以，基础架构有50个人还能用起来，小的公司基础架构也就是五个人，十个人，二十个人，平常我们都是靠吼的，那还需要这个东西吗？不需要。其三，资源维护自动发现能力严重匮乏，维护成本高，效率低。最后就是系统运维的建设碎片，因为我CMDB从来没有考虑跟自动化对接，跟其他的对接，造成数据永远就是在小范围流转，没有给其他平台用。最后发现我们做出来这套东西很难支撑我们现有的运维管理平台了。

04

国信证券怎样迈向DevOps

这张是技术架构，涉及的技术债务多，缺乏端到端的高效IT价值流，上面的红色部分就是我们总结出来的运维和发布两个阶段的问题，在前面的原因，下面是一定的解决的手段。

整个券商基本上都是这样，缺乏面向DevOps端到端的IT流程，交付流动效率低下。整个IT标准化、持续交付过程规范，工具能力建设，系统架构，组织协作，监管体系等能力都需要全面的建设和提升。有这么多问题需要解决，所有券商都在考虑向DevOps转型，尤其是敏态业务。

那么，第一个该试点什么？就拿某一个敏态业务吧！国信也是这样想的，所以国信拿金太阳手机APP作为试点，希望它成功之后再一个一个推广。

我们一共两块，配套两个服务：微服务架构改造和业务监控。这样才能把整个体系全部做起来。

从我们的运维角度来看DevOps IT自动化的本质应该是两个层面：

1. 资源的交付层面，就是类似于Laas和Paas层自动化。

2. 应用交付平台，就是我们经常说的持续交付、配置管理，端到端交付这些，是利用DevOps做的。

这两个都很重要，现在它们是独立割裂的流程。我们怎样把这两个流程整合到一起去？其实就要做一个囊括两者的CMDB，这是我们的想法。

2015年，我们画了一张架构图，当时就讨论先做哪一块，很多内容，云管，持续交付，自动化、监控，一些大数据，各种各样的，到底做哪块。最后我们讨论决定，还是做基础：先把CMDB做起来，然后做消费场景，然后再做一些登录统一，流程统一，最后再做一个事件统一。因为我们金融工具非常多，传统的像各类监控系统等等这个渠道非常多，很多监控工具没有办法发挥效用，必须要做集中平台，把所有的工具统一起来，统一起来之后再用CMDB做比如事件告警。

之前我们看到有一些公司他们做事件告警，他说我今天排班，每一个组排一个人。现在银行经常这样做，因为你的监控不能精确到人，就只能靠人值班去做。

我们现在第一个阶段以CMDB为基础，建的内容第一个是统一事件平台、运维大数据平台，混合云管平台等。

国信的DevOps有三步走策略：

1. 资源自动化管理。为什么要做这一步？因为这是基础，如果不做这一步下面两步做完了，效果大打折扣。

2. 持续部署和运维自动化管理。这也是我们现在的痛点，因为整个券商行业都是手工操作，包括我们现在的很多运维人员就是手工操作，这样我们就要把人从这种人工模式中解放出来，让人去做二线工作。

3. 持续集成和持续交付。通过流水线打破开发、测试、运维的壁垒这个部门墙的问题，通过工具将这个交付能力建设成为一种可靠、可重复的，可持续的交付能力。

这是国信的思路。我们这个平台命名叫磐石系统，希望以它为基础，有一个坚实可靠的基础，然后在这个上面再做其他的业务场景。我们建设目标基本上就是这些思路，这些在两年前我们就开始做规划做设计，这里就不细说了。

然后我们系统有一个理念就是我们要面向业务去设计，为什么要这么做？因为我这个平台不能只给技术架构用，要给开发用，给运维人员用，他们看问题的不是像我们这样，他们看的视角是这个应用部署在哪里。所以最后你看这里有三个纬度：

1.基础资源； 

2.动作； 

3.职能监控；

第三个就是数据分析这块，最后要做成面向应用管理的场景。

应用CMDB建设七原则

1. CMDB设计得面向应用。既然面向应用，就要有下面两部分。

2. 面向基础的CMDB和面向技术的CMDB。

3. 面向LaaS和PaaS设计，能够管理底层的一切资源。

4. 状态控制借助运维流程自动化完成。

5. CI的维护要深度使用自动发现，而不是人工维护。

6. 资源信息必须能为上层应用提供服务。就是以前说的面向应用的CMDB。

7. CI的颗粒度，必须要符合未来的场景设计，假如我们公司有一些监控的场景，有一些变更装机的场景，那我的CMDB就必须要满足它才可以。

这是应用CMDB的建设七个原则。这里有一个方法论在里面，就是我做应用CMDB，我要看我的场景有哪些。对我们国信来说有两大场景，监控和持续交付场景。既然我知道了这两个场景之后，我再去做CMDB的建设就相对简单了，也更清楚。

这是我们的模型框架。从这条线来看往下都是基础CMDB，大家可以看到跟Laas层和PaaS都是一样的，我们管的内容基本要到机房、机柜等这些物理信息都要有。现在的敏态业务基本上都是采用这种方式去做。

基础的CMDB之上我们又开始了将CMDB和应用的这些内容做整合，我们应用包括哪些？包括证书和发布版本、配置信息，甚至包括镜像在里面。这两个整合之后就会生成业务和应用系统出来，相当于描述了我们整个CMDB的模型架构。

还有一个比较独立的一块，就是人员信息、部门信息等，这块为什么要加进去呢？是因为CMDB对外是服务了很多平台，这些平台都可能有采集人员信息的需求，所以这个时候既然已经在我CMDB统一拿到了数据，那就干脆把这块数据也纳入进来。其实CMDB本身也会用到这块信息，因为CMDB本身的业务属于谁负责，我的网络设备属于谁负责都要填写关联。

这块基本上是对应用怎么拆分，也有个方法论，我们拆分成部署资源和服务资源。部署资源就是安装资源，我们需要哪些资源；还有服务资源，就是说我运维的时候需要采用监控哪些资源，这些资源可能影响到我的业务可能性。这两部分资源通过一个场景动作再去做关联，建立应用交付动作和应用维护动作，这基本上是我们模型的一个思想。

磐石系统技术架构特点

整个磐石系统技术上的架构有几个特点：

1. 自动采集层。这个应用包括了很多协议，这些协议包括像agent、私有协议，ssh等等；

2. 资源对象层。我们采用的有OpenStoc，公有云，私有云，服务器、网络，存储，机房等等；

3. 开放式的API接口。因为我的CMDB要服务很多消费场景，这些场景不可能只在一个平台之上，就会需要给每个系统都要放统一且一致的API，去保证能够消费数据；

4. 模型资产管理能力。这个就不多讲了，我们在功能框架里面主要是模型管理这块的落地实践；

5. 拓扑管理。对运维来说我们初期关注的是一个点，比如我一台机器的属性，但是我们到后期就会有一个需求，我们要关注到两个机器之间关系的属性，这个属性怎么建立？我们就要采集这一层的关系，采集了这个关系之后，机器和机器的关系就要必须抽象成应用和应用的关系，当然你用的方式就很多了，像互联网的应用就要用交换机做，或者可能借助一些操作系统的命令去做。就是说我做这个拓扑图要分几个层次，有应用架构拓扑、应用部署拓扑，应用实例拓扑，基础架构拓扑，还有机房。

   

磐石系统的场景化规划

如果CMDB系统做完之后没有跟其他平台对接，实际上这个数据的价值非常有限。所以说我们这个时候在做CMDB的同时就要考虑到它有哪些场景设计。比如有一些各种流程、交付、监控平台，像统一事件平台，变更平台，分析平台的（流程），这些都要考虑进去。

这里重点讲一条，人员的逻辑。其实这块并不是说能够自动采集到，是有些信息不是通过自动采集回来，但作为CMDB系统来说，这个时候这块信息别的系统要用，那怎么办？一定要采集回来！确保别的平台对你平台有一个重度依赖。如果做不到这一点，其他平台在你平台拿不到这个数据，就会到其他平台拿，这样就会慢慢造成数据失控，统一数据的目标就完不成了。

05

磐石系统的建设成果

整个系统的落地实施跟一般项目差不多，现状评估、项目启动、CMDB实例化、数据校验，最后数据场景消费。一般是到数据校验就结束了。在国信做完这一步，就立刻做了周边运维平台与CMDB平台的对接，然后还有后面的与自动化平台的对接，和持续交付的平台对接，因为这些平台的数据变更相对准确。

整个平台的建设是从2016年启动，项目成员一共10个人，其实也不止10个人，因为咱们整个基本运维这块的人都要参与进去。

项目建设实录

• 2016年9月份开始建设和脚本开发； 

• 2016年10月份CMDB平台上线； 

• 2016年12月份流程平台开发，因为我CMDB维护不能光靠自动采集，还要靠流程去记录我的变更状态，所以我们当时启动了物理机上架流程，也对接了FID、自动装机平台，以及监控等工具所有都对接了； 

• 2017年1月启动了东莞数据中心的上线……第一个100%的对接IT资源管理平台。

这个机房有一个强项优势，从物理资源开始，从机柜、网络设备就开始标准化，然后从操作系统，从数据库等等也做了标准化，做完之后，也就非常标准化之后，你会发现脚本开发就变得非常容易了，很容易能够实现100%的对接，这个机房也是整个证券行业标准化的机房。

平台建设成果

再总结下一下我们的平台建设成果，俗话说好马配鞍，如果没有好的平台我们也做不到这些好的功能出来。

1. 平台特点就是从资产管理到资源的管理升级。我们以前的CMDB很多是静态的资产管理的系统，大家把这个定位定的都比较局限。我们现在要把这个功能扩大，但是我并不是一切的IT资源都要管进来，因为CMDB要数据准确性，所以能够纳入CMDB管理的资源应该是那些可以自动采集的资源、可以流程控制住的资源。如果资源处于失控状态，不能采集到，也不能管控，这时候就不能把这些数据跟准确数据捆在一起，只能够单独建一个表。因为一旦CMDB数据准确性不能保证，其他平台的数据就都不能得到保证。

2. 第二个就是动态资源模型秒级完成。这个在数据量大的时候按照以往方式做调整会非常耗费时间，而且也很难实现。所以我们要让现在的模型调整得能秒级之内完成。这是用的图数据库，应该是两个数据都用了。

   

3. 资源的自动发现。做这个其实说起来真的很简单，就是每个公司有运维研发岗位，对接一些协议，包括SNMP的协议，包括API都可以，还有网络设备还是SNMP的方式，但是过几年SDN的发展，API也非常成熟了，其他的就不用说了。CMDB这个项目不是项目做完，CMDB就做完可以撂挑子放手了。CMDB本身是一个持续优化、持续改进、持续完善的项目。因为我们公司买设备都是低价竞标，几次下来的中标商可能都不一样，那就得一直做对接，这样我如果有自己的运维研发岗，就能持续保证我的采集能够百分之百覆盖。这是我们的一个持久策略，大概是这么多。

4. 是面向应用的CMDB。我们之前最初做CMDB的时候，做的是基础资源到底属于哪个应用的环节，结果做完之后发现对机器特别友好，写代码特别容易。但这个对于应用管理人员和开发来说，这个不是他的视角，所以他们不会用这个东西……所以后面的建设中我们就改成这个应用到底管了多少，用了多少资源的思路，这样让应用管理人员从应用角度看待这个问题，于是CMDB就可以给应用开发广泛使用，实际上他们也非常喜欢。

5. 

总结一下这个特点：全开放式的API接口、全开源技术栈、与流程平台深度集成、面向集中管理。

国信的IT资源自动化管理建设成果

下面是基于磐石的IT资源自动化管理建设成果。我们做的相关流程是30多个，这些流程都跟自动化相关，不是纯流程，最后落地的是通过自动化要维护和CMDB关系的流程，这个是有关联了4个系统，分运维监控、IT管理、资源系统三大类。业务系统梳理需要领导大力支持，这块是全覆盖，组件也实现了全覆盖。

可能你想问，当时我们怎么做到的全覆盖？就是做了覆盖之后，要把每个时间去关联每个业务。如果做不到，就立马去找相关人员，问为什么没有关联起来，然后一直做到业务系统全覆盖。最后是一个实例信息，这我们一些核心资产，我们大概规模是应该X万台的机器。

06

可落地的经验总结

最后做一个总结，我们券商的案例应该对一些传统行业和泛金融行业有一些参考和借鉴的意义。

这是我们现在的一个实时情况，黄色部分就是已经实施完毕的情况，蓝色是还没有做完（正在做）的内容。大家可以看到其中有几大块吧，因为这属于规划，我们就是在这个里面填东西，一直在填。

我们现在趋向于监控系统，因为我们原来用的网络用得不是太好。我们所有的平台在选型时就已经定了一套标准，是要和CMDB去做对接。这个要求很基础实际了，否则运维平台就会失控，底层数据不统一，比如网络数据不统一，这些问题都非常严重。

首先做数据统一；然后到流程，应该说是流程统一，把整个公司运维流程做了一套出来，所有平台都要和它对接。所有的集中事件都要通过这个平台做事件告警；接着做运维大数据分析，统一容量数据分析。

平台搭建成果

我们觉得这个平台搭建的成果主要是这几点：管理，支撑，优化：

• 从管理角度来看实际上是降低了资源维护的成本，通过流程自动化去实现了轻量级的管理平台，然后也实现了资源全生命周期的管理。

• 数据支撑方面，我们第一阶段就已经和很多平台做了对接，建立了周边的场景消费，确保了数据的准确性和鲜活性。

• 优化部分，这个CMDB实现了IT变更服务流程能力再造，体现变更的能力。

平台实施经验

实施的经验部分重点讲两个，因为后面都是做技术的内容，就不用说了，因为跟这个项目经理或者项目成员的能力有关系。 

• 领导支持。这不是说我奉承我们领导，如果运营团队到50人以上，研发团队到350人的时候，实际上很多事情就不是一个运维人员能控制的，如果没有一个领导的大力支持，CMDB项目就很难能够落地。

• 理念和意识先行。大家知道金融行业是很传统的行业，无论是银行还是证券，很多运维人员还是习惯于做手工操作。我们现在做备份平台，思想保守一些的老干部说不定做了一辈子快退休了，他说不定就接受不了你做的备份自动化管理平台……所以在前期的培训、宣讲和咨询这块都必须要下力度，而且这也不是由一个研发或运维人员就能可以推动的事情。剩下与平台对接、持续交付这些都是纯技术内容，也没有什么大的实施难度。

受认可的创新点

整个系统的创新归纳如下：

1. 自动化采集。CMDB整个系统是以自动化采集为主的，以流程自动化为辅的。因为我们前期是这样的，自动化采集为主，人工验证为辅。

2. 复杂业务访问关系的拓扑图动态展示。大屏对运维来说并不是很实用，但我们要做的是一个业务访问关系的自动采集，动态展示。

3. 以应用为中心的资源管理全视图。

4. 以CMDB为核心的运维生态圈。就是说我的运维工具很多，可能有50个人，但是有20个运维工具，尤其是基础运维就更复杂了。我要做一个生态圈，以CMDB为基础，把这些资源全部整合起来。

最后，国信证券这边，我们券商其实氛围好，老板好，待遇好，假期多，不熬夜，不背锅……因为我在一些其他公司也接触过，略有了解，不背锅这一点能满足就很好了。为什么不熬夜？因为券商主要是5×7的工作特点，晚上没有什么变更，我们基本下午三点半做变更，最晚八点就下班了。出事时候领导很好，宽容，不会让我们背锅的。不像其他“传统”团队，锅都在员工背上。

实际上券商这个案例，我个人觉得对一些传统行业还是有一些借鉴意义。像证券这个行业没有垄断，大家都知道114家券商，这么多券商在这里竞争都非常激烈，业务创新真的不停在做。我们每年都在讲业务创新这个事情，尤其是交易类的产品。我们的运维怎样支撑这个业务创新？肯定是快速交付，稳定运维这方面。我们也希望在座的各位大家共同努力，对自己的行业尽自己能力做好支撑，做好行业内的创新工作。谢谢大家！