IDCC2018民生银行毕永军:智能运维处于10阶段要从痛点出发
时间:2019-08-28 21:42

  中国IDC圈讯 12月11日-13日,由中国IDC产业年度大典组委会主办,中国IDC圈、CloudBest承办的以“赋能企业数字化转型”为主题的第十三届中国IDC产业年度大典(简称“IDCC2018”)在北京国家会议中心隆重召开。

  13日上午,IDCC2018分论坛智能运维安全论坛正式召开!本次论坛由威客安全和中国IDC圈承办,汇聚了来自来自运营商、互联网、数据中心云计算等多领域多行业的企业高管、★▽…◇嘉宾、媒体等。与会嘉宾们在大典现场,共话数字经济时代,▲=○▼聚焦数据安全问题,◇=△▲探讨智能化与可视化运维的新方向与新趋势。

  会上,中国民生银行信息科技部应用运维二中心负责人毕永军先生,为大家带来《民生银行的AIOps实践之路》的主题演讲。以下为演讲实录(未经本人核实):

  大家好!我是民生银行的毕永军,因为大家知道AIOps这两年比较火,也有人把2018年当作AIOps的元年,我们今年也做了一些实践,下面我花一点时间跟大家分享一下我们在AIOps这边做了哪些事情。

  分四个部分来讲一下,首先看一下为什么要做这个智能运维。现在大家提得非常多的,都在做数字化转型,其实在银行的领域,今年出现了金融科技,大家都在提这个事情,民生银行也有自己的定位,要在十年之内成为科技金融的银行。民生银行的战略目标,会向数字化、轻型化、综合化的标杆银行转变。民生银行在转型方面也做了很多工作,在2月份上线了分布式核心系统,以前的核心系统是基于小型机跟ICP,但是成本是非常高的,上线了分布式核心系统之后,单账户的成本从原来的2.5块降到8分钱,在节省成本方面的效果是非常好的。▪▲□◁另外5月份成立了民生科技公司。金融科技公司,今年人员规模也在不断扩大,开始要在金融科技方面要做一些发力。

  看民生银行这几年的发展趋势,在2000年初的时候,当时也是契合IT的发展规划,开始有网络,当时做的是老核心系统,是八大系统,在银行当时应该是比较早的做了全国集中的系统。•□▼◁▼民生银行在2012年投产的一个核心系统是面向服务的架构,金融科技主要还是基于分布式架构、业务架构的创新,这个发展过程也体现了科技在银行业当中,从成本中心逐步转变,给业务赋能,协同业务创新一起去发展。

  涉及到业务创新,之前讲了分布式核心,以及新零售用的一些大数据、机器学习的手段来做智能的风控,还有新技术的演进,微服务,以及容器平台的引入,民生银行的投入运行还是需要运维来支撑,这个技术的发展对运维带来了很大挑战。比如软硬件数量,老核心技术系统,两台小机运行了民生银行绝大多数的业务,但是到了民生银行(SAB)系统,发现这个系统规模一下扩大了,从原来的一百多套系统到四百多套系统,现在还在持续增加。所以,对于运维来讲挑战比较大。对于银行业来讲,稳定运行是非常重要的,故障处理难度很大,运维数据也需要去做进一步的分析,我们的组织和人才在新技术方面也面临着转型。

  这个解决方案,★△◁◁▽▼要用民生银行现在新的技术,用智能运维的技术,从传统运维去走向智能运维,我们认为这是必由之路。右侧这个Gartner的报告,这是2016年画的图书,其实很契合银行的现状,传统银行在监控管理自动化方面已经大量的工作,已经比较成熟,接下来智能运维是基于这个体系的基础上,运用新的大数据技术、机器学习的技术,引入对数据进行进一步的挖掘和分析,得出智能的结果,进行智能的决策,给出相应的解决方案,智能运维是下一代运维技术的必然选择。

  智能运维为民生银行带来的价值是什么?我自己的理解,智能运维对民生银行来讲,引入大数据和人工智能技术,从海量数据中进行智能分析和决策,最终目的是提升系统的可用性,降本增效,也是企业的永恒的话题。相对来讲分几块,第一感知体系,更多的是监控体系,收集数据。第二是数据体系,这些数据除了结构化的数据,很多是非结构化的数据,需要大数据平台来做存储,做统一的标准化。第三个是决策体系,需要引入人工智能,加入一些算法,●得到一些启示,或者是对事件的预先的发现,或者是有一些其他的事情可以通过这个决策体系得到。第四个是操作体系,跟自动化体系结合起来,针对比较标准化的场景可以做自动的处理,目前来看这种不算太多,主要原因还是在于现在IT复杂度太高,没有达到标准化的程度,不像现在的商品化,看电视按开关就可以打开和关掉。◆●△▼●但是有一些操作,是可以通过这个体系来运作的。

  我们也总结了一下运维场景,一种是质量保障,还有是效率提升和成本优化。我们对于日常运维的一些工单,智能工单处理,包括智能机器人,还有容量规划,性能优化,资源调度方面,我们都会做一些尝试。

  总结来看,智能运维的几个核心价值,□◁从三个方面去看,对做数据中心运维的人来讲,我们重要的是提高对系统的感知能力,降低故障的持续时间,很多业务都是移动化、互联网化,我们有的时候也学互联网公司做一些促销。我们平时系统的交易量是很低的,每天几万笔交易,但是促销活动来了就对运维挑战很大,如果做了预测之后就可以感知到异常,可以提前感知这个事情,再有是降低故障的持续时间。银保监会的底线分钟之内一定要恢复服务,我们提的目标是10分钟之内故障定位,10分钟故障解决,这样才能满足半个小时之内把问题解决掉的目标,这是对运维来讲。对科技来讲,对科技价值来讲,提高了系统可用性和成本节约,集中式系统已经达到极致之后,垂直扩展是很难的,通过分布式架构可以容纳10亿以上的账处理,交易量也可以大幅度的增加,◇•■★▼响应时间得到持续的降低,可以到50毫秒,也是体现科技的价值。从业务价值来讲,系统性能提升了,稳定度提高了,做很多秒杀,做促销的时候,系统能够支撑得住,对用户体验来讲就是好的提升。

  民生银行在里面做了一些探索跟实践。在做智能运维的时候发现有很多挑战,原来建设IT管理系统的时候也是做统一的规划,包括监控系统,包括流程系统,但是做智能运维,想把运维的数据打通,能够用的数据获得一些动态的信息,发现数据还是比较分散,结构还是非常多样化,引入了数据治理,把我们的数据做标准化。再有是技术挑战,包括自动驾驶,包括语音识别,发展得还是比较好的,但是对运维场景来讲,标准化程度没有那么高,场景非常复杂,对于研发来讲挑战就很大。举个例子,做故障预测,○▲-•■□有监督学习的时候就需要样本,一年真正对业务产生影响的可能就是10个、20个事件。数据量大了之后怎么进行实时的计算,需要有大的计算机群来支撑这个计算,这样才可以克服这方面的挑战。第三是人才和组织的挑战,民生银行还是传统架构的技术人才,包括组织架构,有网络管理人员,有存储管理人员,有系统管理人员,有应用管理人员,我们要做智能运维这件事情需要的算法人才是没有的,•☆■▲这对我们的挑战很大。

  要解决这些挑战怎么去做?我们也做了一些思考,一,智能运维本身还处于初级发展阶段,现在还没有成熟,我们想的第一个就是场景驱动,重点解决运维当中的痛点问题,可能有一个痛点问题让我们觉得头疼,就会有动力去解决这个问题,我们就做这样的场景,要做场景服务。第二点,有了场景之后,数据怎么来?怎么去做加工?我们提到运维数据中台,这两年中台的概念特别火,我们搞了运维数据中台,之前已经建立了比较完善的工具,我们需要中台系统能够把数据进行收集,存储,整理起来,变成一个标准化的数据体系。另外,我们把一些标准的算法放到中台上去。第三,需要组建一些敏捷团队,首先要有懂运维的业务,◁☆●•○△得知道运维业务是怎么做的,还要懂数据,懂算法,还得懂开发,你要落地,说了半天最后人家等着用,发现三个月啥事都没有,这个事就凉了,所以就需要快速交付,我们要建立虚拟化的敏捷团队来解决这样的问题。

  数据治理,我们搭了数据平台之后,上面是大家都在做的一些事情,其实我们在建立数据这块,原来数据中心都是标准化的,建立了几年成效也不算太好,究其原因还是消费场景太少,用得不够多,做数据治理的时候还是从需求驱动,拉动的方式,需要什么样的数据我给你加工什么样的数据,当然也有标准化的数据,我们做了数据建模,标准层按照标准做了28种计算模型,把有些数据按照这个体系建了四大体系,比如运维工单的数据,比如监控数据,性能数据,这个类别是比较相近的,分成四个体系。在运维数据中台上,对数据进行了一定的加工,便于做数据应用的时候可以很方便的获取标准化的数据。

  再看看我们这个组织,这是我们现在的组织情况,下面是支撑的工具平台,我们去做这个东西的时候会发现在数据中心内部,同样存在着数据管理的问题。各个中心之间还有一些隔阂,信息的交流,透明程度,▲★-●还远远没有那么高,确实存在这样的问题。我们要做智能运维就要打通,刚才讲了建立虚拟团队,按照项目的方式去组织虚拟团队,智能运维的项目,在数据中心层面下有领导挂帅,驱动数据中心的人一起参与进来,组织上的支撑也是很关键的,我们对数据模型算法和算力方面提供支持。我们还有运维工程师,运维开发工程师,还培养智能运维工程师,做算法开发。结合上面的智能运维的产品,结合我们的痛点和需求,我们做了几块,一个是智能故障的发现与分析,还有智能运维机器人,还有对运营数据的支持。我们发现人才很缺,我们和清华大学智能运维实验室进行合作,他们给我们提供一些培训,对算法上也有合作的开发。通过这个过程,我们发现效果也不错,一方面他们有他们的成果,但是他们缺场景,可以跟我们的场景结合起来。通过培训我们自己的人也掌握了这个能力,可以自己来做开发了,自己做算法开发。

  这是我们大概的平台架构,现在数据中心目前都是双态的结构,有不同的工具,中间的数据运维平台解决数据模型,算法和算力的问题,同时数据中台对上提供服务接口,还有展示层去做开发。平台搭建大多数是基于开源的技术,也是契合国家要求的自主可控,我们底层的大数据平台是一起的。

  下面简单讲一些场景,一个就是可视化,怎么做可视化?我们系统的情况也要做感知,我们应用系统放到显示屏上,对接了所有告警的数据,交易性能的数据都对接上去,包括系统架构图,整个呈现在上面。我们运行人员可以感知到系统的情况,如果某些情况出现问题,就看关联系统是什么,有哪些报警,都可以直观的呈现出来。

  我们大概分三步,一个是故障发现,一个是故障定位,一个是故障解决,还有智能异常检测,自动故障定位,调用链路分析,底层就是用到的一些数据,基于网络流量的交易监控的指标,CMDB的数据,机器的监控指标,基于流量镜像的交易信息数据。

  这是智能异常检测,◆▼我们和清华大学合作,2018年做了无监督的算法,对相似指标做了定位,因为我们系统非常多,要求还是很高的,算法整体上做了一些优化,平均的时间是1.5秒,把我们52套系统400多个业务指标进行异常检测,重点是关注业务,整体来看出了问题之后提高的有效率还是不错的。

  故障定位,以前也做过,现在是我们机器学习,▪•★就是看指标异常不异常,我们指标非常多,我们可以加人,把异常的指标出来,人再去判断一下。故障出现前后的时间,我们利用这段时间,6.5分钟就可以算出异常的指标,右下角就是同时出现异常的情况,方便我们可以进一步排查。

  调用链路分析,我们可以获得直观的呈现图,拿出一个系统来,其他系统调用都可以呈现出来,在日常运维过程中用得挺多的,可以去判断哪个系统有问题。

  举一个案例,仪表盘报警了,我们做故障检测,形成这么一个图,发现这个系统都调其中一个系统,★◇▽▼•因为所有系统一起出问题的概率是很低的,我们去看这个问题的时候,通过我们刚才讲到的异常检测,会发现排名比较靠前的,最后发现就是这个问题,进程宕掉了,某一个数据库节点出问题了,这个筛选了2700多个指标,一起找出原因,效果还是不错的。

  现在系统比较复杂,▪…□▷▷•中间这个业务可能很多时候没有不能像以前的强一致性,我们要进行分析,看具体哪个交易出问题了,看本身的调用链路的耗时,也可以对接到日志平台,看当时日志的输出来进行判断,把我们的故障发现和处理的过程可以串接起来。还有日志检测,咨询机器人等等,就不一一讲了。

  关于智能运维的思考,通过我们一年多的实践,运维数据的治理是非常重要的,只有规范集中的数据才能发挥最大的价值。就像人脸识别一样,拍的象素很低,让算法去识别,△▪▲□△跟清晰度很高的效果绝对是不一样的。我们的智能运维还处于1.0阶段,我们要从痛点出发。我们认为大数据分析和可视化仍然有很多地方可以做,通过大数据分析跟可视化,可以给我们运维带来非常大的价值。

  这是Gartner今年的技术成熟度的曲线,可以看到还处于前期探索的阶段,还有5到10年的时机,还是大有可为的,应该持续的投入。

  引用比尔盖茨的话,人们总是高估了未来一到两年的变化,低估了未来十年的变革。我们20多年技术进展非常快,进展速度是以我们想象不到的速度来进展的,◆◁•我们的深度和广度上要继续扩展更多的运维领域,甚至有人提到无人运维,我觉得未来也是有可能的。