携程：上万坐席呼叫中心异地双活架构及系统设计-巨人网络通讯

携程：上万坐席呼叫中心异地双活架构及系统设计

作者简介：

沈强

携程旅行网通信技术中心高级经理

拥有十几年的呼叫中心系统建设和运维管理经验，经历了携程呼叫中心系统架构的多次转型设计，使之从单一系统逐步演进到异地冗灾、异地双活，从单品牌到多平台的融合架构设计。目前负责携程上万座席呼叫中心的产品管理和架构设计工作。

序言

之前，我先拜读了《Google SRE》这本书的几个章节，我对这些章节中的内容非常认同，特别是基于自动化运维以及故障响应时间的阐述，感同身受。

今天我讲的这个技术实现就是一个非常接地气的案例，很好了诠释了 Google SRE 的理念，下面我会结合携程实际的技术实现方案，进行详细的讲解。

今天演讲分为三块内容：

•首先，介绍一下携程呼叫中心系统的整体架构，因为携程主要是以呼叫中心起家，当时呼叫中心占整个业务订单量70% 以上，因此呼叫中心在我们的业务里面，起到非常重要作用。

•其次，讲解一下携程呼叫中心异地双活的架构，整个过程中会涉及到各个层面的双活架构设计。

•最后，讲解一下座席介入端的异地双活的系统设计。

一、呼叫中心在携程

就像刚才举手的同学不是特别多，大家对呼叫中心这个系统还不是特别了解，因此我先简单介绍一下呼叫中心的基本的架构，由于各个厂家或者说各个公司对于呼叫中心的设计不一样，可能会有一些架构不一样，因此此次基本上以携程的基本架构作为一个模板进行的说明。

对于呼叫中心系统，主要一个系统就是 PBX 系统，这个 PBX ，类似于运营商的语音交换机，只是用于企业端，功能比较简单一点，主要实现语音媒体的处理和呼叫排队。

第二个系统就是 CTI 系统，就是电话和电脑的集成，等于是我们在电脑和电话之间建立的一个中间件，还包括 IVR ，录音等系统，当然有些平台这些系统会从 CTI 中独立出来。

最后一点就是 CRM 系统，当然各个企业业务定义不同，携程的 CRM 是一个订单的业务系统，包括酒店、机票、度假等等。可能在运营商，他们更多是一个客服系统，这里面会有业务差别，但从整体架构上面来说其实都是相似的，以下是架构图。

在这个架构图中，描述了 PBX，CTI 和 CRM 的组网结构和关系图，另外我们增加了远程座席和在家办公，上海的成本越来越高，很多的座席希望回家乡上班，但是没有一个好的工作或者是一个相对合适的平台。对于在家办公而言，大家花在交通上的成本很高，希望能在家办公，这也是借鉴从美国引进的一些成熟理念，因此我们新增这两种座席办公的途径。

前面介绍了一些呼叫中心的架构，下面讲解一下携程呼叫中心的一些高可用架构相关大纪事。

携程呼叫中心成立以来，总共经历了三次大的调整，第一次是2007年公司大楼搬迁，呼叫中心系统也要搬迁到新大楼，由于当时系统硬件的设计限制和成本考虑，无法做到无缝搬迁，所以搬迁过程中我们整个呼叫中心业务中断了两个小时。这两个小时中断从现在来说可能是不可想象的，说明当时我们的高可用架构还不够完善。

第二次调整是2010年，我们在南通建了一个新的大楼，同时我们也按新架构重构了呼叫中心系统，从平台上实现了异地双活设计，并且将中继路由以及其他业务进行模块化的分拆，各模块之间全部通过SIP协议进行连接，每个模块之间再采用异地双活的设计，因此各个模块可以在异地灵活组合搭配，充分体现系统可靠性。

最后当系统正式启用的后，两地系统同时工作，对业务没有任何影响，系统无缝衔接。

最后一次是今年，我们在上半年对座席客户端进行了一个改造，因为原先我们在做设计的时候，平台这边我们都已经做到了全部的异地双活，但是在客户端由于历史的原因，我们的一些分机全部是模拟的线路，模拟的线路如果想异地切换的话，技术上没法实现。

因此我们从2014年进行统一登录平台的建设，经历一年多的一些优化和改进，我们在今年上半年就实现了一个座席端的异地双活的设计。

二、呼叫中心异地双活架构简介

