Как выбрать стратегию очереди Asterisk без потерь наугад

В Asterisk Ring All одновременно вызывает доступных участников очереди, а Random выбирает участника случайным образом. Ни одна стратегия сама по себе не гарантирует короткое ожидание или больше продаж: результат зависит от доступности операторов, правил очереди и сценария после выхода из неё. Покажу, что проверить и как безопасно применить настройку.

Что именно выбирает стратегия очереди

В Asterisk очередь задаётся в конфигурации queues.conf, а параметр strategy определяет, как приложение очереди будет предлагать вызов её участникам. Это не настройка качества связи и не способ заставить занятого человека ответить. Если абонентская линия недоступна, устройство не зарегистрировано или участник поставлен на паузу, сама стратегия эти причины не исправит. Я начинаю с queue show: там видны очередь, ожидающие вызовы и состояние участников.

В экспертной базе указано, что стандартное значение стратегии — ringall; официальная документация Asterisk тоже показывает ringall как значение по умолчанию в примере очереди. Но полагаться на «по умолчанию» в рабочей системе нельзя: локальный конфиг, панель управления или realtime-хранилище могли задать собственное значение. Проверяйте фактическое состояние своей очереди, а не воспоминания о том, как её когда-то создавали.

Условный пример из «Домино-Строй»: сотрудники жалуются, что звонок слышит не тот человек или вызов долго остаётся без ответа. Я не объявляю виноватой стратегию до проверки. Сначала сопоставляю настройки очереди, список участников и записи о звонках; затем воспроизвожу вызов с тестового номера. Даже убедительная жалоба — это повод собрать данные, не готовый диагноз. В документации проекта «доступность» рассматривается через состояние канала и параметры очереди; среди причин исключения участника названы, например, пауза, занятость или недоступное устройство. Поэтому одинаковое правило может вести себя по-разному после смены состава смены или регистрации телефона. Для проверки важен не только текст strategy, но и ответ на вопрос: какие участники считались доступными в момент конкретного вызова?

Ring All: одновременный вызов доступных участников

ringall предлагает вызов всем доступным участникам очереди одновременно; ответивший первым принимает звонок. Это может сократить задержку, связанную с последовательным обходом сотрудников, если у очереди есть несколько свободных и корректно настроенных участников. Слово «доступным» здесь важно: настройки участника, его состояние и параметры очереди влияют на то, кому Asterisk вообще сможет звонить.

У такого поведения есть цена. Телефоны могут звонить одновременно, а распределение работы зависит от того, кто успел ответить. Это не равномерная раздача звонков и не гарантия, что сотрудники получат одинаковую нагрузку. В небольшой группе правило бывает удобным, когда важнее быстро предложить вызов свободной команде. Если одновременно звонить всем нежелательно, нужно рассматривать иные стратегии или менять сам процесс обработки. У ringall есть и организационный нюанс: несколько телефонов звонят на один входящий вызов, но разговор достанется одному ответившему участнику. Если команда работает по навыкам, очередям с приоритетами или правилам занятости, проверьте их взаимодействие на своей схеме до изменения. Простая настройка может менять поведение сразу для всей группы.

В кейсе с «Домино-Строй» я бы сравнивал не абстрактные «продажи до и после», а наблюдаемые вещи: сколько вызовов вошло в очередь, сколько дождалось ответа, сколько завершилось выходом без соединения и как долго люди ждали. Asterisk пишет события очереди в queue_log, включая вход в очередь, соединение и выход по тайм-ауту. С этими данными можно проверить эффект изменения; без них фраза «Ring All спас продажи» остаётся рекламой.

Random: случайный выбор не означает равномерную нагрузку

Стратегия random выбирает участника случайным образом. Экспертная база подтверждает именно это описание. Из него не следует, что Asterisk сначала назначит вызов занятому оператору и будет ждать, пока тот освободится, а затем начнёт искать другого. В статье этот сценарий был описан как свойство Random, но он не подтверждён документацией, поэтому я его убрал. Как будет обработан конкретный вызов, зависит от состояния участников и параметров очереди.

Случайный выбор также не обещает математически ровное распределение за короткий период. В серии вызовов один участник может получить больше предложений, другой меньше; случайность не знает, кто только что разговаривал, у кого перерыв и кто лучше подходит к теме обращения. Это не «справедливость», а один из алгоритмов выбора. Если нужна управляемая нагрузка, сначала сформулируйте критерий: по очереди, по длительности простоя, по навыку или по другой логике, которую поддерживает ваша конфигурация.

В «Домино-Строй» проверка должна ответить на конкретный вопрос: действительно ли Random связан с пропущенными вызовами или причина в доступности телефонов, составе участников, маршруте выхода и настройках ожидания? Мы сверяем queue show с записями queue_log и повторяем один и тот же тест при сопоставимых условиях. Ирония короткая: случайный алгоритм может быть честным ровно настолько, насколько честна ваша статистика.

• Случайный выбор участника
• Не гарантия равной нагрузки
• Проверьте доступность устройств
• Сопоставьте очередь и журнал

Как читать настройки и менять конфигурацию

