Система за автоматично обаждане на клиенти

заден план

Към момента е изминала повече от година от изпълнението. Сега около 90-95% от целия програмен код на системата е пренаписан и ясно разбирам как се развива системата и как трябва да се развива. Но в този момент, когато ми беше поставена задачата, имах бегла представа как трябва да изглежда кодът, съдейки по техническата спецификация, и нямах никакъв опит в комуникацията със звездичка по принцип. Веднага трябва да кажа, че основната идея не е моя, моята задача беше да реализирам или дори по-скоро да изобразя това, което беше нарисувано в условията на проблема. Но в същото време, най-важното, бях практически неограничен в избора на технологии и решения - което според мен ми позволи да доведа цялата схема до формата, която исках.

По това време компанията вече разполага с работещ кол център. Около 10 опашки, от 4 до 20 оператора на всяка опашка и около 12-15 хиляди разговора денонощно. 5 доставчика за градски, междуградски и международни разговори. За дълго време кол центърът придоби голям брой различни функционалности и собствени разработки. Основната софтуерна платформа е сървъри на звездички, база данни със статистика на обажданията и бизнес логика на MySQL, както и обвързване от скриптове на AGI.

План за изпълнение

Внедряване

Планиране

Работа с оператор

Балансиране и резервиране

Ако търсите в интернет информация как да резервирате изходящи повиквания, когато някой от доставчиците е недостъпен, най-често ще намерите препоръка като няколко набирания в диаплан едно след друго. От своя страна исках да направя нещо по-гъвкаво и динамично. Основният проблем беше, че използваме много различни железа и преди да оформим повикване, няма време да ги заобиколим в търсене на най-малко натоварените иналичен багажник. Основната идея беше да се работи с вече агрегирана информация. За това беше написан отделен демон, чиито задачи бяха следните: да събира натоварването от различни видове оборудване, с TDM разликата между заетите слотове и свободните слотове, с voip доставчици, достъпност чрез sip peers и, въз основа на текущите канали от звездички, изберете кой се използва повече. Но в допълнение към избора на посока, трябва да се има предвид, че всеки от стволовете може да падне, така че трябва да изберете алтернатива. В моя случай това бяха доставчици на voip, но те също имат свои собствени цени, така че балансирането трябва да избира от най-евтиния до най-скъпия (те са абсолютно еквивалентни по качество). За такава извадка направих собствено тегло или цена за всеки доставчик. По този начин беше получен списък с ключове и стойности на тази форма:

Местен район => 10
Voip доставчик A => 20
Voip доставчик B => 30
Voip доставчик C => 40

Така че, ако някой от доставчиците не е наличен, ние търсим заместник от най-ниския до най-високия или най-скъпия.

Но освен това има и разпределение в зависимост от принадлежността на номера. Тоест, например, трябва да се обаждате на московски номера чрез вашия местен доставчик, до Сибир или други страни чрез собствени, ако има такива, или чрез междуградски и международни направления. Тук е необходимо да се определи към кой регион принадлежи номерът. За това написах анализатор за регистъра на комуникациите към базата данни. Изглежда като:

Обща схема на работа и различни нюанси

За всяка задача в момента можете да зададете броя опити, който се намалява с всеки статус"незавършен". След отново конфигурируемо време за изчакване, задачата е отновоще се върне за освобождаване.
Също така наскоро стана възможно да се направи приоритетно обаждане през даден доставчик, ако не е претоварен и наличен.
Демонът за агрегиране на натоварване от VoIP доставчиците се ръководи от префикса в името на sip каналите. Би било възможно да се използват например групи, но засега всичко работи добре.
Периодично пингва както Voip доставчиците, така и всички железни части по пътя към стволовете, ако някой от тях не е наличен, доставчикът се изважда от балансиране.
След като изберете свободен оператор, той се маркира като зает и се получава следната логика:

Изискваме всички asterisk сървъри, които са в баланс.
За текущата опашка се изискват параметри на повикване. Това е времето за изчакване на отговор от оператора и клиента,"източник"номера, който клиентът ще види при входящо обаждане - различно е за всяка услуга.
Според клиентския номер избираме посоката чрез таблицата с регистъра на номерата.
Изберете връзката нагоре, за да се обадите. Ако е зададено на 0, връзката нагоре няма да участва в избора, така че можете да балансирате, като прехвърлите приоритета към доставчици. Избраният багажник ще бъде проверен за наличност и след това за зареждане. Ако условията не са изпълнени, връзката нагоре се пропуска и преминаваме към следващото най-високо тегло.
След това избираме сървъра със звездичка с най-малък брой канали. Тъй като съхраняваме всички канали от всички сървъри в Redis, ние просто получаваме общия брой чрез вградената функция hlen. След като изберем сървър, се опитваме да се свържем с него - ако сървърът не отговори, вземаме следващия, отново с най-малко натоварване.
Накрая, за параметъра"променлива"се формира масив от сервизни променливи, на базата на които се брои повикването и се избира посоката. Същото и тамизползва се обвързването на текущото повикване на оператора със задачата, за която се извършва повикването.