随着数字化和智能化的飞速发展，传统的呼叫中心逐渐暴露出效率低、人工成本比较高及客户体验受限等诸多问题。随着人工智能技术的蓬勃兴起，智能语音呼叫系统应运而生，为企业的客户服务、营销推广及业务运营等多方面带来了前所未有的机遇与变革。智能语音技术的应用，使得呼叫中心能够实现自动化、智能化的客户服务^[1]，这对于提升企业的竞争力具有重要意义。各铁路局集团公司建设语音呼叫系统时会遇到系统规划容量和实际使用需求难以匹配的问题^[2]。突发性事件的处置与日常工作不同，如果规划容量基本匹配了突发性事件需求，在日常状态情况下，就会出现容量大量闲置，造成浪费；如果只满足日常工作使用需求，当突发性事件发生时，就会不堪重负难以应付^[3]。

中国铁路广州局集团有限公司（简称：广州局）在建设智能应急指挥系统的实践中，基于呼叫通道的独占排他性，区分突发事件的优先级，考察和适应业务敏感性，采用云计算技术，设计了高弹性智能语音呼叫系统。

1   系统架构

高弹性智能语音呼叫系统的架构如图1所示^[4]。

图  1  高弹性智能语音呼叫系统架构

下载: 全尺寸图片 幻灯片

1.1   服务层

提供后台管理相关的 Web 网站及对外服务接口。

1.2   中间层

以组件和接口方式提供了语音转换、交互式语音应答、语音呼叫、JCWI 业务管理、后台管理等方面服务支撑。

1.3   基础设施层

利用操作系统、数据库等软硬件资源，构建系统运行环境。

1.4   云架构层

容器平台KubeSphere具有容器编排与管理、资源调度与优化、应用生命周期管理、集群管理与监控、集成与扩展等作用。

1.5   云互联层

通过 Kurator 实现多云管理，达成对多个云环境的统一管理和协调，实现资源整合与统一视图、标准化操作与流程、资源调配与优化、应用部署与迁移、监控与运营维护（简称：运维）、安全管理与策略执行、成本管理与优化等方面管理。

2   系统功能

高弹性智能语音呼叫系统功能^[5]，如图2所示。

图  2  高弹性智能语音呼叫系统功能架构

下载: 全尺寸图片 幻灯片

2.1   语音呼叫

接收上层应用的呼叫请求，通过运营商的线路完成外呼，将呼叫的结果通知上层应用，并记录整个过程的相关数据。

（1）业务接口：为内部业务系统提供了丰富的接口，业务使用者通过HTTP接口提交外拨任务，指定不同的业务号码，可以分级别插队等。

（2）JUSTTTS语音转换：把文字形式的通知内容转换成语音，供后期下载或复查。

（3）智能路由：实现多队列任务同时提交，并行处理；实现外呼线路资源按组动态分配，使不同组别的呼叫任务都能得到均衡处理；实现任务优先级管理，允许高优先级任务插队执行并预留资源。

（4）JUSTIVR交互式语音应答：自动实现用户与系统的语音交互，获取用户对通知内容的反馈，可以让用户主动呼入自动获取相关信息^[6]。

（5）底层硬件接口：整合匹配多家通信厂家的语音通信设备。

（6）云化扩展互联：结合云技术，实现呼叫资源云共享。

为了解决相互之间服务的积极性、公平性问题，规划设计了计费模块，支持相互之间的通信费用、服务费用清算。互联的多方，通过对外提供服务，赚取收益，弥补自己建设投入和运维成本。

2.2   后台管理

（1）系统管理：实现参数配置功能，提供高弹性智能语音呼叫系统参数配置功能界面；对业务使用者账户等信息管理，包括增、删、改、查等操作。

（2）应用管理：提供高弹性智能语音呼叫系统接入的应用维护功能。包括应用授权，可对该系统接入的应用权限进行管理，在应用列表中点击具体的应用进入应用授权界面；应用优先级管理，对该系统接入的应用优先级进行管理；应用资源分配，对应用的可使用的线路资源进行分配。

