前言
GOPS全球运维大会暨首届金牌运维峰会于11月17日-18日在上海圆满举行。国信证券负责运维平台建设,具有此类丰富经验的讲师张浩水受邀出席大会,并在DevOps道法术器专场带来针对证券及金融行业的精彩分享《证券行业DevOps第一步:IT资源自动化管理》。本文根据此分享整理而来。
券商行业DevOps三步走
DevOps在我们证券业其实才刚刚起步。我们内部经过大量的研习和讨论,结合自身特点,把DevOps称为三个阶段:
两个运维对外核心能力
基础资源交付是一个基础,如果脱离基础单纯讲应用交付能力,实际上也没有办法进入到应用全周期管理这个能力圈:
讲师张浩水自我介绍
自我介绍一下。我08年在中科院自动化研究所毕业,08年到15年做了招商银行系统运维及基础设施运维,2015年至今是在国信证券做运维架构师,负责运维平台建设。
02
证券行业的特点
可能上海的小伙伴对国信证券不是很了解,国信证券是一个立足于深圳的券商,有158家营业部分布在112个城市。在业务创新这块也有很多突出贡献,比如我们金太阳手机是券商行业第一家推出的手机APP,同时我们也推出了内存交易系统,专门为量化的客户做服务。
总结来说,国信证券业务创新应该是处于整个券商行业的前列。这种业务创新就需要我们IT运维能力给以支持,这也是现在我们IT运维能力迫切需要提升的一个重要原因。
我们现在最重要的待办内容就是整合运维平台,因为我们既有传统运维管理平台,也有新理念下的运维管理平台。怎么将它们整合交给我们IT人员使用,已经是我们现在面对一个很重要的课题。
证券行业有它自己的特点:
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自动化的本质应该是两个层面:
这两个都很重要,现在它们是独立割裂的流程。我们怎样把这两个流程整合到一起去?其实就要做一个囊括两者的CMDB,这是我们的想法。
2015年,我们画了一张架构图,当时就讨论先做哪一块,很多内容,云管,持续交付,自动化、监控,一些大数据,各种各样的,到底做哪块。最后我们讨论决定,还是做基础:先把CMDB做起来,然后做消费场景,然后再做一些登录统一,流程统一,最后再做一个事件统一。因为我们金融工具非常多,传统的像各类监控系统等等这个渠道非常多,很多监控工具没有办法发挥效用,必须要做集中平台,把所有的工具统一起来,统一起来之后再用CMDB做比如事件告警。
之前我们看到有一些公司他们做事件告警,他说我今天排班,每一个组排一个人。现在银行经常这样做,因为你的监控不能精确到人,就只能靠人值班去做。
我们现在第一个阶段以CMDB为基础,建的内容第一个是统一事件平台、运维大数据平台,混合云管平台等。
国信的DevOps有三步走策略:
这是国信的思路。我们这个平台命名叫磐石系统,希望以它为基础,有一个坚实可靠的基础,然后在这个上面再做其他的业务场景。我们建设目标基本上就是这些思路,这些在两年前我们就开始做规划做设计,这里就不细说了。
然后我们系统有一个理念就是我们要面向业务去设计,为什么要这么做?因为我这个平台不能只给技术架构用,要给开发用,给运维人员用,他们看问题的不是像我们这样,他们看的视角是这个应用部署在哪里。所以最后你看这里有三个纬度:
1.基础资源;
2.动作;
3.职能监控;
第三个就是数据分析这块,最后要做成面向应用管理的场景。
应用CMDB建设七原则
这是应用CMDB的建设七个原则。这里有一个方法论在里面,就是我做应用CMDB,我要看我的场景有哪些。对我们国信来说有两大场景,监控和持续交付场景。既然我知道了这两个场景之后,我再去做CMDB的建设就相对简单了,也更清楚。
这是我们的模型框架。从这条线来看往下都是基础CMDB,大家可以看到跟Laas层和PaaS都是一样的,我们管的内容基本要到机房、机柜等这些物理信息都要有。现在的敏态业务基本上都是采用这种方式去做。
基础的CMDB之上我们又开始了将CMDB和应用的这些内容做整合,我们应用包括哪些?包括证书和发布版本、配置信息,甚至包括镜像在里面。这两个整合之后就会生成业务和应用系统出来,相当于描述了我们整个CMDB的模型架构。
还有一个比较独立的一块,就是人员信息、部门信息等,这块为什么要加进去呢?是因为CMDB对外是服务了很多平台,这些平台都可能有采集人员信息的需求,所以这个时候既然已经在我CMDB统一拿到了数据,那就干脆把这块数据也纳入进来。其实CMDB本身也会用到这块信息,因为CMDB本身的业务属于谁负责,我的网络设备属于谁负责都要填写关联。
这块基本上是对应用怎么拆分,也有个方法论,我们拆分成部署资源和服务资源。部署资源就是安装资源,我们需要哪些资源;还有服务资源,就是说我运维的时候需要采用监控哪些资源,这些资源可能影响到我的业务可能性。这两部分资源通过一个场景动作再去做关联,建立应用交付动作和应用维护动作,这基本上是我们模型的一个思想。
磐石系统技术架构特点
整个磐石系统技术上的架构有几个特点:
磐石系统的场景化规划
如果CMDB系统做完之后没有跟其他平台对接,实际上这个数据的价值非常有限。所以说我们这个时候在做CMDB的同时就要考虑到它有哪些场景设计。比如有一些各种流程、交付、监控平台,像统一事件平台,变更平台,分析平台的(流程),这些都要考虑进去。
这里重点讲一条,人员的逻辑。其实这块并不是说能够自动采集到,是有些信息不是通过自动采集回来,但作为CMDB系统来说,这个时候这块信息别的系统要用,那怎么办?一定要采集回来!确保别的平台对你平台有一个重度依赖。如果做不到这一点,其他平台在你平台拿不到这个数据,就会到其他平台拿,这样就会慢慢造成数据失控,统一数据的目标就完不成了。
05
磐石系统的建设成果
整个系统的落地实施跟一般项目差不多,现状评估、项目启动、CMDB实例化、数据校验,最后数据场景消费。一般是到数据校验就结束了。在国信做完这一步,就立刻做了周边运维平台与CMDB平台的对接,然后还有后面的与自动化平台的对接,和持续交付的平台对接,因为这些平台的数据变更相对准确。
整个平台的建设是从2016年启动,项目成员一共10个人,其实也不止10个人,因为咱们整个基本运维这块的人都要参与进去。
项目建设实录
这个机房有一个强项优势,从物理资源开始,从机柜、网络设备就开始标准化,然后从操作系统,从数据库等等也做了标准化,做完之后,也就非常标准化之后,你会发现脚本开发就变得非常容易了,很容易能够实现100%的对接,这个机房也是整个证券行业标准化的机房。
平台建设成果
再总结下一下我们的平台建设成果,俗话说好马配鞍,如果没有好的平台我们也做不到这些好的功能出来。
总结一下这个特点:全开放式的API接口、全开源技术栈、与流程平台深度集成、面向集中管理。
国信的IT资源自动化管理建设成果
下面是基于磐石的IT资源自动化管理建设成果。我们做的相关流程是30多个,这些流程都跟自动化相关,不是纯流程,最后落地的是通过自动化要维护和CMDB关系的流程,这个是有关联了4个系统,分运维监控、IT管理、资源系统三大类。业务系统梳理需要领导大力支持,这块是全覆盖,组件也实现了全覆盖。
可能你想问,当时我们怎么做到的全覆盖?就是做了覆盖之后,要把每个时间去关联每个业务。如果做不到,就立马去找相关人员,问为什么没有关联起来,然后一直做到业务系统全覆盖。最后是一个实例信息,这我们一些核心资产,我们大概规模是应该X万台的机器。
06
可落地的经验总结
最后做一个总结,我们券商的案例应该对一些传统行业和泛金融行业有一些参考和借鉴的意义。
这是我们现在的一个实时情况,黄色部分就是已经实施完毕的情况,蓝色是还没有做完(正在做)的内容。大家可以看到其中有几大块吧,因为这属于规划,我们就是在这个里面填东西,一直在填。
我们现在趋向于监控系统,因为我们原来用的网络用得不是太好。我们所有的平台在选型时就已经定了一套标准,是要和CMDB去做对接。这个要求很基础实际了,否则运维平台就会失控,底层数据不统一,比如网络数据不统一,这些问题都非常严重。
首先做数据统一;然后到流程,应该说是流程统一,把整个公司运维流程做了一套出来,所有平台都要和它对接。所有的集中事件都要通过这个平台做事件告警;接着做运维大数据分析,统一容量数据分析。
平台搭建成果
我们觉得这个平台搭建的成果主要是这几点:管理,支撑,优化:
平台实施经验
实施的经验部分重点讲两个,因为后面都是做技术的内容,就不用说了,因为跟这个项目经理或者项目成员的能力有关系。
受认可的创新点
整个系统的创新归纳如下:
最后,国信证券这边,我们券商其实氛围好,老板好,待遇好,假期多,不熬夜,不背锅……因为我在一些其他公司也接触过,略有了解,不背锅这一点能满足就很好了。为什么不熬夜?因为券商主要是5×7的工作特点,晚上没有什么变更,我们基本下午三点半做变更,最晚八点就下班了。出事时候领导很好,宽容,不会让我们背锅的。不像其他“传统”团队,锅都在员工背上。
实际上券商这个案例,我个人觉得对一些传统行业还是有一些借鉴意义。像证券这个行业没有垄断,大家都知道114家券商,这么多券商在这里竞争都非常激烈,业务创新真的不停在做。我们每年都在讲业务创新这个事情,尤其是交易类的产品。我们的运维怎样支撑这个业务创新?肯定是快速交付,稳定运维这方面。我们也希望在座的各位大家共同努力,对自己的行业尽自己能力做好支撑,做好行业内的创新工作。谢谢大家!