干货 | 携程新一代呼叫中心话务监控平台

作者简介 

通信技术中心，主要负责携程呼叫中心日常运维，包括配置管理和监控平台开发，目前主要在呼叫中心运维自动化方向探索和演进。

一、携程呼叫中心话务概况

携程作为中国最大的OTA，和国内外近十家电信运营商展开合作，目前拥有语音线路通道10000+，包括传统语音线路以及基于软交换平台的SIP线路，每天的话务量更是以百万计。从业务类型来说，又可以分为人工呼入呼出、自动呼入呼出和自动转呼等等。

面对不同运营商、不同线路特性的运维管理和灵活多变业务需求，基于监控精细化、自动化、操作便捷化标准下做到对故障快速响应和处理的目标，我们开发了一套针对呼叫中心话务监控管理平台——Horus系统。

二、原有监控痛点

携程呼叫中心原先有一套监控携程所有的呼入呼出话务的监控系统，不过在使用过程中，系统存在以下问题：

图1：原有监控痛点

三、Horus系统特点

Horus系统对这些问题进行了针对性的处理，目前通过以下功能可以自动发现并及时准确的进行告警：

图2：Horus系统特点

四、Horus系统架构

系统架构图：

图3：系统架构图

Horus系统主要由以下模块组成：

1. 采集模块：从数据源采集数据，输送到消息中间件Hermes，支持DB及API方式采集；

2. 存储模块：从Hermes获取数据，并存储到文件数据库Hickwall，将监控项索引存储到Mysql DB中；

3. 故障检测：从Hermes获取已采集的数据并调用数据分析模块进行故障检测；

4. 数据分析：根据历史数据分析生成告警规则，检测当前数据，生成检测结果和告警信息；

5. 告警聚合：将告警进行聚合，聚合后的告警信息返回Hermes；

6. 告警通知：从Hermes调取告警信息，执行告警通知，并将告警通知存入DB；

7. 自动测试：调用“语音机器人”功能，执行自动测试任务；

8. 监控展示/配置：执行用户和系统的交互；

系统逻辑图：

图4：系统逻辑图

五、Horus系统解决方案

整体方案主要结合以下几个方式进行设计：

自动检测

• 算法原理：

自动检测是Horus系统的核心功能，我们的做法是对海量历史数据进行采集和处理，按照以上几个方案形成3种智能化检测策略。

1.   阈值分析

将历史数据结合正态分布生成阈值上下限，再计算越界次数，生成阈值分析策略。为了提高阈值准确性，我们将历史数据区分工作日、双休日以及节假日。同时考虑周期属性，将数据按时间片再细分，对比每天同时刻数据，缩小偏差。

2.    变化率分析

根据数据变化的趋势，利用差分统计计算前后点之间的变化率，和自身数据前后趋势作比较，生成变化率分析策略。

3.   跌零检测

对当前数据进行跌零检测，结合损失话务量和跌零次数判断是否告警。

4.   自动告警逻辑：

根据以上三个策略对实时的监控数据进行检测：

1、先进行跌零检测，如判断数据跌零且满足累计损失话务量或次数条件，则告警；

2、如果数据未跌零，则进行阈值分析和变化率分析，部分场景再结合累计影响话务量以及是否为节假日判断，满足条件则告警，否则不告；

阈值分析&变化率分析示意图如下：

1、Point-A1的值超过阈值下限，且该点与前一点的变化率C-Rate1大于变化率门限，所以该点为异常点。

2、Point-B1的值超过阈值上限，但该点与前一点Point-B2的变化率C-Rate2小于变化率门限，所以该点判断为正常点。

图5：阈值分析&变化率分析示意图

六、业务应用场景：

• 话务量监控

• 成功率监控

• 周期性特征取值

• 小话务量的离散数据

• 关联数据告警

• 长期小幅下跌

• 话务量自动检测：

某号码话务量在一个时间段数据陡降，连续2个点低于阈值下限，同时变化率大于门限值，触发告警。

图6：话务量告警

• 成功率自动检测：

成功率的检测不仅仅是检测是否低于某固定指标，也是需要根据不同业务的特性以及不同时间段进行监控。针对容量类或成功率等特殊监控类型，我们基于历史数据进行阈值分析，生成动态的阈值上限或下限规则，即能满足告警要求。

图7：外呼成功率告警

• 周期性特征取值：

因业务类型不同，部分话务数据存在陡升陡降情况。针对此类数据，我们采用特征分析的方法，自动发现其特征规律，减少误告。

例如某监控项在每周固定时间段有一个数据突升，我们通过特征分析发现了这个规律，作为后期告警检测时的重要参考，避免误告。