（3）计费管理：定义高弹性智能语音呼叫系统的计费规则，提供应用费用明细查询及结算功能。

（4）统计分析：提供应用的外呼统计数据和应用呼叫明细查询功能等。

（5）系统监控：实时展示系统中各种软硬件状态，包括中继状态、呼叫队列、子系统程序状态等。

3   系统实现

3.1   语音呼叫组件负载均衡

语音呼叫软/硬件组件负载均衡结构，如图3所示。其中，应用服务器和呼叫服务器都采用双路结构，由高性能反向代理软件Nginx在底层扮演负载均衡架构的核心角色。

图  3  语音呼叫组件负载均衡结构

下载: 全尺寸图片 幻灯片

3.2   云计算技术

采用云计算架构和技术，把各铁路局集团公司本地的呼叫系统联接起来。云计算技术保证高弹性智能语音呼叫系统能力的高弹性，从而体现其高可用，分两个层面：本地呼叫系统构建采用kubernetes应用服务器集群，各种网络计算资源通过负载均衡和故障自动转移构建出本地云；各铁路局集团公司本地云之间互联，采用Kurator作为集群管理，使集群组扩充方便，更多铁路局集团公司新建的呼叫本地云加入这个集群组以后，分享出自己的资源，并同步获得组内其他云的共享资源。多系统间云化扩展互联结构如图4所示。

图  4  多系统间云化扩展互联结构

下载: 全尺寸图片 幻灯片

3.3   用户分组和优先插队

采用用户分组技术和优先插队技术，可保证单位和组织机构优先权，而对突发事件敏感度稍低的部分用户稍后处理，并引导用户的自主适应和配合支持行为，从而有效地缓解用户在等待时的焦灼不适感^[7]。

3.3.1   用户分组

呼叫通道在接到呼叫任务开始运作后，不能强行中断，必须等到呼叫完成，才能再次利用。因为独占排他性，在使用呼叫资源时，对紧迫程度不同的任务要标识不同优先级。仍在待处理队列未送入呼叫通道且优先级高的任务，可以中途插队排在优先级低的任务前面，抢先获得空闲出来的呼叫资源，优先获得服务。一般而言，事件带来的潜在受损越严重，影响范围越大，它的优先级就越高，默认把集团一级响应事件的优先级定为最高级，其次是集团二级、三级响应，其后是站段级别的事件。

考虑到突发事件的偶发性，一般情况下认为，某地域发生了较大规模的突发事件，其他地方不会同时发生；同时、同地并发多个较大影响的突发事件的概率很低。因此，可基于铁路局集团公司管辖范围，在不同地域投入一定资源构建各个铁路局集团公司的本地语音呼叫系统，承担各自的一些日常业务，占用一部分资源；同时让各铁路局集团公司的语音呼叫系统互联，把日常空闲的资源共享起来，相互调剂使用。

在应急呼叫中，假设通知的用户涉及工务、电务、供电、机务、车务等5个专业的基层站段，如果按照常见的专业、站段、人员简单排序，如图5所示。

图  5  按专业简单排序示意

下载: 全尺寸图片 幻灯片

按照图5的顺序，工务部门的人员最先收到通知，车务部门最后收到通知，不同专业之间接收的通知不同步，使工作无法协同开展。

如果分开工务、电务、供电、机务、车务等5个组，在每一个专业组中又有不同站段，铁路局集团公司指挥中心为A级，对呼叫人员按照收到通知的时间敏感度区分3个层级：调度值班室（站段应急指挥中心）为B级、站段领导为C级、出事地点附近的车间和工区管理人员为D级，然后根据敏感度层级、专业、站段来统一排序构建一个统一的队列，如图6所示。

图  6  分组分敏感层级队列原理

下载: 全尺寸图片 幻灯片

按照上述统一队列发起呼叫，保证各专业、各站段有序收到通知，在资源紧张时均衡分担，避免出现严重失衡、先后差距太大，影响后续统一调度指挥。

