Работа справочной службы (call-центра) предполагает обработку вызовов 24 часа в сутки, 7 дней в неделю, 365 дней в году, иными словами круглосуточно и непрерывно. Это требование является весьма желательным для call-центров, оказывающих коммерческие услуги. Но есть ряд call-центров, для которых это условие является обязательным. Такими call-центрами являются службы «09» или службы экстренного реагирования «01»–«04» и «112». Несмотря на заверения поставщиков платформ call-центра о высокой надежности и безотказности системы, все равно случается, что случаются такие ситуации, когда программно-аппаратный комплекс дает сбой. И обработка поступающих в call-центр вызовов становится невозможной. Связано ли это падение с проблемами программного обеспечения или с проблемами аппаратной составляющей уже не важно, поскольку перерыв в обслуживании вызовов уже сам по себе критичен.
Не все платформы call-центра предполагают возможность полного «горячего» резервирования, а во многих платформах, предполагающих полное «горячее» резервирование, бюджет на него сравним с покупкой второго такого call-центра.
Так как сделать так, чтобы зарезервировать мощности call-центра даже в том случае, если архитектура call-центра не позволяет делать «горячее» резервирование или оптимизировать свои затраты на организацию схемы резервирования. Оговорюсь сразу, такое решение в основном ориентировано на большие call-центры, хотя в ряде случаев, оно может быть полезно и для небольшого количества операторов тоже.
Недавно мы реализовали схему «горячего» резервирования для реального call-центра, там, где существующая платформа call-центра не предполагала схемы «горячего» резервирования. Общее число операторов – 75, подключение к телефонной сети общего пользования (ТсОП) – Е1 (edss1) в количестве 4 шт от одного оператора связи. Максимальная загрузка линий в ЧНН – не более 90 одновременных звонков в системе (разговор с оператором + ожидание в очереди).
Перед нами стояла стратегическая задача исключить возможный перерыв в обслуживании телефонных вызовов. Мы начали с того, что поняли, что при обработке вызовов, даже в ЧНН, потеря одного потока Е1 неприятна, но не страшна. Задача не могла быть решена в рамках существующей платформы call-центра, и мы решили расширить рамки и решать задачу в рамках построения двух, независимо установленных серверов call-центров, а далее нарастив их количество до четырех. В идеале желательно было разнести потоки Е1 в четыре разных call-центра, установленных независимо. То есть, если «падает» любой из независимых call-центров, остальные платформы должны продолжать обслуживание вызовов, а рабочие места операторов, потеряв связь с сервером call-центра, переключаются в автоматическом режиме к другому серверу и вся система call-центров продолжает обслуживание телефонных вызовов, понеся минимальные потери в один сервер call-центра и один поток Е1.
«Падение» любого из независимо установленных call-центров сопровождается разрывом связи Е1 потока, заведенного в этот call-центр, и оператором связи. Таким образом, мы считаем, что событие «падение call-центра» и «разрыв связи по Е1 потоку» эквивалентны.
Работы на стороне оператора связи. Оборудование операторов связи позволяет маршрутизировать вызовы на альтернативные направления в случае недоступности основного. То есть, если при маршрутизации вызова на конкретный Е1 поток, текущее направление не доступно («потеря связи по Е1 потоку»), оператор связи маршрутизирует этот же вызов на альтернативное направление – другие Е1 потоки. Этот вопрос мы решили совместно с оператором связи настроив «перекрестную маршрутизацию» вызовов для Е1 потоков на стороне оператора связи. То есть, если в процессе работы коммутатор оператора связи фиксировал разрыв связи с каким либо потоком Е1, то вызовы направляются на другие потоки Е1, а в случае восстановления связи, возобновляется первоначальная схема маршрутизации. Дополнительно мы определили с оператором связи порядок приоритета потоков Е1 по приему вызовов. После того как задача с маршрутизаций и распределением вызовов была решена, необходимо было организовать обслуживание вызовов внутри справочной службы.
Перекрестная маршрутизация вызовов на Е1 потоках позволила полностью исключить вероятность отказа в обработке вызова при падении любого из call-центров.
Работы на площадке справочной службы. После того, как были решены вопросы поступления вызовов на площадку справочной службы в любом случае (даже если «падал» любой из Е1 потоков) необходимо было поставить решить ряд задач по маршрутизации между независимыми call-центрами. Мы предположили, что административно достаточно трудно будет контролировать количество операторов, подключенных к тому или иному call-центру. Следовательно, количество операторов, вошедших в систему в любой из call-центров, не регламентируется. То есть, в любой момент времени в любом из call-центров может быть любое, даже нулевое, количество операторов. Кроме того, необходимо обеспечить равномерную нагрузку на операторов. То есть, за одинаковый интервал времени на каждого из операторов, подключенных к любому из call-центров, должно поступать примерно одинаковое количество вызовов. Дополнительно надо обеспечить автоматическое переключение рабочего места оператора к другому call-центру, при условии «падения» текущего. Ну и, собственно, необходимо объединить статистику обработки вызовов со всех call-центров, оставив отображение показателей статистики реального времени в каждом call-центре в отдельности.
Прежде всего, мы объединили все call-центры таким образом, что каждый call-центр был связан с остальными другими VoIP каналом, обеспечивающим обработку 30-ти голосовых соединений. Такая избыточность позволила в случае необходимости «отдать» все 30 вызовов, поступивших по Е1 потоку любому из соседних call-центров. Следующей задачей была реализовать такую логику направления вызовов между call-центрами, которая бы балансировала нагрузку между операторами справочной службы и исключала появление очереди обслуживания на одном из 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-центра от одного производителя
Не все платформы call-центра предполагают возможность полного «горячего» резервирования, а во многих платформах, предполагающих полное «горячее» резервирование, бюджет на него сравним с покупкой второго такого call-центра.
Так как сделать так, чтобы зарезервировать мощности call-центра даже в том случае, если архитектура call-центра не позволяет делать «горячее» резервирование или оптимизировать свои затраты на организацию схемы резервирования. Оговорюсь сразу, такое решение в основном ориентировано на большие call-центры, хотя в ряде случаев, оно может быть полезно и для небольшого количества операторов тоже.
Недавно мы реализовали схему «горячего» резервирования для реального call-центра, там, где существующая платформа call-центра не предполагала схемы «горячего» резервирования. Общее число операторов – 75, подключение к телефонной сети общего пользования (ТсОП) – Е1 (edss1) в количестве 4 шт от одного оператора связи. Максимальная загрузка линий в ЧНН – не более 90 одновременных звонков в системе (разговор с оператором + ожидание в очереди).
Перед нами стояла стратегическая задача исключить возможный перерыв в обслуживании телефонных вызовов. Мы начали с того, что поняли, что при обработке вызовов, даже в ЧНН, потеря одного потока Е1 неприятна, но не страшна. Задача не могла быть решена в рамках существующей платформы call-центра, и мы решили расширить рамки и решать задачу в рамках построения двух, независимо установленных серверов call-центров, а далее нарастив их количество до четырех. В идеале желательно было разнести потоки Е1 в четыре разных call-центра, установленных независимо. То есть, если «падает» любой из независимых call-центров, остальные платформы должны продолжать обслуживание вызовов, а рабочие места операторов, потеряв связь с сервером call-центра, переключаются в автоматическом режиме к другому серверу и вся система call-центров продолжает обслуживание телефонных вызовов, понеся минимальные потери в один сервер call-центра и один поток Е1.
«Падение» любого из независимо установленных call-центров сопровождается разрывом связи Е1 потока, заведенного в этот call-центр, и оператором связи. Таким образом, мы считаем, что событие «падение call-центра» и «разрыв связи по Е1 потоку» эквивалентны.
Работы на стороне оператора связи. Оборудование операторов связи позволяет маршрутизировать вызовы на альтернативные направления в случае недоступности основного. То есть, если при маршрутизации вызова на конкретный Е1 поток, текущее направление не доступно («потеря связи по Е1 потоку»), оператор связи маршрутизирует этот же вызов на альтернативное направление – другие Е1 потоки. Этот вопрос мы решили совместно с оператором связи настроив «перекрестную маршрутизацию» вызовов для Е1 потоков на стороне оператора связи. То есть, если в процессе работы коммутатор оператора связи фиксировал разрыв связи с каким либо потоком Е1, то вызовы направляются на другие потоки Е1, а в случае восстановления связи, возобновляется первоначальная схема маршрутизации. Дополнительно мы определили с оператором связи порядок приоритета потоков Е1 по приему вызовов. После того как задача с маршрутизаций и распределением вызовов была решена, необходимо было организовать обслуживание вызовов внутри справочной службы.
Перекрестная маршрутизация вызовов на Е1 потоках позволила полностью исключить вероятность отказа в обработке вызова при падении любого из call-центров.
Работы на площадке справочной службы. После того, как были решены вопросы поступления вызовов на площадку справочной службы в любом случае (даже если «падал» любой из Е1 потоков) необходимо было поставить решить ряд задач по маршрутизации между независимыми call-центрами. Мы предположили, что административно достаточно трудно будет контролировать количество операторов, подключенных к тому или иному call-центру. Следовательно, количество операторов, вошедших в систему в любой из call-центров, не регламентируется. То есть, в любой момент времени в любом из call-центров может быть любое, даже нулевое, количество операторов. Кроме того, необходимо обеспечить равномерную нагрузку на операторов. То есть, за одинаковый интервал времени на каждого из операторов, подключенных к любому из call-центров, должно поступать примерно одинаковое количество вызовов. Дополнительно надо обеспечить автоматическое переключение рабочего места оператора к другому call-центру, при условии «падения» текущего. Ну и, собственно, необходимо объединить статистику обработки вызовов со всех call-центров, оставив отображение показателей статистики реального времени в каждом call-центре в отдельности.
Прежде всего, мы объединили все call-центры таким образом, что каждый call-центр был связан с остальными другими VoIP каналом, обеспечивающим обработку 30-ти голосовых соединений. Такая избыточность позволила в случае необходимости «отдать» все 30 вызовов, поступивших по Е1 потоку любому из соседних call-центров. Следующей задачей была реализовать такую логику направления вызовов между call-центрами, которая бы балансировала нагрузку между операторами справочной службы и исключала появление очереди обслуживания на одном из 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-центра от одного производителя