刚才对携程的呼叫中心系统做了一个简短的介绍，下面把呼叫中心异地双活的架构设计做一下简单的描述。

异地双活衡量标准，我们从自己的业务的角度定了两个级别的标准：

•区别异地灾备

•故障恢复时间

当出现故障时，我们启用备份，但经常出现备份无法正常工作，或者不能完全接替主应用。而双活我们是两个系统实时存活的，切换时，只是负载增加，其他的功能模块都一样。对于故障恢复时间，我们希望故障恢复快速，只有快速恢复，对用户几乎透明或无感知，才是真正的双活。

我们根据这两个概念定义了一个我们的架构分层或者说这个技术实现的一个标准。

针对这两个标准我们将系统分成三个层面进行设计实现：

•公网接入层

•应用层

•座席接入层

公网接入层和运营商线路相关，双活设计原理很简单，基本上都是在运营商端配置，主要涉及以下内容：

•话务中继两地接入

•智能网平台(可配置三个路由)

•按百分比/主叫号码区域

•SIP 语音中继

只是对运营商，如果不提出你的一些想法和设计要求的话，他也不一定帮你去做，因为这样对他的成本会高很多。我们当时在上海和南通两地分别找了电信和联通，总共四家运营商。对于运营商我们要求上海和南通分别都有中继接入的，然后通过运营商的智能网平台将我们的话务进行分配。

运营商智能网平台有多个话务分流的策略，可以根据你的需求进行话务的分配：按百分比进行分配，或按照主叫号码归属的区域进行分配。这样企业可以根据自己的业务需求，规划自己的话务分配逻辑设计。

我们考虑到话务费用成本问题，采用了根据主机号码所处的区域进行分布的策略。因为我们不希望上海的话务分配到南通，产生长途费用。

运营商还有一个先进的技术方案，就是SIP中继接入。这个概念和方案其实很早就提出来了，只是运营商考虑技术风险，当时一直在运营商内部使用，没有对外推广。我们和运营商进行一些技术沟通，最终尝试接入SIP中继，在两个机房分别接入了一个SIP 中继群，负载均衡，光纤接入。

达到的效果就是线路快速扩容，无需重新施工，只需后台参数配置即可。线路主备快速切换，无需事先部署备份额外线路资源。如传统的中继接进来，我的话务要切到另外一边去，这个时候如果没有足够的线路资源的话，而话务量还是原先那么多，那就会存在电话呼损。

而如果事先预留资源的话，一直放着没用的，成本比较高。采用光线接入，直接就是百兆接入，资源充足，先期投入也就是新增几根网线，切换也非常方便，而且我们这边部署简单，无须中继网关和中继线路，只须网络交换机进行数据接入即可。这个方案我们当初跟运营商谈判时，估计当时也是第一家运营商正式开通SIP中继的公司。

总体而言，公网接入层除了SIP中继外，其他在我们企业端的设备部署也比较简单，就是两地部署，所有的线路均衡分配到不同的设备上，预防单设备故障。并且都上联到我们南通上海核心交换，由核心系统进行异地调度。

第二层是应用层，其实原理和互联网WEB应用都是相似的，细节就不再展开，唯一需要说明的就是我们的应用层跟我们的核心交换层，他是一个静态配置，就是我们原先就制订好了一个路由策略，本地访问，优先访问本地集群，如果出现故障，可以通过路由到异地的集群去，配置非常简单。

我们的四个核心也是full mapping设计，这四套我们分别部署在两地，两地都是双活的架构，任何一地出现问题，都不影响所有的业务。这个设计我们和Google SRE的介绍的理念一致，并且我们每年都会进行冗灾演练，把核心关掉，或者把集群关掉，进行观察验证。

第三层就是客户端接入层，也是我们项目的实施的重点，主要讲一下三种客户端注册登录方式：

•双中心连接

•轮询技术

•负载均衡

因为呼叫中心他有一个语音线路，一个话机，我们设计的双中心连接的方法，就是我的话机同时接入到两个中心里面去，同时有效，按需切换。另外一个就是轮询技术，访问应用服务器，主系统有问题可以自动访问第二个。最后一个就是负载均衡，这个就不多说了，WEB应用访问。这三个技术其实我们在整个客户端都采用了。

座席端接入异地双活的必要性

下面讲一下座席接入端异地双活的必要性，携程总共有一万多的座席，如果一地系统出现重大故障，业务影响非常大。我们在这方面有很多的经验教训。在2014年，我们运维同事去机房进行巡检，结果由于工作机电源线路短路，又正好触发了电源的设计中一个bug，导致二级开关跳闸，当时我们整个呼叫中心一个大的部门业务全部垮掉了。

