Что нам стоит ВАТС построить? История о том, как анализ потоков данных помогает строить облачный сервис виртуальных АТС

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

Архитектура виртуальной АТС и роль Asterisk

В основе сервиса используется простая и масштабируемая схема. Стыки с телефонной сетью и операторами терминации принимаются на центральный SIP-прокси, после чего вызовы и регистрации распределяются на пул серверов Asterisk. Каждый сервер может обслуживать несколько виртуальных АТС разных клиентов — от небольших инсталляций до сотен абонентов.

Asterisk в этой архитектуре выполняет роль высокопроизводительного “двигателя” обработки звонков, а не центра хранения данных или бизнес-логики. Он горизонтально масштабируется, использует единый Dialplan на Lua и минимально зависит от локальной конфигурации.

Категории данных и их жизненный цикл

В рамках виртуальной АТС используется несколько принципиально разных категорий данных, каждая из которых требует своего подхода к хранению и обработке.

Основные категории данных:

• Программное обеспечение и конфигурации — ОС, пакеты, контейнеры и Dialplan, единые для всех серверов;
• Системные метрики и логи — данные о здоровье сервисов и ходе обработки звонков;
• Пользовательские конфигурации — SIP-настройки, маршруты, очереди, интеграции, которые занимают небольшой объём и легко переносятся;
• Пользовательские генерируемые данные — журналы вызовов, события, записи разговоров и конференций, объём которых постоянно растёт.

Такое разделение позволяет чётко понимать, какие данные критичны, какие быстро устаревают, а какие должны храниться годами.

Сбор и доставка данных о звонках

Во время обработки вызова Asterisk собирает расширенный набор данных: маршрут звонка, прохождение IVR и очередей, нажатые DTMF, операторов, регионы, данные из CRM. Вся эта информация формируется в единый структурированный объект Call Info, который после завершения звонка передаётся дальше по системе.

Для надёжной доставки используется брокер сообщений. Это позволяет:

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

Записи разговоров обрабатываются отдельно: сначала сохраняются в исходном формате, затем передаются в систему конвертации и долговременного хранения.

События, интеграции и брокерная модель

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

Брокерная модель позволяет:

• подключать сервисы обработки пропущенных звонков;
• инициировать автоматические перезвоны;
• отправлять уведомления по e-mail, SMS и мессенджерам;
• интегрироваться с CRM и внешними платформами через вебхуки.

Вся внешняя и внутренняя интеграция описывается через OpenAPI (Swagger), что упрощает сопровождение, развитие и повторное использование API.

Безопасность, форматы и наблюдаемость

Для передачи данных во внешние сервисы используется API Gateway, который контролирует доступ, ключи и объём передаваемой информации. Все форматы данных версионируются, а сервисы проектируются с минимальной ответственностью: каждый выполняет строго одну функцию.

Особое внимание уделяется:

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

Это позволяет заранее выявлять деградации сервисов и минимизировать влияние внешних проблем на качество обслуживания.