图8：周期性特征取值

• 小话务量的离散数据

小业务量监控项一直以来都是业务监控的盲区，因为业务量小导致告警规则难以确定。对此我们采用了数据聚合的策略，从数据量和业务形态两方面入手，自动分析监控项特征并打上标签，通过不同聚合维度对监控项进行检测和告警。

图9的常规时间序列图中，该监控项的数据是离散的，传统方法无法有效监控起来。经过聚合之后，图10的数据被聚合成1小时维度的，这样形态就变得很有规律，可以进行检测和告警。当然，聚合之后虽然可以解决检测和告警的问题，但展示和监控维度都变成1小时，从问题发生到告警触发时延有所延长。

图9：常规时间序列图

图10：聚合时间序列图

• 关联告警

话务监控项之间往往存在着一定的关联性，我们通过将2个或多个相关的监控项自动关联，以减少误告避免漏告。

下图我们将传真请求总量、传真发送总量进行关联。以下红色圆点请求总量增加，但发送总量没有变化，因此进行告警，而后面的请求总量增加，同时发送总量也增加，系统关联后，不进行告警。

图11：关联告警

• 长期小幅下跌

对于某些长期小幅下跌的问题，传统方式无法有效检测，通过聚合之后阈值和累计影响话务量的检测，可以有效发出告警。

图12：长期小幅下跌

七、告警筛查

告警检测依赖的是历史数据分析，而业务也有其随机性，因此不可避免的存在误告的可能。对此，我们采用自动测试方式对告警进行筛查。

自动测试功能的实现基于我们的另一款产品“语音机器人”。针对话务量，成功率等监控项，获取疑似告警发生后，系统会调用“语音机器人”功能，根据测试用例进行自动测试，将测试结果返回后插入到告警信息中，并告知运维负责人该告警为误告。

图13：自动测试报告

八、告警聚合

监控系统发出告警之后，可能会引申出另一个问题，那就是告警风暴。告警风暴通常发生于以下两种情况：

1、系统发生大型故障，多个监控项同时发生告警

2、单个监控项连续发生告警

针对告警风暴，我们的做法是将大量重复的、或同类的告警压缩为一条真正有意义的告警，为运维人员提供甄选之后的最重要的告警。

这里有两个规则：

1、同一通知组，1分钟内同时发生的不同告警合并成一个通知内；

2、同一监控项，30分钟内的告警只通知一次，不再重复通知；

用户也可以查看聚合之前的告警以及他们的时间序列关系。实际使用中，告警压缩率可以达到95%以上。

九、其他功能

• 便捷接入

提供API、DB和插件等多种方式，3步完成接入。

Step1：配置采集信息，包括监控对象分类、采集名称和采集方式等

图14：采集配置

Step2：自动校验，生成监控项

图15：生成监控项

Step3：确定图表需要接入的菜单名称，同时完成启用告警、告警通知组等全局配置

图16：全局配置

• 可视化编辑

图表编辑页面，可同时完成图表命名、监控项选择、添加上周曲线、添加基线、修改颜色和编辑告警规则等典型场景下的常用操作

图17：可视化编辑

• 运维大屏

梳理各类运维数据，投放到大屏上进行综合展示

图18：运维大屏

• 自动语音通知

对于告警通知，我们在邮件通知的基础上增加了电话通知功能。在告警发生后，调用“语音机器人”模块向系统负责人手机发起呼叫，通过文本转语音模块将告警内容自动转化成语音及时通知应用负责人。运维人员在听取告警内容后，如暂时无需处理或暂时无需关注，可通过按键进行“屏蔽”或“误告”等操作，避免系统一直告警。

告警通知采用自动升级机制，如三次系统负责人不接听电话，自动升级至其主管，如主管不接电话，自动升级至更高级别管理人员。（升级机制可通过参数配置）

十、后续规划

Horus系统投入生产后，接入的监控项type已达17种，不同的业务类型引出了更多的问题和需求。后续我们会继续通过大数据分析、AI等人工智能技术不断优化监控平台,并在用户界面提供更多便捷、个性化的操作体验和展示效果。当然从传统业务监控到全面自动化业务监控必将是一个持久的过程。

十一、总结

将新监控系统命名为Horus，寓意该系统能够像古埃及神话中的Horus神一样，拥有敏锐的鹰眼，及时准确地发现业务数据上的异常。Horus系统也是我们从传统业务监控转向自动化业务监控的一款突破性产品，针对高度复杂业务实现面向用户体验、面向业务可用性的实时监测和自动告警，让业务监控更加简洁、自动和高效。

推荐阅读：