案例研究：携程的呼叫中心坐席管理

携程呼叫中心成立以来，总共经历了三次大的调整，第一次是2007年公司大楼搬迁，呼叫中心系统也要搬迁到新大楼，由于当时系统硬件的设计限制和成本考虑，无法做到无缝搬迁，所以搬迁过程中我们整个呼叫中心业务中断了两个小时。这两个小时中断从现在来说可能是不可想象的，说明当时我们的高可用架构还不够完善。
第二次调整是2010年，我们在南通建了一个新的大楼，同时我们也按新架构重构了呼叫中心系统，从平台上实现了异地双活设计，并且将中继路由以及其他业务进行模块化的分拆，各模块之间全部通过SIP协议进行连接，每个模块之间再采用异地双活的设计，因此各个模块可以在异地灵活组合搭配，充分体现系统可靠性。
最后当系统正式启用的后，两地系统同时工作，对业务没有任何影响，系统无缝衔接。
最后一次是今年，我们在上半年对座席客户端进行了一个改造，因为原先我们在做设计的时候，平台这边我们都已经做到了全部的异地双活，但是在客户端由于历史的原因，我们的一些分机全部是模拟的线路，模拟的线路如果想异地切换的话，技术上没法实现。
因此我们从2014年进行统一登录平台的建设，经历一年多的一些优化和改进，我们在今年上半年就实现了一个座席端的异地双活的设计。
二、呼叫中心异地双活架构简介
刚才对携程的呼叫中心系统做了一个简短的介绍，下面把呼叫中心异地双活的架构设计做一下简单的描述。
异地双活衡量标准，我们从自己的业务的角度定了两个级别的标准：
区别异地灾备
故障恢复时间
当出现故障时，我们启用备份，但经常出现备份无法正常工作，或者不能完全接替主应用。而双活我们是两个系统实时存活的，切换时，只是负载增加，其他的功能模块都一样。对于故障恢复时间，我们希望故障恢复快速，只有快速恢复，对用户几乎透明或无感知，才是真正的双活。
我们根据这两个概念定义了一个我们的架构分层或者说这个技术实现的一个标准。
针对这两个标准我们将系统分成三个层面进行设计实现：
公网接入层
应用层
座席接入层

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

 2/10   首页 上一页 1 2 3 4 5 6 下一页 尾页

BPO网版权及免责声明

1、凡本网注明：“BPO网”或者“原创”的所有作品，版权均属于BPO网所有，其他媒体、网站或个人转载使用时必须注明：“文章来源：BPO网”。违反上述声明者，本网将追究其法律责任。

2、凡本网注明“来源：XXX（非BPO网）”的作品，均转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其产生的任何结果负责。