建行关于数据中心智能化服务台的研究

白凡

分享：郝丽萍
编辑：白凡

大家好，我是建设银行运营数据中心的郝丽萍，往运维方向转，所以刚刚改了名字。今天专场是金融专场的智能化，所以我讲的领域是服务台，服务台是某一个领域，不像刚刚王总介绍的工行、上海数据中心主机，而且讲的比较全面，像我讲的领域是专业的领域。

现在我在服务数据中心从“运维”向“运营”转型，现在我负责运营数据中心的创新公司。原来大家认为数据中心是稳态运行，现在从态逐步向敏态创新型数据中心转。我也是第一次参加GOPS的会，更多也是来学习的。

现在把我们前期做的工作跟大家做分享。分享的主要有三方面：

• 1.研究背景；
• 2.研究目标；
• 3.研究成果。

1. 研究背景

先给大家介绍一下，建设银行数据中心也是“两地三中心”的布局，五大行的发展历程应该差不多，刚刚工行的王总介绍了工行的数据中心的历程，从分行的核心上升到总行，从总行上升后要不做了新一代，走的历程是差不多的。现在是生产中心主要在北京，未来生产中心在稻香湖，现在还没有投产，现在的生产中国是北京洋桥，北京有一个总中心和灾备中心。异地灾备中心在武汉，已经投产2、3年了。

未来稻香湖主要做生产和全行控制，交易类系统生产也放在稻香湖。北京桐城有一部分是稻香湖的接入以及建行北京两地和武汉的一地都有。武汉主要是灾备以及准生产环境、渠道、大数据。大数据是P9到P12的生产都在武汉。

这是运营数据中心的团队划分，有些历史的远程，上海参数放在上海，原来上海是有数据中心，后来上海体制改革后就留了一些参数在上海，但里面相当于是数据管理部的业务领域。现在三地含有北京、武汉、上海，上海主要是参数，因为上海有全行的网络接入。

北京市牵头的主要是绿色部分，有技术设施规划、创新发展、工具和流程的建设。刚刚我也在请教王总工行是什么模式，现在我们是集中的模式，负责的流程和工具开发是集中的模式，没有放在运维团队。大家很多都是一线运维的人员，而我们是支持一线运维的人员。我们的压力也很大，尤其是智能化、自动化对领域要求越来越高，现在有集约化行里给的压力也比较大，数据中心的规模越来越大怎么通过智能化和自动化来实现人员的集约，而不是随着规模的增大人员会越来越多的情况。
基础设施方面北京和武汉都有的，基础设施的运维、基础设施的建设都有。现在新成立的有三个共有云团队，是有运营的概念在里面。有一部分是要做运营的，因为公有云是建行未来要输出的。我们是建行的大部门，两个牌子但其实是一个大整合团队。按专业领域一体化划分，有的团队是跨北京和武汉的，跨北京和武汉的团队就是虚拟的团队在运作。

这是数据中心的知识体系，最底层是ECC监控批处理是24小时值班的，北京和武汉有两个ECC中心，因为在北京和武汉看到的监控是一样的。如果北京满足ECC灾难性的不能支持，武汉那边是有全局监控能力完全能力支撑建设银行ECC日常工作的运转。再上面是一线的运维能力，我们现在支持的所有标准操作、标准变更，二线的能力是分领域划分的，是专业领域比较清晰的网络、平台、应用、存储、风险。三线是应用开发中心作为支持，如果基础设施的是厂商作为支持。左边是统一的基层管理，制度流程全部一套，有一体化的流程和制度，三个中心运作的一套制度和体系，标准也是一套，生产调度也是统一的。

服务台传统来讲相当于受理电话、流转、转派、解答问题。现在是除了24小时值班监控造作，把一线作为大服务台的概念，现在的范围相当于标准ECC运作方面称之为大服务台，下面我给大家分享的是在大服务台里做了哪些智能化的工作。
这是建行统一的服务台，大家知道我们有“95533”，“95533”是对外部客户的，建行客户有问题解答不了打“95533”总会找人解决。现在是内部员工响应服务台，是含业务的，不管是技术，业务也有。有了“4006695533”内部员工，后台会有二线三线进行支持。我们的“95533”解决不了问题的时候也会找到内部服务台、总行部门、外联合作单位等。

