Когда виртуальный оператор запускает сервис на сети партнёра, для конечного абонента это должно выглядеть как обычный работающий сервис, без единого намёка на то, что за ним стоит чужая инфраструктура. Для вендора, который эту интеграцию делает, задача выглядит иначе: нужно встроить нового оператора в действующую платформу так, чтобы его трафик ни при каких условиях не задел основной.
В одном из наших проектов виртуальный оператор запускал SMS-сервис на сети партнёра, чью радиосеть и SMS-инфраструктуру он на старте полностью арендовал. Действующий SMS-центр к тому моменту уже обслуживал основной трафик оператора-хоста, и в него нужно было встроить отдельный контур для абонентов нового оператора: чтобы их сообщения распознавались, маршрутизировались и тарифицировались по собственным правилам, никак не задевая при этом основной трафик. Требование звучало жёстко: платформа остаётся одна, а приём и доставка сообщений для каждого оператора идут независимо друг от друга, и происходящее у одного не должно отражаться на другом. Наша команда донастроила сигнальный стек и протокол Diameter, логику определения сети получателя с учётом переносимости номера, параметры адресации нового операторского контура, обмен с системой тарификации оператора-хоста и отдельную бизнес-логику защиты от спама для каждого оператора. Часть этих наработок оказалась достаточно универсальной, чтобы применять её и в следующих похожих запусках, а не переписывать каждый раз заново.
Отдельного внимания в этом проекте заслужила часть, не связанная напрямую с трафиком: интеграция потребовала сопряжения на стыке двух инфраструктур с разными протоколами сигнального взаимодействия. Работа над этим узлом велась внутри защищённого контура заказчика, и обычного удалённого доступа для этого оказалось недостаточно. Заказчику было важно контролировать, кто именно и с какого устройства заходит в его технический периметр, поэтому инженер, который занимался этой частью, был официально оформлен в штат заказчика, подписал NDA и получил корпоративный ноутбук, через который вёл всю работу внутри чужой инфраструктуры.
Абонент нового оператора ничего из этого не видит. Но для тех, кто сам планирует подобный запуск, в этой истории есть практический вывод: техническая часть интеграции обычно предсказуема и хорошо укладывается в оценку сроков, а вот согласование доступа и требований безопасности заказчика часто остаётся за скобками планирования и в итоге сдвигает даты сильнее, чем любая техническая сложность. В Связьком мы закладываем это в оценку проекта заранее: если интеграция подразумевает работу внутри защищённого контура заказчика, в план идёт не только время на настройку платформы, но и время на оформление доступа и согласование требований безопасности с самого начала.
Если вы рассматриваете запуск виртуального оператора на своей сети или подключение к действующей платформе нового операторского контура, у нас есть отработанный подход к таким интеграциям, и мы готовы обсудить конкретную задачу.
