一、背景介绍
传统的呼叫中心主要依靠单一的电话呼入方式为客户提供简单的服务，随着IT技术和通讯技术的飞速发展，这种单一的电话方式已经不能满足客户的需要，为顺应时代发展，客服系统涉及到的产品、技术和服务模式也在不断的改革创新，现在的呼叫中心可以通过WEB、微信、APP、文字、视频、传真等多种渠道联络手段为客户提供服务，以此更好的满足客户不断变化的深层次需求。依托大数据、云计算和互联网技术的快速发展，人工智能技术应运而生，并被快速应用到呼叫中心领域，智能语音、机器人、语音识别、语义分析等产品的出现，有效降低了客服中心的人力成本，新技术、新产品引入的同时，客服系统的维护变得越来越复杂，目前各大银行的客服系统涉及到的产品大约均在20个左右，维护难度之大可想而知，对于客服系统运维人员来说也面临着巨大的挑战。
二、客服系统监控发展历程
客服系统的特点是，厂商多、产品多、专有设备多，监控手段单一，G行针对客服系统的监控经历了三个阶段：
第一阶段：基础监控+人工巡检
客服系统建设初期，仅包括应用、系统、中间件、数据库等标准监控，专有设备只能通过ping的方式获取主机状态，对于专有设备的资源占用情况运维人员只能通过人工巡检的方式查看，设备运行风险较高。
第二阶段：脚本辅助监控
通过脚本的方式，获取部分指标写入临时文件，统一监控平台再通过定期轮询的方式查看文件内容，发现关键字，再通过短信方式推送告警给运维人员。脚本辅助方式虽然增加了中继组状态、媒体资源、系统资源使用率等重要指标监控，但覆盖范围有限，获取方式不灵活，实效性较差。
第三阶段：专业平台监控
通过代理、接口、syslog、snmp等采集方式收集日志与告警信息，实时展示客服系统运行状态和关键指标数据。监控采集方式由被动的轮询式告警转变为主动推送的流式告警，专业监控平台虽然可以解决80%的告警需求，但还有一些特殊化的需求还不能覆盖，比如陡增突降告警、同比环比等复杂的需要经过统计运算的告警、智能化故障诊断及业务关联影响分析等。
三、客服智能监控分析平台建设
G行目前正在进行客服智能监控分析平台建设，在平台建设之前，G行从业务视角、科技运维等角度深度挖掘客服智能监控要解决的核心问题：
从业务视角考虑，客服智能监控分析平台需要解决的核心问题主要有如下几个方面：
- 支持关键KPI指标和运营能力指标实时展示，包括坐席KPI指标、渠道话务量统计、区域话务量统计等
- 支持话务量按日预测及实时矫正二次预测功能
- 支持客服重点交易、热点业务、投诉、舆情等数据实时展示
- 对恶意呼叫进行核实与屏蔽，可实时展示异常挂机数据，分析挂机原因
从科技运维角度考虑，客服智能监控分析平台需要解决如下问题：
- 覆盖客服产品监控盲区，涉及PBX、IVR、CTI、媒体网关等特殊设备的监控，监控指标包括中继利用率、媒体资源使用率、IVR并发量、CTI链路消息数、CTI链路状态、媒体网关状态等
- 实现对客服人工智能产品的监控，包括ASR、TTS、机器人等产品的并发量、许可使用量等数据的实时统计与展示
- 为容量管理提供有效的、准确的数据支撑
- 指导运维人员快速定位、快速恢复生产问题
- 支持对历史发生的事件进行复盘、推演、溯源
- 智能诊断、智能分析故障对业务的影响
客服智能监控分析平台框架
基于上述监控体系指标和功能需求，整体框架示意图如下所示：
客服智能监控分析平台自下而上的架构如下：
- 数据采集层：负责监控分析数据采集与预处理策略执行。数据采集层支持多协议，以实现异构数据源的采集。采集模块支持分布式水平扩展，以满足大规模、高时效数据的采集需求。
- 数据存储层：采用高速缓存中间件Redis实现对复杂或操作代价较高的实时数据进行缓存，以保障实时数据的高频访问效率。采用Elasticsearch实现离线数据存储，支持高吞吐数据写入以及大规模数据存储，存储和查询性能可线性扩展。配置数据则采用关系型数据库Oracle实现持久化存储，提供事务型数据处理。
- 分析与计算层：实现分析规则和算法计算。分析规则包括告警触发规则、告警处理规则、容量分析规则、关联分析规则等。通过模式匹配引擎分析流式数据中的时序与依赖关系，实现数据关联分析。匹配规则可动态配置以适应复杂多变的业务需求，通过历史数据的对比和分析，实现阈值的动态调节。
- 业务展现层：实现业务功能展示。通过Spring Cloud微服务实现业务模块标准化，支持按需弹性扩展，通过Spring Security提供统一的权限和登录控制，通过Portal提供视图的组件化管理，实现业务视图的灵活定制化。
采集与处理流程
随着业务的发展和智能化平台的引入，监控对象的分类和数量越来越多，各类数据，如指标数据、分析数据、日志、告警等更是指数级倍增。因此，一方面数据采集与处理流程应实现各类数据的统一转译和结构化处理，使得数据可识别、可使用；另一方面客服智能监控平台除了关注运行数据外，还需要深入到运营业务流程中，汇集整合客服业务运营和系统运行的各类数据，形成完备的数据集合，完成数据互联。采集与处理设计方案需具备低耦合、高内聚、弹性扩展等特点，才能满足高并发、高时效、大规模数据处理的需求。
分析模型与计算
客服智能监控分析平台中的分析模型和计算能力是实现智能运维的关键点，分析模型决定了监控分析结果的有效性和深度，计算能力是保障智能监控分析目标得以实现的首要因素。从话务异常分析、容量分析、故障关联影响分析、故障复盘推演等方面设计模型，并不断优化，达成智能化监控的目标。
场景实践与思考
1、告警关联分析
客服系统是一个复杂的有机体，每个组件的故障不再是孤立的事件，有可能影响到业务的可用性或者客户的访问体验，因此基于组件间的业务依赖和数据流向构建组件关系图谱，可实现故障的关联影响分析，判断出故障的影响范围和程度，为运维工作的处理决策提供数据支撑。
当组件出现故障时，依据组件间的关系类型，系统可以判断出关联组件的可用性或容量是否会受到影响，可计算出此影响是否会传导到业务层或其他组件上。
2、运营数据关联分析
运维工作的目标是保障业务的可用性和连续性，当业务存在异常时，可基于客服系统正常运行模型的匹配来识别。以呼叫日志分析模型为例，当运营监控中显示队列排队人数较多时，有可能是坐席比较繁忙，人手不够导致，但也有可能是客服系统自身原因导致呼叫无法正常分配给坐席，我们可以通过呼叫日志分析模型检测电话呼叫是否存在异常，当呼叫日志流流入计算框架时，检测到与正常呼叫日志不匹配时，则可判断为客服系统异常。
3、故障复盘与推演
故障发生时，运维人员大都是优先处理故障，尽快恢复系统正常使用，如果事后不对故障进行复盘分析的话，再次发生故障时，运维人员仍然不能快速识别出同类故障，影响故障处置效率。智能监控分析平台在告警发生时，不但可以识别出故障并生成告警信息，还会保留故障相关的周边信息，以时序方式记录故障的上下文场景和组件间关联告警信息，并支持以电影放映的模式，将故障发生前后的各种相关数据进行回放和推演，以便发现故障发生的规律，优化故障分析模型，为运维人员快速定位故障原因提供工具支撑。
下一阶段建设目标
数据是一切运维的基础，也是智能监控分析和数据驱动运维的关键资源，未来几年，客服智能监控分析平台的智能化程度将会持续加深，数据也将变得更加连贯和立体。客服智能监控平台下一步将在业务探测、趋势预测、动态阀值、智能告警方面进行更深入的研究与尝试。
