Создание тиражных решений для Asterisk: сад подводных камней

В докладах о продуктах чаще всего говорят о технологиях и впечатляющих результатах, но значительно реже — о самом процессе создания продукта. Между тем именно этот путь во многом определяет успех или провал. Ниже разобран практический опыт перехода от сервисной модели к сервисно‑продуктовой, с разбором типичных ошибок и выводов, которые могут сократить путь тем, кто задумывается о собственном продукте.

От сервиса к продукту

Отправной точкой стала интеграция Bitrix24 и Asterisk, созданная около полутора лет назад. Неожиданно для команды решение оказалось востребованным и со временем привело к пересмотру стратегии компании: от чисто сервисной модели — к сервисно‑продуктовой.
Сегодня продукт используется клиентами по всему миру, практически на всех континентах. Однако еще совсем недавно компания была одним из партнеров Bitrix24 с узкой специализацией — интеграцией телефонии и решением задач колл‑центров. Эта ниша долгое время оставалась сложной и малоосвоенной.
Работа с клиентами выглядела типично: запрос на колл‑центр, Bitrix24 и «что‑нибудь, чтобы все заработало». При детальном погружении часто выяснялось одно из двух:

• либо у клиента был хаотичный набор инструментов, половину из которых требовалось заменить
• либо отсутствовало четкое понимание собственных бизнес‑процессов

Такая ситуация демотивирует и усложняет работу на качество. Со временем стало очевидно: для устойчивого роста нужен собственный продукт.

Идея и образ идеального продукта

Окончательно идея продукта оформилась после открытия API телефонии в Bitrix24 (конец 2016 года). На рынке уже существовали решения, но в основном они представляли собой промежуточные прослойки — браузерные плагины или внешние софтфоны — и не удовлетворяли клиентов.
Ключевым наблюдением стало то, что требования к интеграции на самом деле достаточно просты: достаточно воспроизвести стандартные сценарии телефонии Bitrix24, не усложняя пользовательский опыт.
Идеальный продукт в этом контексте обладает несколькими свойствами:

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

Полная самообслуживаемость продукта — скорее утопия, но стремление к максимальной простоте и автономности остается важным ориентиром.

Надежность, сценарии и среда выполнения

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

• малый бизнес ищет готовое и недорогое решение;
• enterprise‑клиенты чаще выбирают сервис и почти всегда требуют доработок.

Отдельного внимания заслуживает техническая реализация. Даже если кажется, что путь очевиден, важно рассмотреть альтернативы. В данном случае выбор стоял между внешними приложениями через AMI и реализацией логики внутри dialplan. Был выбран второй вариант — из‑за простоты установки и минимальных требований к окружению. Это же повлияло на выбор FreePBX как базового фреймворка.

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

Надежность, сценарии и среда выполнения

Даже простые на первый взгляд сценарии быстро множатся, если учитывать поведение агентов, схемы распределения вызовов и дополнительные условия. В итоге счет идет на сотни сценариев, каждый из которых необходимо проверять.
Отдельная категория проблем — плавающие баги. Один из показательных случаев был связан с различиями окружений: тестовые стенды работали на CentOS, а у клиентов использовалась Ubuntu. Это приводило к отсутствию критичных переменных в канале вызова. После фиксации поддерживаемой платформы проблема исчезла.
Вывод очевиден: программное обеспечение по‑разному ведет себя в разных окружениях. Полностью предусмотреть все исключения невозможно, но необходимо:

• обрабатывать ошибки;
• расставлять тайм‑ауты;
• быть готовыми к нештатным ситуациям.

Реальный инцидент с сетевыми ограничениями у облачного провайдера показал важность плана «Б». Заранее продуманный запасной сценарий позволил сохранить работоспособность сервисов и выиграть время для восстановления.
Графический интерфейс — еще один элемент надежности. Пользователи ожидают прежде всего простоты и интуитивности. Минимум элементов и действий — правило, которое стоит проверять при каждом новом релизе.

Релизы, тестирование и поддержка

Процесс выпуска — ключевая часть продуктовой разработки. Современные инструменты автоматизации делают CI/CD доступным даже небольшим командам. Автоматизация сборки, установки в эталонное окружение и прогона базовых сценариев позволяет существенно повысить качество релизов.

Ручное тестирование полностью не исчезает, но его объем можно значительно сократить. В данном случае автоматизировано около 70% тестов, что дало заметную экономию времени.
Для продукта, продаваемого по всему миру, обязательны локализация и полноценная документация на нескольких языках. Игнорирование этой части неизбежно усложняет жизнь и пользователям, и службе поддержки.

При построении поддержки выбор часто стоит между helpdesk и чатом. Чат обеспечивает быстрый контакт, но требует решения вопросов приоритизации и SLA. Один из рабочих подходов — использование чат‑бота на входе: он отвечает на базовые вопросы, приветствует клиента и дает сотрудникам время завершить текущую задачу.
Вторая линия поддержки требует инженеров высокой квалификации. Один сложный кейс может занимать до двух часов, и это время необходимо закладывать в планы развития продукта.