如果是业务问题，相当于是有分流的，如果业务问题会转到业务的一线人员，在成都有一个业务的作息全部支持业务工作流程。北京数据中心是“运营数据中心”，有了一个技术的服务台，相当于全行的技术支持。但是是用统一号码来接入的。一线解决不了有二线解决，二线解决不了有各个业务部门，如果还解决不了可以向技术专家来问，认为他解决不了的问题可能就是技术问题，也许是比较深的业务问题最后也会到技术响应专家，技术响应专家会转给作息，作息再通过技术的工作流程去做相关的工作。数据中心有二线，二线解决不了是三线，二线知识团队和三线厂家开发中心作为支持团队。这是建设银行大的内部员工响应服务台统一流程。

为什么要现在做智能服务台呢？因为服务台面向全行的支持，现在服务的网点是15000个，37个分行，日均受理问题2000个。

目前服务台还存在哪些问题呢？服务台的事件受理效率低，为什么我们要做智能服务台呢？因为觉得受理效率低，用户体验不好，受理电话以后记录解决问题率低，尤其涉及到具体技术问题的时候一时半会儿更找不到，知识库也不完善，这样操作的复杂度将人员解决出来引入智能化的手段对外提供更高效智能的技术支持和事件受理的服务。

数据中心在做智能化，今天我分享的是服务台智能化的研究。年初按照行里的要求、中心转型的要求做了智能化转型。当时对智能化、现有工具平台、数据中心的工具进行了一遍梳理，未来我们希望搭建什么样的平台呢？希望智能化做什么？具备哪些能力？总结出来了8项能力，当中画星的是服务台应该具备的五项能力。

1.会学习，智能化首先要会学习，会学习是自动对生产环境的相关配置、监控采集数据进行学习，完善相关的模型、知识、规律。原来传统大家觉得知识管理主要是靠人来积累的，把人的经验录进去存起来就是静态的知识。现在会学习智能化的知识是动态的，通过配置、系统画像形成动态知识，而且不断地根据生产环境变化形成的知识。
2.能感知，需要监控快速感知，利用流失计算实行了秒级监控，应用监控现在能达到10秒。利用流失计算和提高效率的实时监控能力提高监控的感知能力，系统一旦有风吹草动有问题的时候可以感知到系统出问题了，所以现在是可以感知秒级的监控能力。
3.会分析，基础数据是现在在建设的配置建立系统画像和运维进行比对和差异并且进行提前预警，智能化管理平台未来还需要有会学习的能力。
4.会推理，根据系统分析和评估结果，利用故障场景、专家建议等规则或模型，对故障、问题定位提供推理能力。
5.可预测，利用大数据平台采用预测和分析的算法进行智能和单指标的测试。
6.可决策，什么叫AIOps，就是要有大数据平台，要有人工智能和大数据智能结合起来的算法平台和算法分析来支持智能化的场景。
7.自动化，这是最基本的能力，大家知道智能化里是“脑心手”里的“手”，现在需要把简单、重复性的操作拿出来，用自动化的手段来实现。
8：可视化，数据中心建的是运维大数据平台，从运维数据和业务数据对可视化提出了特别高的要求。尤其前一段时间给普惠金融做了可视化展现场景，当然国家副总理刘鹤进行参观，给予了很高的评价。我们主要提供的是数据支撑，还有专业化的工具要提供专业化的手段。未来的运营能力可能也要通过此来展现。
讲一下研究目标。

2. 研究目标

这是梳理以后做智能化服务台用到了哪些智能化的相关技术，最底层是IaaS平台，是智能化平台里最基础的算力。在此上面是AIOps云平台，有深度学习、机器学习、大数据平台、通用组件、微服务框架，现在也在做微服务框架的改造和数据存储。基础层相当于数据处理，主要还是数据收集和统一采控平台和数据标注、数据处理、数据加载。算法层，算法层是现在的深入学习、机器学习、统计分析，现在说AIOps智能化主要是机器学习和深度学习。智能化是服务台用到的技术组件，技术层支持的是智能化服务台场景，第一个场景是语音处理，语音处理用到了语音识别、NPL（自然语言处理技术）。文本交互用到意图理解、NPL（自然语言处理）。

自然监控用到的最多，相当于比较大的场景，为什么放在服务台呢？因为范围是比较大的，而不是传统的只是受理变化。服务台的问题主要来自于变化和监控收到的信息，作为服务台要受理的问题。根因分析、业务影响分析、异常定位、稳态、异常检测等智能组件也是重要的。机器人客服用到的是知识图谱、意图、NPL。技术运营运维层有重的，因为对应到不同的场景，组合起来对应的场景就是这样。知识库用到了知识图谱、配置自动发现、配置自动校对。智能处置是自动化，智能处置涉及到智能流程编排、规则引擎。以上是智能服务台用到的智能化技术、场景。

