Ретроспектива одного проекта IqDialer

За последние годы на рынке появилось множество решений для автоматизации исходящего обзвона, однако путь от простого прототипа до полноценного продуктового решения остаётся непростым. Особенно это заметно в проектах, где требуется интеграция телефонии, CRM-систем, пользовательских интерфейсов и аналитики. В этом материале рассматривается эволюция одной платформы автоматизированного обзвона — от первых экспериментов до зрелой архитектуры с микросервисами, метриками и промышленным внедрением.

Идея продукта и первые требования

Изначально задача сводилась к автоматизации исходящего обзвона для колл-центров. На рынке существовали open-source решения, которые успешно решали базовую задачу дозвона, но плохо подходили для интеграции с внешними системами, прежде всего с CRM.

Быстро стало очевидно, что платформа должна выступать связующим звеном между несколькими классами систем:
CRM, сервером телефонии, рабочими местами операторов и интерфейсами для супервайзеров. При этом у каждого заказчика эти компоненты могли отличаться — от используемой CRM до пользовательских интерфейсов операторов.

Ключевая идея заключалась не в создании очередного «автодозвона», а в построении гибкой интеграционной платформы, способной работать с разными сценариями и масштабироваться под нагрузку.

Идея продукта и первые требования

Первый рабочий прототип был реализован на классическом стеке: PHP, MySQL и генерация call-файлов для Asterisk. Интеграция с CRM осуществлялась через API, а события передавались обратно в пользовательские интерфейсы с помощью вебхуков. Отчётность формировалась через импорт и экспорт данных в CSV.

Довольно быстро проявились архитектурные проблемы:

• выполнение логики через cron и PHP-скрипты плохо подходило для длительных процессов;
• потребление памяти росло, а управлять временем выполнения было сложно;
• в базе данных начали накапливаться полуструктурированные данные, по которым требовался поиск;
• поиск по JSON в MySQL на тот момент был практически неприменим;
• использование call-файлов ограничивало гибкость и масштабируемость.

Эти ограничения стали сигналом к пересмотру технологического стека и архитектуры системы.

Переход к новой архитектуре и работе с данными

Следующим шагом стал переход на Python как основной язык разработки. Он позволил создавать сервисы, работающие 24/7, и дал доступ к богатой экосистеме библиотек. Была реализована собственная REST API, через которую взаимодействовали как внешние системы, так и внутренние компоненты платформы.

База данных была заменена на PostgreSQL. Это дало сразу несколько преимуществ: поддержку JSONB, расширяемость и возможность эффективно работать с большими объёмами данных. Особое внимание уделялось партиционированию таблиц — особенно тех, которые быстро росли, например CDR и данные лидов.

Партиционирование позволило:

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

Дополнительно в архитектуру был внедрён ClickHouse — как хранилище метрик и событий, не предназначенное для транзакционной логики, но идеально подходящее для аналитики.

Метрики, real-time интерфейсы и микросервисы

Одной из ключевых проблем ранних этапов разработки стала отсутствие наблюдаемости. Логи быстро разрастались до десятков гигабайт и не давали целостного понимания происходящего в системе. Это привело к важному выводу: без метрик невозможно развивать продукт.

Метрики начали собираться с самого приложения и складываться в ClickHouse, а визуализация выполнялась через Grafana. Со временем эти данные стали полезны не только разработчикам, но и заказчикам.

Параллельно была переработана логика пользовательских интерфейсов. Вместо постоянных запросов к API был внедрён push-подход с использованием WebSocket. Пользователи подписываются на события, а система сама уведомляет их обо всех изменениях в реальном времени. Это снизило количество ошибок и устранило проблемы гонок при одновременном редактировании данных.

Постепенно вокруг ядра платформы сформировался набор микросервисов:
импорт и экспорт данных, асинхронные задачи, уведомления, аудит изменений и централизованная аутентификация (SSO). Такой подход позволил переиспользовать компоненты в других проектах и упростить развитие системы.

Внедрение, обновления и эксплуатация

Когда платформа стала зрелым продуктом, встал вопрос промышленного внедрения и сопровождения. Ручная установка зависимостей на серверах заказчиков оказалась слишком трудоёмкой, и было принято решение использовать Docker.

Контейнеризация позволила стандартизировать поставку решения. Клиенту передаётся Docker Compose-файл с преднастроенной конфигурацией, а доступ к образам осуществляется через закрытый Docker Registry. Установка и обновление продукта сводятся к нескольким командам, а время простоя при обновлении ограничивается перезапуском контейнеров.

Для эксплуатации используется комплексный мониторинг:
системные метрики серверов, метрики приложения, аналитика звонков. Данные из ClickHouse визуализируются в Grafana, а алерты передаются во внешние системы мониторинга. При этом платформа позволяет гибко настраивать набор графиков под потребности конкретного заказчика.