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

Несколько месяцев тому назад мы писали о «Неваляшке», о том, как сделать так, чтобы ваше call-центровое решение было абсолютно стабильным и не падало. Описанное решение было хорошим и выполняло свою роль. Вместе с тем оно было не лишено некоторых недостатков, как то: инерционный характер реагирования на появление очередей на том или ином call-центре и зависимость равномерного распределения операторов по серверам call-центров (при большой диспропорции распределения операторов по call-центрам реализованный механизм работает не идеально).

Сегодня я расскажу Вам о том, как получить стабильность без недостатков.

Время на месте не стоит и нашими партнерами компанией «ИнтелТелеком» было предложено решение, которое обеспечивает абсолютную стабильность комплекса и при этом оно лишено каких бы то ни было недостатков. Мы, по истечении полугода эксплуатации системы на больших нагрузках, их не обнаружили.

Сначала схему:

Итак, что у нас было. У нас был распределенный call-центр с единым центром управления на 90 рабочих мест. Мы имели проблемы со стабильностью; накоплением «усталости» у call-центра; долгим перезапуском системы при падении.

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

Перед нами стояла задача построить систему лишенную этих недостатков. Были сформулированы функциональные требования в виде:

  1. администрирование системы происходит с единого рабочего места;
  2. статистика и мониторинг системы в целом можно посмотреть с единого рабочего места;
  3. выход из строя любого сервера системы не должен приводить к остановке работы комплекса в целом. Фактически это требование отсутствия единой точки отказа.

В жертву мы принесли рабочее место оператора, заменив его максимально упрощенным рабочим местом, включающим в себя карточку вызова и интеграцию с используемой CRM системой.

В итоге получилась новая архитектурная форма, в которой:

  • каждое рабочее место подключено сразу ко всем серверам call-центра одновременно;
  • каждый сервер call-центра телефонии установлен абсолютно независимо и ничего «не знает» о других серверах комплекса;
  • авторизация операторов ведется на внешнем MS SQL сервере;
  • вся статистика и мониторинг складываются серверами call-центров на внешний MS SQL сервер;
  • MS SQL сервер организован на основе кластера, который полностью исключает отказ от обслуживания;
  • рабочее место супервизора и администратора подключается к MS SQL серверу, через который ведется администрирование и просмотр статистики;
  • все сервера call-центров (за исключением IP адресов) настроены абсолютно одинаково!

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

Это ли не идеально?

Айрат

21 комментарий для “ПроCall-центр. Правильная «Неваляшка»

    • присоединяюсь к вопросу про городские линии, поскольку мы подобную систему на Агат UX раз клиенту предлагали, зарезервировать настройки, регистрации абонентов и пр.- не проблема, но все «затыкалось» на вопросе наличия специально обученного человека, который побежит линии переключать…

    • С городскими линиями то как раз все просто. Все решается на уровне провайдера, который закидывает в 1 транк несоклько PRI/SIP потоков физически приходящих в разные сервера

  • Если рабочее место оператора залогинено на 3х серверах, которые не знают друг о друге. Как решается вопрос с тем, что когда оператор принял звонк с 1го сервера, остальные 2 считают его свободным и будут на него тоже гнать звонки?

    • Иван, опять зачет за самый грамотный вопрос. Это решается на уровне сип регистрации клиента на сервере. Получая вызов с одного из серверов телефонии, рабочее место производит разрегистрацию себя с других серверов

  • 🙂 Я знаю как это решить на октелле и даже несколькими способами. Мне прросто интересно как это было решено в этом проекте:) Неужели банальное использовать хранимой процедуры и хранение статуса оператора в БД?

    • Ну в октеле статус оператора какбе и хранится в БД (далее хранимая процедура обхода операторов).

    • Вариант номер 2 — рисуем плагин, которой подбирает текущий статус полозователя и загоняем его результаты либо в extended stored procedure либо в вебинтерфейс (по желанию)

    • «рабочее место супервизора и администратора подключается к MS SQL серверу, через который ведется администрирование и просмотр статистики;» Посмертная статистика понятна, а вот как происходит администрирование «администрирование системы происходит с единого рабочего места;» Как супервизор управляет с единого рабочего места 4мя серверами? Вот это вопрос

    • Да чего ты пристал с октеллом. В нём более — менее понятно как такие схемы делать и какие есть ограничения. Меня вот интересует что ж такого было предложено компанией «ИнтелТелеком» что обеспечивает абсолютную стабильность комплекса и при этом оно лишено каких бы то ни было недостатков.

      • Ну ты сказал что знаешь несколько на октеле — я 2 придумал 🙂 А про идею в Инфинити — ждём Айрата. Хорошая беседа. Мне нравится. Дельная 🙂

    • Насколько я понимаю это должно быть что-то вроде:
      Cупервизор/администратор рулит не 4мя серверами, а 1 «виртуальным» сервером, который только для администрирования и используется (звонки на этот сервер не идут и пользователи на нём не логинятся. На сервер только реплицируются данные с 3х серверов, поэтому на нём видна коммулятивная статистика).
      Настройки с этого сервера тиражируются на подчинённые «никого незнающие» сервера. Рабочее место по-сути иcпользуется не родное, а собственный клиент, который через API отдаёт свой текущий статус сразу на 3 сервера + возможно на виртуальный главный сервер что бы оттуда им можно было «рулить».
      Ёщу должны быть учтены тонкости с приоритезацией статусов.

      • «Настройки с этого сервера тиражируются на подчинённые «никого незнающие» сервера.» Если тут ещё присутствует оперативное управление хотя бы на уровне «кампаний», то вообще супер (лично меня интересует обратная связь — супервизор — «сервер-часть-неваляшки»).

        • Незнаю как в инифити, но в октелле особо опираться на эту хранимую процедуру нельзя, т.к. она только возвращает список операторов. Если никто из этого списка не подходит или ошибка его формирования — звонить начинает у всех операторов в задаче, даже если некоторые из них «принимают звонок на другом сервере». Без приоритезации статусов, получится что в один момент времени оператор и разговаривал и звонок пропустил и трубку поднял с большой задержкой

          • На сколько я знаю, наумен декларирует (по крайней мере) горячую замену сервера состояний

  • Когда мы такую схему недавно делали, самый оптимальный способ был именно собственный клиент работающий через СОМ + веб связку.
    На сервер по которому приходит звонок идёт статус «занят», на соседние сервера «Регламентный перерыв. Обработка звонка на сервере1».
    После завершения звонка — на соседние сервера уходила команда «выход из перерыва» поочерёдно с задержкой в 2 секунды, что бы если есть очередь на одном из серверов — брать только 1 звонок на оператора.
    Но и тут есть тонкости, поэтому меня и интересует может что более интересное придумали:)

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

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

*