Работаю я как Voip системный администратор на одну маленькую французскую компанию, как я сюда попал это отдельная история.
Я покажу результаты работы команды над проектом целью которого являлась глобальная эквивалентная стратегия распределения звонков на центры дозвона в зависимости от количества агентов способных принимать звонки. Фраза конечно удалась,
B примере это выглядит так:
Центр1 = 20 агентов
Центр2 = 10 агентов
При загруженности в 50 % В Центре1 должно быть 10 свободных агентов, в Центре2 5 агентов. Вот такой паритет.
Когда количество звонков превышает количество свободных агентов, клиенты должны постоять в одной глобальной очереди, друг за дружкой. Если некоторое количество агентов стало свободно, то клиенты в порядке очередности продвигаются к агентам.
Всё должно быть завёрнуто в веб интерфейс, с модными прибамбасами.
Старая система:
У нашего клиента, 6 Колл центров, все они удовлетворяют один и тот же сервис с единственным входящим номером. Количество звонков зависит от дня недели, но в основном это 15000-20000 в день. Сами центры работали по такой схеме:
До меня, сервера на трикбоксах(астериск) работали без серверов опенсипс, система была архаичной, были проблемы с качеством звука. Я поставил две сервера с опенсипсами, Opensips это как прокси, только для звонков, их можно направить по заданным правилам куда угодно. Но и эта система начала показывать свой лимит. Сервера на опенсипсе раздавали звонки с модулем Dispatcher, принцип простой, на сервере был текстовый файл с такими данными:
1 192.168.1.1:5060 #Центр1
1 192.168.1.2:5060 #Центр2
1 192.168.1.3:5060 #Центр3
1 192.168.1.4:5060 #Центр4
1 192.168.1.5:5060 #Центр5
1 192.168.1.6:5060 #Центр6
Приходит звонок, опенсипс читает первую линию > звонок в центр 1 > Перенаправляем
Приходит звонок, опенсипс читает вторую линию > звонок в центр 2 > Перенаправляем
Когда мы подходим к концу файла, начинаем читать по кругу. Вот теперь представим что линий у нас 100, это что? Правильно 100%
Каждое утро я получал процентное соотношение для каждого центра, округлял и генерировал файл маленьким руби скриптом. Это позволило поднять эффективность на 5% Мало? 5 % это 9 человек, при средней зарплате 1700, умножаем = 15300 € экономии в месяц. Количество агентов разное, от 180 до 1 то есть варьируется в течение дня. Через некоторое время я начал замечать некоторые аномалии, то один центр меньше ресурсов декларирует чем на самом деле, то другой… Вот он человеческий фактор. Да и общая непрозрачность, локально на Триксбоксах была полная отчетность, но глобально, сколько человек ждет в очереди в 10:30 я сказать не способен. Выходит без глобальной видимости хорошо спрогнозировать нагрузку просто трудно, ну и количество агентов может быть неправильным. Мои 5% сходили на нет из за «Фактора Ч» и глобальной статистики.
Идея! А как бы оно того, так вот что бы оно как то так…
Между делом вышел опенсипс 1.6 с интересным модулем Load Balancer. Принцип интересен, опенсипс держит в памяти количество заданных ресурсов, и посылает звонки где они свободны. Осталось достать количество агентов из Триксбокса каждую минуту и модифицировать в базе. Эврика ?!
Не совсем,
1: Делает это он не эквивалентно по отношению от количества агентов, то есть забивает первый ресурс до 0, потом второй. (в нашем случает первый центр, второй)
2: Опенсипс не умеет играть аудио, и вообще очередей нет, это прокси.
3: Альфа версия.
Решение,
1: Я написал главному разработчику опенсипса (Богдан) он сделал для нас нужный алгоритм. Можно посмотреть тут
2: Используем астериск для аудио и очереди.
3: Крестим пальцы, тестируем, тестируем.
Новая система:
Астериск принимает звонок, и пытается позвонить через опенсипс, если ресурсы есть, он проходит, ресурсов нет, говорим подождите. Все клиенты становятся в одну очередь что уменьшает количество не принятых звонков по сравнению со старой системой. Обновление количества ресурсов идет каждые Х сек. Что вообще такое эти ресурсы? Это количестве залогиненых в Триксбох про агентов.
Поставили мы 4 сервера, всё нужно дублировать, сеть питание, сетевые адаптеры в разных свичах, сервера по двое на отдельных ангарах с разными источниками питания, между ними двойная оптика «кольцом». Физические характеристики такие:
Dell r410 double quad core xenon, статистика загрузки:
Opensips
top — 19:05:59 up 35 days, 4:16, 2 users, load average: 1.10, 1.24, 1.21
Tasks: 192 total, 1 running, 191 sleeping, 0 stopped, 0 zombie
Cpu(s): 9.2%us, 1.3%sy, 0.0%ni, 89.4%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4043228k total, 3905396k used, 137832k free, 256656k buffers
Swap: 6094840k total, 108k used, 6094732k free, 3101996k cached
Asterisk:
top — 19:10:31 up 37 days, 23:40, 3 users, load average: 0.04, 0.05, 0.12
Tasks: 175 total, 1 running, 174 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 16.7%sy, 0.0%ni, 83.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4037580k total, 2375616k used, 1661964k free, 156400k buffers
Swap: 6094840k total, 168k used, 6094672k free, 1876072k cached
По астериску поздно снял, обычно они в среднем 0.5 Load. На опенсипсах думаем добавить памяти и процессоров, система жрет, оптимизация не помогла.
Запуск
Кошмар, система брыкалась, стопорилась посередине дня, клиент плевался, мы работали ночами. Вылезали баги, проблема в том что их было сложно выявить без реальной нагрузки сервера, синтетические тесты не помогали. На исправление багов у нас ушло 5 дней. График был интересный, ночью работаешь, днем смотришь что б не упало. Я ВИДЕЛ эти 180 человек которые из за меня не работали, их проклятия шли мне прямо в мозг. За эти пять дней я понял что такое быть на горящей сковороде. Но вот на пятый день заработало, после были только мелкие модификации. Клиент доволен.
Интерфейс
Веб интерфейс получился простым и функциональным, лишних рюшечек нет, вот собственно и он. Правда пришлось потереть имена, из за легальных вопросов.
Логин:
Глобальная статистика в цифровом варианте. Всё на французком, попытаюсь пояснить:
Nombre d'appels totaux pour la journée: Количество принятых звонков.
Temps de réponse estimé: Среднее время ожидания.
Appels en attente: Количество человек в очереди (им ещё не ответили).
Appels reçus: Количество принятых звонков.
Agents [ Total: Libre: En com ]: Агенты [ Все: Свободные: Говорят ]
Appels abandonnées: Количество клиентов повесившие трубку до связи с агентом.
Efficacité Globale: Общая эффективность, % от отвеченных из общих принятых.
Charge Globale: Глобальная нагрузка, ну если 10 из 10 разговаривают, и 0 человек ждут, то нагрузка 100% итд…
То же самое, но статистика по одному центру:
Графики, обратите внимание на второй график, теперь количество агентов быстрей и эффективней адаптируется на загруженность, когда делать нечего они занимаются другими делами вместо торчания у телефона который звонит раз в пол часа.
Но видно что в обед поднажать ещё могут.
Остальные скрины вставлю поменьше, а то и так топик длинный. Кому интересно тот посмотрит.
Результаты скачек
Увеличение производительности на 7-10 % Это только для центров дозвона, глобальная экономия времени на другие задачи. Исчезновение рутинных задач, вроде составления ресурсов руководящими центрами дозвона.
Наш сайт: www.ipbx-france.fr
Отдельное спасибо команде Master of Code за их работу по части веб морды и внутренних скриптов.
Спасибо всем за внимание.