今年IT条线技术在做智能化规划，在数据中心做了调研。收集了一下现在的运维场景有哪些，排了一下四象限。从下往上是从简单到复杂，从左到右是低频到高频，红框框出来的是智能服务台要用到的场景。
最左下面是规范化和流程化，是属于低频比较简单容易做成规范化和流程化的。在上面看一下低频复杂的是智能处置，现在尽管大家谈智能化这么多，但真正拿智能化的是场景太复杂，不是每一个通过自动隔离、重启就能解决问题，所以智能处置不是很高频地使用，智能处置属于复杂、低频的。
右下角是自动化、半自动化，首先要解决的问题是右下角，因为能解决在工作方面提升比较多，首先解决重复比较简单的事情，先做成自动化，像机器人客服和语音处理现在都比较成熟了。右上角是最难的，既复杂频率又高，因为智能化是没有终点的，不像自动化做完就算完了，但知识库、系统画像、健康度评估什么时候算做好了呢？这也是个漫漫长路。智能监控用到的异常检测，什么时候算达到了目标是很难说的。

前面是背景，研究目标里回到服务台了。最终智能化服务台应该具备的能力是什么呢？对客户，从业务的角度来讲应该具备什么能力呢？
1.听明白，不光是原来接电话进来要听明白，通过记录形成电话，通过语音分析听明白。还有把监控扩进来，将有效地告警通知到有效的人员，什么是有效的？要把这个告警同志到服务台人员，让他把告警听明白。听明白的含义来源于电话受理、告警信息。
2.秒回复，听明白以后怎么能通过秒回复很快地答复。通过自动的知识检索、引导式问答给业务客户比较满意的答复。
3.会学习，需要自动整合知识挖掘，用知识库、知识图谱积累的知识越来越多，让服务台变的越来越聪明。
4.能管事，服务台不是传统解决不了就转走了，未来要能管事，要能解决问题，首先要有端端事件的发生能力，系统可能还没有报警、还没有故障的时候就能发现有什么情况有可能会发生，要有管事的能力。根据知识识别能够组织发起应急，知道系统可能有问题了，怎么组织应急。

这是当时我们想研究时服务台具备的四个能力。

3. 研究成果

和大家分享一下研究的成果和落地成果。
1.怎么落地听明白。通过语音识别让热线听的更清楚，作为服务台的接线员可能有告警同志，一会儿接电话，又要搜索知识、记录问题，现在的问题是注意力分散，不利于问题解决，电话工单的填写质量不够高。怎么解决问题呢？采用语音识别的引擎，现在厂商在人工智能方面有语音识别的引擎，通过语音识别的引擎自动进行语音识别，技术路线接通以后能够将客户的语音转化成文字，根据预警正确识别展示在坐席人员的屏幕界面上，还有解决口语化表达和环境噪音的处理能力，语音识别要能考虑到范围，假如客户在商场打电话可能噪音比较多，那语音处理可能还需要有去噪音的能力。要理解引擎的噪声化和自然语言处理的过滤能力，听明白有语音的能力还有文本的能力，要用到自然语言的能力。作为银行来讲，银行的服务台有一些专用的词汇，银行的专用术语也有识别的能力。

有一个例子“我岳父这几个月的房款月付，怎么月付金额越付越多呢？”，接线员去听的话可能不能处理，但有了词法分析、语法分析以后就能把事说明白，让客户更加能听清楚，让电话受理员更清楚地理解客户在说什么。

刚才讲的主要是电话接进来服务台受理电话的能力，还有服务台受理的监控能力，怎么能让监控听明白呢？现在也做了一些尝试，收到多个告警的时候怎么通知别人？现在多条线路自动播，通过配置能找到到底是谁在值班，通过和值班系统联动就知道这个系统今天是谁在值班谁在运维，然后自动地拨电。人工作息实时跟踪，需要人工介入的时候介入，如果电话拨通了值班员的电话，值班员说系统没有问题是正常的是误报，他就自动地把工程师的解答填到系统里，值班员一看系统没有问题就把问题关闭了。机器的规模、监控指标在不断地扩展，工行是大机为主机器数量相对比较多，建行现在做了好多主机下移开放系统，所以机器数量越来越多，告警数量越来越多，必须要通过压制才能把告警数量压制下来，再通过关联让坐席员看了告警已经能明白是什么事。