虽然我们快速把电源恢复起来，但是有些系统恢复不了，经过排查，发现是一些设备由于异常断电而损坏，导致我们花了很长时间处理这个问题。故障时，系统所在地我们有大量的座席，他们没法进行工作，而在另外一地系统即使我们把当地所有的人员加进去都没法解决人员不足这个问题。

后续把故障的硬件设备排除后，系统恢复，但我们花了将近两个小时，这个业务影响很大，对我们的触动也特别大，如果那个时候座席异地双活能实现，直接登录到异地系统，这个业务影响就会避免掉。

第二个就是业务需求，其实所有的业务需求类似于我们的计划内的系统的一个调整，这方面我们也有一个真实的故事，也是在去年夏天的时候，台风当时特别大，全市学校都停课。

我们大楼的物业说，这个台风可能会造成我们机房这边的漏水，所以决定在台风来的时候，把这个机房全部停电。我们当时所有的设备都在这个机房，我们这边也很头疼，经过协商以后，物业说还是不行，风险太大。

我们这边不得不安排了技术人员去通宵加班，在异地系统新增配置全部的数据，计划让我们的上海的座席登到异地系统上，花了一个通宵才把数据配好。

第二天，由于台风没有预期到来，因此没有实施这个方案，我们配置数据效果也没有验证过是否可靠，而我们花了大量的时间做这些应急处理，如果说当时系统能够登录到异地的话，这些工作我们都可以省下来，而且系统的可靠性也更高。

经历的这几个点，是我们深有感触的一些痛点，因此我们花了很多的精力整改这一套系统，做到客户端的异地双活接入。

三、呼叫中心座席介入异地双活

座席端异地接入前提条件：

•话务多地接入，可全局分配

•座席一地签入，可接全局话务

•话机IP化

话务多地接入，可全局分配，如果不能全局分配的话，座席异地登录后，就不能接听全局的电话。另外座席一地签入以后，可以接全局的话务，这里有一个话务分配的策略，这样才能保证我们座席在任意地方签入，都能接听我们所有的话务。

当然最重要的一点就是IP话机，我们原先没这么做就是因为模拟话机无法实现两地注册，而IP话机可以预先注册登录，并且可以实现自动化。这是我们三个前提条件。

客户端异地双活难点：

•话机注册问题

•客户端登录问题

•资源配置问题

话机注册问题，以前的话机是模拟线路，只能对应一个分机，并注册到一个后台系统，物理线路和系统一一对应，而双活则必须同时能注册到至少两个平台上，且能自动切换，以前的系统不支持。

座席登录问题，座席是一个点对点，一个长连接的状态，座席通过一个操作员号登录CTI，就和PBX中的一个话机进行绑定，因此登录后就是一个常态的固定绑定关系。

如果切换系统，必须要重新更换一个新系统的操作员号进行登录，分机也要重新注册到新系统，这个必须人为去进行操作，业务、报表等等都要受到影响。且以前出现问题是人工去操作，一万多座席进行调整，难度还是很大，而且会出现很多的偏差。

因此如果没有一个自动化的措施，而是座席人工操作，根本不知道配置什么数据，会一片混乱，这是一个痛点。所以座席登录我们也是希望做到自动识别，自动完成，不需要人工干预。这也是我们的难点之一。

第三点是资源配置的问题，我在A城市访问B城市，原先的资源都是各自配置各自，各自登录，相互独立，现在我们需要座席异地登录时能无缝，则需实现两地配置自动互通，而不是再去人工干预。

统一登录

如果能解决以上这几个问题，则我们的就能实现座席接入异地双活了。以下我们来讲一下我们针对这三个问题的解决过程。

话机注册问题，以前是模拟线路，无法实现，此次改造我们首先更换成IP话机。而且现在话机厂商很多，只要选定厂商，能配置双线路（A线、B线），你配置好以后，只要A线和B线双活，配合客户端软件的联动机制和心跳检测机制，由客户端自由选择，就可实现话机绑定关系。现在有很多厂家支持这类配置，通过招标选型基本上不是问题。

座席登录的问题，座席怎么去自动识别和登录，这也是我们花了很多的时间和精力去处理的一个业务逻辑。统一登录，顾名思义，座席不管在哪里，用唯一的帐号就可以登录。

