ПроCall-центр. Неваляшка

Как сделать так, чтобы эксплуатация call-центра исключала возможные перерывы в его работе

Работа call-центра предполагает обработку вызовов круглосуточно и непрерывно (24 часа в сутки, 7 дней в неделю, 365 дней в году). Не все платформы call-центра предполагают возможность полного «горячего» резервирования, а платформах его предполагающих бюджет на «горячее» сравним с покупкой второго такого call-центра.

Зарезервируем мощности call-центра даже в тех случаев, когда архитектура call-центра не обеспечивает этого. Хотя такое решение ориентировано на большие call-центры, оно может быть полезно и для небольших решений.

Мы реализовали схему «горячего» резервирования для call-центра, там, где существующая платформа call-центра не предполагала схемы «горячего» резервирования. Общее число операторов – 75, подключение к телефонной сети общего пользования (ТсОП) – Е1 (edss1) в количестве 4 шт от одного оператора связи. Максимальная загрузка линий в ЧНН – не более 90 одновременных звонков в системе (разговор с оператором + ожидание в очереди).

Задача: исключить возможный перерыв в обслуживании телефонных вызовов.

Решение. Мы начали с того, что поняли, что при обработке вызовов, даже в ЧНН, потеря одного потока Е1 неприятна, но не страшна. Разносим потоки Е1 на четыре разных call-центра, установленных независимо. Если «падает» любой из отдельных call-центров, остальные продолжать работать. При этом рабочие места операторов, потеряв связь с текущим сервером call-центра, переключаются в автоматическом режиме к другому серверу. Вся система call-центров продолжает обслуживание телефонных вызовов, понеся потери в один сервер call-центра и один поток Е1. «Падение» любого из отдельных call-центров сопровождается разрывом связи по Е1 потоку, заведенного в этот call-центр. Принимаем, что событие «падение call-центра» и «разрыв связи по Е1 потоку» эквивалентны.

На стороне оператора связи. Оборудование операторов связи позволяет маршрутизировать вызовы на альтернативные направления в случае недоступности основного. То есть, если получена «потеря связи по Е1 потоку», оператор связи перераспределяет эти вызовы на остальные Е1 потоки.

Перекрестная маршрутизация вызовов на Е1 потоках позволила полностью исключить вероятность отказа в обработке вызова при падении любого из call-центров.

Работы на площадке справочной службы. В любой момент времени в любом из call-центров может быть любое, даже нулевое, количество операторов. При этом необходимо обеспечить равномерную звонковую нагрузку на операторов − за одинаковый интервал времени на каждого из операторов, подключенных к любому из call-центров, должно поступать примерно одинаковое количество вызовов. Дополнительно надо обеспечить автоматическое переключение рабочего места оператора к другому call-центру, при «падении» текущего. Необходимо объединить статистику обработки вызовов со всех call-центров, оставив отображение показателей статистики реального времени в каждом call-центре в отдельности.

Мы объединили все call-центры таким образом, что каждый call-центр был связан с остальными другими VoIP каналом, обеспечивающим обработку 30-ти голосовых соединений. Избыточность позволила в случае необходимости «отдать» все 30 вызовов, поступивших по Е1 потоку любому из соседних call-центров.

Следующим этапом была разработка логики обмена вызовами между call-центрами таким образом, чтобы выполнялись требования балансировки нагрузки на операторов справочной службы. Это было сделано так. При поступлении каждого звонка (со стороны Е1 потока) в каждый из call-центров, call-центр вызывает хранимую процедуру во внешней базе данных, передавая туда параметры:

  • номер А (АОН)
  • номер В (набранный номер)
  • количество свободных операторов (Fi), то есть, о количество операторов находящихся в системе и в статусе «готов обслужить вызов»
  • общее количество операторов (Ni), обслуживающих вызовы, то есть, количество операторов, находящихся в системе в любом статусе («готов», «занят», «пост вызывная обработка»), за исключением статуса «перерыв»
  • количество абонентов, находящихся в очереди (Qi)
  • предполагаемом времени ожидания ответа (Ti), в том случае, если вызов будет распределен на этот сервер.