下面是我们的流程，统一事件平台，所有的告警全部通过事件平台发起来，通过多长时间有个轮巡，到了一定的预值有规则来判断多长时间同志一次，触发告警超过了预值多长时间一次。可以实现自动拨号通知到人，人工播报方式出现告警的时候可以自动播报也可以用人工点，需要反馈记录把整个记录反馈回来。这是服务台所做的工作，下面是有自动、半自动的流程。

2.秒回复。秒回复主要还是依靠知识库，传统的知识库是主要靠人员的录入，大部分知识都是静态的知识，传统的知识库都是靠人录入的。现在智能化的数据库要通过数据分析、机器学习、历史数据的训练新城知识，通过配置、知识图谱形成动态知识。依据建立会学习的服务台越用越聪明，右下角相当于知识总结的流程，有业务的支持，有技术的支持。统一服务台目前要通过技术、开发中心、业务部门定期总结知识给到员工响应中心，要解答一些基本的问题，未来希望把左下角动态的知识管理做进去。

这是秒回复的案例，通过知识库使秒回复成为可能。现在下一代有三码，通过三码基本能够定位问题，通过问题能够找到对应的知识。

对于网点人员使用的员工渠道提供场景化的智能解决方案，自动实现员工渠道报错的问题，构建以菜单码、交易码、报告码总结到知识。机器人客服是逐步在成熟的技术，通过机器人通过知识库搜索，通过引导式的回答让他们快速地解答问题，基于知识库和推理的分析结合机器学习、情感技术来做的。

这是一个机器人客服分流服务台压力的案例，系统怎么这么慢？怎么这么破，怎么不好用。系统坐席平台会自动找出来近一个小时有哪些系统在报障，哪些系统慢。会在P2平台里做解答。

3.会学习。怎么通过事件闭环的处理流程变更，通过基础设施、CMBD构建知识库流程。事件受理是两方面，基础设施来自于监控、来自于电话受理，出现问题以后怎么从事件进入问题管理，如果问题解决不了通过变更，长期的问题可能通过项目管理彻底解决问题，通过基础设施变更来进行。这是事件处理的闭环流程，怎么形成现在的知识库。上面有一些人工智能的技术组建。

通过运维知识图谱不断地更新知识，会学习主要是怎么完善知识库，数据主要是实体属性、关系。要把实体的属性梳理出来，之间的关系梳理出来，按照领导的要求把数据中心的数据全部梳理了一遍。右边是怎么构建知识图谱，通过自有数据、爬虫、数据清晰拿到数据，数据拿到以后怎么识别实体？怎么做分析？就是把上面的实体属性、关系分析出来，分析出来再构建知识图谱，右边是知识图谱的构建过程。

会学习很重要的是配置管理，未来数据中心不管是做人工智能、智能化未来配置都是基础。能管事是4大能力，服务台怎么变的能管事，能把事情管起来而不是把问题给传过去呢？

4.能管事，系统还没有告警但怎么通过用户体验发现系统用户体验不好，有客户流失了呢？针对现在Web和客户端APP引入客户数据采集，相当于手机用户做到哪一步觉得不好用就退出了，未来这些也要纳入到数据管理。在客户不知道的时候怎么知道系统、操作上有外部的突发事件会影响系统的问题呢？

了解系统的手段通过健康评估，可能系统没有影响到客户但有些隐含的问题怎么发现呢。系统画像是原来认识系统是通过人的认识，现在是怎么通过工具让工具来认识系统是什么样的，借助与系统画像怎么理解系统是我们做出来的场景。

数据中心系统的关系视图是通过配置构建出来的，一个系统为中心跟哪些系统有关系。词云视图是分析告警，哪些词的频率特别高就定位到某些方面，假如说某些系统的词频繁在告警里出现的比较多，说明它是根源系统，大部分都是配置系统构建出来的图，未来大家可能理解不一样，现在我们只是做了一部分尝试和探索。

健康度评估是怎么说明系统的是健康，健康检查、健康管理、健康建议。健康检查是通过算法对每天做健康检查，跟之前的比较比对出来有没有差异发现系统是不是健康的。健康管理是对指标的全种进行计算，健康检查相当于体检，体检出来给一个指标健康度是多少，是80分还是90分。

健康建议是像体检的表，健康体检出来有问题建议后续怎么做。智能处置相对来说比较南作，因为这是一套流程。收到告警以后通过交互怎么处理的流程。