根据应急事件处置工作和专业的相关程度，按照专业相关度、敏感层级来构建一个待呼叫组织的优先级代码矩阵，如表1所示。

表  1  用户分组优先级代码

层级	专业
	工务1	电务2	供电3	机车4	车务5
铁路局集团公司指挥层级A	A1	A2	A3	A4	A5
站段敏感层级B	B1	B2	B3	B4	B5
站段敏感层级C	C1	C2	C3	C4	C5
站段敏感层级D	D1	D2	D3	D4	D5

下载: 导出CSV 

| 显示表格

在软件设计实现时，对发送给高弹性智能语音呼叫系统的人员队列构建排序规则，把表1中的优先级代码置于排序规则的首要位置。

采用用户分组的方式，优先照顾团体组织，站段最先收到通知的值班室工作人员，对于站段级别应急事件，有自己固定的通知途径，他们会沿着传统路径通知方式，扩大通知范围。

对于全局性的应急演练以及大范围应急响应，在呼叫分组策略上，再引入一个区域变量，保证在资源紧张情况下，各区域的重点优先呼叫对象也能尽早收到通知^[8]。

3.3.2   优先插队

高优先级的呼叫任务允许插队置于低优先级呼叫任务队列前面。同时，主动发送通知给低优先级用户，并在用户界面上实时提示，缓解用户焦灼等待的郁闷，从而改善用户体验。

4   应用场景和效果

高弹性智能语音呼叫系统成功应用在广州局智能应急指挥平台中，通过智能化高效统一的语音呼叫，支撑了应急指挥工作的首要环节，在应急事件发生之初，迅速通知和调集人员。

4.1   本地系统高效语音呼叫

4.1.1   精准找人

应急事件通知的文字内容通过相关设备和本系统在1～3 s内自动转换成语音信息，精准发送给该事件附近或者与之紧密相关的各专业值班人员和主管领导，根据应急响应等级严格控制通知范围，以强提醒的方式通知用户。

4.1.2   信息可追溯

用户除了收到语音呼叫通知以外，还会收到一条对应的文字短信，并能通过回拨呼叫号码，交互式提取最近一条语音播报。赶赴现场的主管人员，打开移动端应用，还能看到该应急事件发生地的定位点，一键导航前往。

4.1.3   区分敏感度

设置多个用于呼叫的主叫号码，来区分呼叫的重要紧急程度及工作范围，分为集团级、调度所级、站段级，有利于用户根据响应等级来选择处理分支，投入对应的支持配合努力，加强业务协调，保证职责到位。

4.1.4   防手机拦截

移动端应用安装后首次启动时，在用户同意的前提下，新建联系人，把呼叫用户的主叫号码内置到手机通讯录里面，避免手机端的防骚扰软件阻挡语音呼叫和短信通知。

4.1.5   实时反馈信息

把用户的接通挂断动作及时间点实时反馈到发通知的用户界面，让发送应急通知的人员即时看到。

4.2   多云互联方便可控

4.2.1   多个系统间互联方便

本系统基于云计算架构建立，扩展起来很方便和简洁。各个铁路局集团公司建立其自己的本地呼叫系统，网络是互联互通的，授权是放开的，就可以直接相连。

4.2.2   保留专用资源

呼叫通道一旦被占用，不可中断。为了避免资源被外铁路局涌来的呼叫全部占用，本铁路局的重要紧急呼叫请求得不到马上响应，可以预留一定数量呼叫线路给本局专用。

4.2.3   可管理性良好

多个系统（多云）之间的统一管理和运维，使用开源的集群管理软件Kurator来承担。

5   结束语

广州局在应急指挥平台建设中，基于调度指挥工作的指令性通知需求，依据高弹性、智能化呼叫的概念、原理和技术，设计并应用了高弹性语音呼叫系统，解决了呼叫系统建设中资源有限投入和支持突发性大规模使用的矛盾，取得了用户满意的效果。