•ITDB

•IP话机MAC与分机号映射

•座席虚拟ID（内部资源）

•座席工号与域帐号关系表

•座席工号动态使用（资源池）

ITDB，我们的实现过程，首先我们自己IT部门建立的一个ITDB资源库，就是对我们管理IT设备进行自动关联，包括我们的话机、PC机信息、座位号等，都是通过我们的系统可自动实时识别，自动更新。

如一个话机接入网络以后，可以通过网络接口识别到话机MAC地址，同时可以识别PC的MAC地址（话机和PC共用一个网口），并进行绑定关联，再根据ITDB中配置的话机MAC地址对应的分机号码，PC的MAC地址对应的机器名，就可以把PC的机器名和话机号码进行关联，座席客户端登录时通过获取PC机器名的同时获取到话机分机号码。

座席虚拟ID，前面讲过我们的座席要用操作员号要登录到CTI中去，要正常登录的话首先要配置好相关的数据，包括PBX中的数据。如果你想换一套呼叫中心的系统，这个数据要重配，包括CTI 和PBX中的数据。

因此如果要实现在两套呼叫中心都能登录，则必须两套都要事先配置好数据，这样会造成很多的冗余数据，人员信息也不统一，容易造成数据的偏差。因此我们建立的一个虚拟ID，这个ID跟CTI和PBX系统没有直接关系，只是中间过渡衔接的模式，但和座席人员是唯一绑定。

这样把整个CTI的操作员号资源变成一个动态的资源池，不再和座席人员固定，根据座席登录的实时需要再去动态获取。获取后可以保留一定时间，类似DHCP获取IP地址，到了设定时间，自动的释放这个资源。这样我们用虚拟ID把座席人员和呼叫中心系统资源解绑，使座席人员和呼叫中心系统无强耦合关系。

后续我们将虚拟ID和域帐号进行绑定，让后根据HR系统中域帐号对应员工信息确定员工业务属性，确定他归属哪个技能组，自此虚拟ID获取了座席业务属性，并建立了域帐号和操作员工号（技能组）的逻辑关系。

座席通过域帐号登录时，将业务属性告知给CTI，CTI 根据定义好的逻辑分配一个对应技能组的动态操作员工号给域帐号进行关联，并用分配的操作员工号登录CTI ，同时结合ITDB获取的信息关联到话机，完成了自动登录。

通过统一登录将座席员工和CTI/PBX资源进行了分离和动态分配。当系统出现故障时，可按照业务逻辑到另外的系统并重新获取一个动态操作员号并重新登录，实现了容灾处理。

资源配置的问题：

•在双中心的统一登录平台中配置全部座席虚拟ID

•双中心IP话机的MAC信息共享

•分机号码各自独立

对异地双活整个逻辑了解以后，我们讲一下心跳监控联动策略：

•Client-CTI-PBX-IP话机联动

•二次确认，预防误判

•故障确认，异地登录

•全程自动，用户透明

这个机制其实就是我们这边设置的座席客户端，CTI，PBX以及IP话机实时的联动，当任何一个设备出现问题，通过心跳机制，互相之间检测到这个故障，并发出一个消息确认，以便进行整个呼叫的调整。

另外在检测的时候，担心可能网络抖动或者是意外情况，做二次确认，故障确认以后，我们便可以异地登录，而整个过程对座席来说基本无感知的，整个是过程全程自动，用户透明。

我这里整理了一张内部统一登录逻辑图

这个逻辑图，图中表述了座席登录的三种状态，第一种状态就是在已登录状态（绿色这一部分），在已登录的时候，检测到话机出现故障，会发起一个请求，如果说第二次请求是OK，保持状态不变，如果发现有问题，直接触发统一登录请求登录，如果说异地请求登录OK的话，会向异地发消息登录成功的。

如果异地登录的时候发现还是失败，两地同时失败，那基本上你话机本身的问题。如果是话机本身的问题，基本上会认为是一个单点故障，问题不是很大。

另外两种状态就是在登录过程中发现问题，如果是CTI出现问题，则会直接向异地进行登录请求，如果是统一登录平台出现了问题，我们会进行二次确认，如果二次确认登录不成功的话，则会向异地再发起一个请求，进行异地登录。

技术特点：

•支持故障情况下在线座席自动双活切换

•支持按系统、按地域、按座席技能组等不同维护进行计划内的手工切换

•支持1000+ 并发在线座席异地双活自动切换