В качестве выходного параметра хранимая процедура возвращает имя сервера, на который необходимо перенаправить вызов. В хранимой процедуре используются следующие константы: интервал времени (P) в течение которого мы считаем информацию, полученную от серверов актуальной. Погрешность (E), при не превышении которой считаем, что нагрузка на операторов одинакова.

Логика принятия решения о том, на какой из серверов направить вызов учитывает мгновенные, актуальные только в данный момент, показатели загруженности операторов (Ri) на каждом сервере. В качестве мгновенного показателя загруженности операторов принимаем следующие величины: а) при наличии очереди – это предполагаемое время ожидания клиента в очереди (Ti) или отношение длины очереди (Qi) к общему количеству операторов в системе (Ni). б) при отсутствии очереди в качестве показателя загруженности операторов служит величина обратная количеству свободных операторов (1/Fi). Если при отсутствии очереди показатель мгновенный загруженности не вызывает подозрений, то вопрос какой из показателей выбрать в случае наличия очереди требовал дополнительно изучения. Опытным путем было выяснено, что для балансировки нагрузки между разными платформами call-центр, наилучшие результаты дает использование отношения длины очереди к общему количеству операторов в системе (Qi/Ni). Причина большего доверия к этому показателю кроется дополнительно еще и в том, что разные платформы call-центров (а в нашем случае были две разные платформы двух производителей) используют свои собственные алгоритмы вычисления предполагаемого времени ожидания в очереди, разные алгоритмы предполагают разную точность этих вычислений и разную дискретизацию значений. В том случае, если механизм балансировки используется для балансировки нагрузки между двумя одинаковыми платформами call-центров использование предполагаемого времени ожидания ответа более оправдано.

Таким образом, для каждого из серверов call-центр вычислялся мгновенный показатель загруженности операторов. При вычислении обрабатываем исключительные ситуации, когда количество свободных операторов равно нулю, когда общее количество операторов равно нулю. Отсекаем показатели загруженности серверов (Ri), поступившие ранее заданного интервала времени (P).

Итоговым этапом принятия решения о том, на какой же из серверов отправить вызов, является выбор наименее загруженного из серверов call-центров. Вместе с тем, если разница в загруженности между серверами не превышает заданной погрешности (на практике мы ее приняли равной 10% или E = 0.10), тогда включается механизм циклического распределения вызовов на сервера call-центр (первый звонок на первый сервер, второй на второй и так далее).

В случае невозможности отдать вызов на сервер, указанный в в качестве целевого сервера по результатам хранимой процедуры, вызов отдаем следующему серверу, с отметкой этого в БД.

Организация рабочих мест на площадке справочной службы. Все рабочие места справочной службы были логически разделены на 4 зоны. Рабочие места каждой зоны подключались к call-центру, который являлся основным для рабочих станций этой зоны (см. рисунок). Вместе с тем, в настройках рабочих мест были указаны альтернативные (дополнительные) сервера call-центра, к которым рабочее место оператора должно подключаться в случае, если между рабочим местом и call-центром произошел разрыв соединения и call-центр не отвечает на запросы клиентского рабочего места.

Еще один вопрос, который необходимо было решать – это сбор статистики в единое место. Но там уж совсем все просто, обычный сбор статистики с разных баз данных в одну с приведением данных к одному общему виду. Описывать, в общем-то, и нечего.

В итоге мы получили такую организацию работы в справочной службе, когда «падение» любого из серверов call-центр приводит лишь к 25% потере мощности. Поток входящих вызовов продолжает обрабатываться, а операторы автоматически переключаются к другому работающему серверу call-центр.

Айрат

PS: на настоящий момент решена и работает задача построения такой распределенной системы для двух различных call-центров различных производителей, включая балансировку нагрузки и сбор статистики. В работе — построение полноценной распределенной системы на 4 е1 потока на базе решения call-центра от одного производителя

Добавить комментарий

Ваш e-mail не будет опубликован.

*