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

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

第三层就是客户端接入层，也是我们项目的实施的重点，主要讲一下三种客户端注册登录方式：
双中心连接
轮询技术
负载均衡

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

下面讲一下座席接入端异地双活的必要性，携程总共有一万多的座席，如果一地系统出现重大故障，业务影响非常大。我们在这方面有很多的经验教训。在2014年，我们运维同事去机房进行巡检，结果由于工作机电源线路短路，又正好触发了电源的设计中一个bug，导致二级开关跳闸，当时我们整个呼叫中心一个大的部门业务全部垮掉了。
虽然我们快速把电源恢复起来，但是有些系统恢复不了，经过排查，发现是一些设备由于异常断电而损坏，导致我们花了很长时间处理这个问题。故障时，系统所在地我们有大量的座席，他们没法进行工作，而在另外一地系统即使我们把当地所有的人员加进去都没法解决人员不足这个问题。
后续把故障的硬件设备排除后，系统恢复，但我们花了将近两个小时，这个业务影响很大，对我们的触动也特别大，如果那个时候座席异地双活能实现，直接登录到异地系统，这个业务影响就会避免掉。
第二个就是业务需求，其实所有的业务需求类似于我们的计划内的系统的一个调整，这方面我们也有一个真实的故事，也是在去年夏天的时候，台风当时特别大，全市学校都停课。

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

BPO网版权及免责声明

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

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