演练效果：

我们当时做了一个演练，这个演练也比较符合Google的一个理念，定期演练并根据演练结果进行修正。在做演练过程中，你会发现计划内目标是否完成的，是否有一些计划外的事情。而在实际演练中也确实发现跟我们计划稍微有点出入，具体数据如下：

后期我们针对演练发现的问题，进行了修复和调整，并在测试环境进行压测验证，最终实现1000+座席自动切换在2分钟内全部完成。

未来

未来的方向，这也是我们公司目前正在做的两个方向

•客户端全软件化，取消硬件电话限制

•客户端移动化，任意地点可接入

客户端全软件化，其实现在的很多的都已经全软化的，全部在软件上实现，这个从技术上我们在尝试，而且也做demo，之所以我们这边并没有全部推推广，也是跟我们的公司的战略有关。

现在我们客户端几乎是全部是虚拟云桌面，运行在后台的虚机上面，如果我们的语音功能在虚机上运行的话，我的后台配置要求高，成本也会比较高。当然如果运行在普通PC机上，我们是可以采用全软化的方式，这个就不会存在我们前面所说的一些瓶颈限定。

还有就是客户端移动化，我们现在也做了一些尝试，我们自己开发了一个APP，座席可在任意地点接入，就可以登录到系统里面去。只是因业务发展的需求做了一些业务的分类，目前只用于外呼。对于呼入，我们现在还没有去应用，呼入会涉及到一些话务分配的问题，分配到哪个座席，我们要解决他的状态，这些是一个难点，所以我们现在还没去规划。

但对于外呼业务的话，由于主动权在我们手里，也无严格的分配话务要求，任何一地点都可以接入，这个可以尝试，也是在未来的发展方向，当然可能其他厂商或者其他的公司也有一些不同的接入方式，大家可以讨论一下。

我今天主要是讲一些针对我们携程自身接地气的一些技术实现，也是跟业务需求做的一些开发和尝试。我今天就讲这么多，有什么问题大家可以现场问一下。

四、提问环节

Q1：

我问一下像呼叫中心这个全软化方向，现在你们有没有实际的案例或者实际的可用的解决方案是全软件化的？

沈强：这个是有的，我刚才只是讲了一个平台，其实我们公司从14年开始就是多平台进行接入的。现在我们至少有三个平台，有两个平台基于的硬件，基于语音设备的，第三个平台全是我们自研的，现在也是基于开源的软件做了一些开发，连语音交换机没有了，基本上实现了全软的概念。

我们提出了客户端也是全软件，这个刚才也讲过，我们已经实现了，只是我们没有大规模推广，毕竟我们对于客户端全软化还是有一些疑惑。如果用上去以后PC机出了问题，语音也会受到影响，语音在PC机上处理会不会对PC性能出现影响，导致业务处理受影响？我们是结合这两点考虑，现在还是做一些线上测试，但是产品的话我们都已经全部开发完了。

Q2：

第一个我想问一下就是关于贵公司现在SIP中继的使用量？

沈强：比例还是比少，因为这也是受制于运营商的一些限定，举个例子，其实刚开始我们找上海运营商，但是他们不开放。我们也是找其他的地市的运营商，他们也愿意跟我们合作，因此我们当时尝试应该是10%左右。

Q3：

我们之前的了解，就是SIP应用可能，第三方的安全性的话可能有差异，我不知道实际应用当中会不会有这影响？

沈强：是跟运营商协商过，开始也非常担心这个问题，我们当时采购语音的安全网关设备进行保护。而且我们和运营商是专线连接，用的是内网地址，另外当时我们讨论下，我们安全部认为运营商是可信任的一个点，因此继续推行这么一个策略。

Q4：

我想问一下，就是说携程这么大规模的话，就是电话外呼有没有被运营商封的可能性，如果被封的话怎么处理，针对外呼这块？

沈强：确实，有这个可能性，虽然我们外呼的时候对所有的号码进行了备案，但有些用户在APP中标记为骚扰，针对这个问题，一方面我们跟运营商积极协商，让他不要封，把号码加入到白名单里面去。

另外一个如果检测到这个号码的呼叫成功率突然降低，或者有问题的话，我们马上进行外呼号码的切换，这个也是在运营商的号段里面的。如果出现一个号码被拦截，我们可能换一个运营商进行一个切换，采用一个人工和自动相结合的方法。

Q5：

这样的话，切换会不会影响用户的接通率？