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

作者简介

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

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

携程作为中国最大的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系统也是我们从传统业务监控转向自动化业务监控的一款突破性产品,针对高度复杂业务实现面向用户体验、面向业务可用性的实时监测和自动告警,让业务监控更加简洁、自动和高效。

原文发布于微信公众号 - 携程技术中心(ctriptech)

原文发表时间:2017-11-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序人生 阅读快乐

Linux性能优化大师

性能调优有时被称为“黑色艺术”,因为有时有效地调整一个系统,要求具有更深层次的知识,且需要了解一个系统的硬件和软件组成,以及系统之间的相互作用。性能优化是针对特...

1741
来自专栏企鹅号快讯

从15000个Python开源项目中精选TOP30,GitHub平均star为3707,赶紧收藏!

参与 | SuiSui 继推出 2017年机器学习开源项目Top 30榜单 后,Mybridge AI又推出了一个Python开源项目Top 30榜单,包括开源...

2469
来自专栏服务端技术杂谈

程序员工作久了基础更重要

工作一段时间会遇到一个瓶颈期,会考虑未来1到2年的发展和方向问题,之前的方式是通过不停的学习新的框架或者解决方案来调整。 比如写服务端代码期间会去学习TDD,D...

30810
来自专栏BestSDK

Hexagon DSP 发布SDK 3.3.2,打造全新神经网络库

将推理、场景分类、图像处理和视频回放增强之类的工作负载放到边缘设备(如智能手机)的CPU和GPU进行处理,会耗尽运行周期并缩短电池使用寿命。DSP编程越方便,您...

6096
来自专栏架构师之旅

百分点推荐引擎——从需求到架构

需求 当下,个性化时代的潮流势不可挡,业界普遍意识到了推荐是网站的一项基本服务。但是,人们对推荐该如何来做,也就是推荐技术本身,还不甚了解。我们经常会遇到这样的...

2577
来自专栏机器人网

工业机器人典型控制系统及结构

工业机器人由主体、驱动系统和控制系统三个基本部分组成。 主体即机座和执行机构,包括臂部、腕部和手部,有的机器人还有行走机构。大多数工业机器人有3~6个运动自由度...

3825
来自专栏Dawnzhang的开发者手册

软件测试学习笔记-概念篇(一)

  每个系统的成型,上线都离不开测试,这段时间陆陆续续的学习测试,在这里总结一番;作为学习交流之用;

1602
来自专栏SDNLAB

领英(LinkedIn)的数据中心设计原则

运营大规模、快速增长的网络需要在如何规划、部署和运营基础设施方面进行变革,随着LinkedIn不断扩张数据中心网络,很明确的是LinkedIn不仅需要尽快地提供...

36412
来自专栏IT大咖说

新一代CMDB模型构建指南

摘要 今天我为大家带来的分享主题是新一代CMDB模型的构建指南,主要分为四大部分。 困境:当前CMDB模型面临的普遍困境 很多CMDB建设前期做得风风火火,而后...

5805
来自专栏闰土大叔

vue菜鸟从业记:没准备好的面试,那叫尬聊

最近我的朋友王小闰参加了一场面试,在他填写简历表的时候,排在他前面的应聘者正在旁边邻桌接受来自面试官的检验。

1483

扫码关注云+社区

领取腾讯云代金券