В статической конфигурации очереди задаются в queues.conf; имя очереди записывается в квадратных скобках, а среди её параметров — strategy. Не копируйте наугад целый конфиг из чужой версии: используйте пример queues.conf именно установленного релиза и учитывайте, не управляет ли очередями внешняя панель или realtime-хранилище. Если источник конфигурации другой, ручная правка файла может не изменить рабочее состояние. Отдельно проверьте, не используется ли статический список участников или динамическая регистрация операторов. В первом случае конфигурационный файл может содержать актуальный состав, во втором участники добавляются через интерфейс управления или другое хранилище. Не редактируйте параллельно два источника и не считайте успешный reload доказательством, что изменился именно нужный параметр: сверка через queue show покажет загруженную стратегию. В примере конфигурации параметр записывается как strategy=ringall или strategy=random; слово после знака равенства и есть выбор способа распределения. Не добавляйте кавычки и не называйте параметр ring_strategy: используйте синтаксис из примера Asterisk.

Параметры timeout и retry тоже нельзя трактовать как универсальные обещания. Первый задаёт интервал попытки дозвона участникам, а второй участвует в цикле повторной попытки; суммарное ожидание зависит от настроек очереди и сценария Queue() в диалплане.

После правки queues.conf обычно достаточно перезагрузить поддерживающий это модуль, а не перезапускать весь Asterisk и обрывать активные разговоры. В официальном руководстве Asterisk показана команда CLI module reload app_queue.so, после чего пример проверяет список очередей командой queue show. Перед выполнением посмотрите справку своей версии и способ управления конфигурацией: изменения через GUI или базу данных могут требовать другого действия. ARI — интерфейс управления, а не место, где нужно «перезапускать настройки очереди».

• Проверьте источник конфигурации
• Сверьте strategy и параметры ожидания
• Примените поддерживаемую перезагрузку
• Проверьте очередь через queue show

Как проверить эффект без выдуманной конверсии

До изменения зафиксируйте исходные условия: расписание, состав и статус участников, входящий маршрут и время проверки. Затем соберите события queue_log для выбранного периода и посмотрите, сколько звонков вошло, сколько было соединено, сколько завершилось ожиданием или отказом абонента. В официальном описании Queue Logs перечислены ENTERQUEUE, CONNECT и EXITWITHTIMEOUT; по ним можно восстановить путь вызова, но сами события не объяснят бизнес-причину без контекста. В журнале есть и другие события, например завершение попытки дозвона без ответа или отмена вызова самим ожидающим. Их стоит учитывать отдельно от успешных соединений: один итоговый счётчик «пропущено» может смешивать разные ситуации. Сопоставление событий помогает отделить очередь от отказа вызывающего и от проблемы конкретного участника, хотя финансовый вывод всё равно требует данных самой компании.

Проведите тестовый звонок в контролируемое время и убедитесь, что вызов дошёл до ожидаемой очереди, участники действительно зазвонили, а ответивший оператор получил разговор. Затем проверьте сценарии без доступных участников и при отсутствии ответа. Asterisk может завершить приложение Queue с определённым статусом; дальше диалплан должен решить, предложить ли голосовое меню, альтернативную очередь, обратный звонок или другой маршрут. Нельзя обещать «звонок всегда кому-нибудь достанется», если такой путь не настроен.

Сравнивайте периоды с одинаковыми правилами учёта и похожей нагрузкой. Не выдавайте единичный тест за рост конверсии: на продажи влияют график, реклама, скорость ответа и работа сотрудников. В исходном варианте были проценты потерь, прироста конверсии и выручки, а также времена ожидания, якобы измеренные в одном кейсе; экспертная база их не подтверждает. Я удалил эти значения. Если компания ведёт собственную аналитику, её цифры можно добавить только с периодом, методикой и проверяемым источником.

Что делать, если вызов не попадает оператору

Не начинайте с замены SIP-провайдера по одному сообщению «all circuits busy». Эта фраза сама по себе не доказывает, что виновата стратегия очереди, а экспертная база отдельно указывает на необходимость проверить аутентификацию транка. Я проверяю регистрацию и доступность транка, маршрут входящего вызова, состояние участника, ответные коды и журналы именно в момент проблемы. Затем локализую сбой: вызов не дошёл до Asterisk, не вошёл в Queue, не получил доступных участников или вышел из очереди по условию.

Для контроля очереди используйте queue show и включённое журналирование событий очереди. Сопоставьте номер вызова и время в журналах, проверьте, не стоит ли нужный участник на паузе, не занят ли он и разрешает ли конфигурация звонить ему в текущем состоянии. Когда очередь пуста или участники недоступны, проверьте ветку диалплана после Queue. «Переадресовать на голосовую почту» — лишь один из вариантов, его нужно согласовать с бизнес-процессом и реально настроить.

Мой порядок действий для «Домино-Строй» такой: зафиксировать настройки до изменения, провести контрольный вызов, проверить записи очереди, применить одну обоснованную правку и повторить тест. Если причина оказалась не в стратегии, не оставляем случайную смену алгоритма как будто она что-то вылечила. Если причина в маршруте или статусах участников, исправляем их отдельно. Короткая ирония: менять стратегию наугад — это способ получить новую загадку, а не ответ.

• Проверьте транк и входящий маршрут
• Сверьте статус участников
• Найдите событие выхода из Queue
• Проверьте резервный сценарий диалплана

Частые вопросы