Event-driven telecom: почему ночные выгрузки больше не подходят к бизнесу 2026

Откуда взялась ночная выгрузка

В середине 2010-х архитектура операций телекома в регионе строилась так. Биллинг, CRM, аналитика, маркетинг, retention — каждая система имела свою базу. Связь между ними — ночные выгрузки. Биллинг по утрам сбрасывает данные за прошлый день в DWH, маркетинг видит свежие цифры на следующий день, retention — через 24-48 часов.

Этот подход был адекватен задачам того времени. Большая часть бизнес-решений принималась на ежемесячных циклах. Кампания планировалась за неделю, сегмент выгружался из DWH за день до запуска — этого хватало.

К концу 2020-х ситуация изменилась. Решения, которые требуются в 2026, оперируют другими горизонтами:

Anti-fraud. SIM swap должен быть детектирован в момент, не через 24 часа — за это время мошенник уже может вывести деньги.

Anti-scam. Паттерн мошеннических звонков должен распознаваться в течение секунд, не часов — иначе блокировка не помогает.

Компенсация за качество сети. Если у клиента сейчас плохое качество, сигнал к коммуникации должен прийти в течение минут, не на следующий день, когда инцидент уже завершился.

Real-time NBA. Когда клиент в приложении, рекомендация должна учитывать его действия секунду назад, не вчерашний batch.

Trust-сигналы для партнёров. Банковский партнёр запрашивает сигнал о статусе SIM — нужен в реальном времени, иначе банковская транзакция уже проведена.

Все эти требования не реализуются на batch-архитектуре. Нужна событийная модель.

Что значит event-driven предметно

Событийная архитектура не означает «всё в реальном времени». Она означает следующее:

Каждое значимое событие в системах оператора публикуется в общую event bus в момент, когда происходит. SIM активирована — событие. Платёж прошёл — событие. Изменение тарифа — событие. Жалоба заведена — событие. Network-инцидент в локации — событие. Всё это публикуется в момент.

Любая downstream-система может подписаться на нужные ей события и реагировать. Anti-fraud подписывается на события SIM и устройства. Маркетинг — на аномалии использования. Retention — на сигналы оттока. CRM — на взаимодействия с клиентом.

Реакция на событие может быть в реальном времени или с задержкой — это определяется требованием каждого consumer. Anti-fraud — миллисекунды. Маркетинг — минуты. Отчётность — часы. Не всё в реальном времени, но всё знающее о событиях.

Каждое событие — неизменяемая запись с timestamp, источником, payload, correlation ID. Это позволяет аудит, повтор, отложенную обработку.

Где обычно начинается build

Не «сразу всё переводим на event-driven». Это путь, который занимает 2-3 года. Поэтапный подход.

Месяцы 1-6. Фундамент. Event bus как инфраструктурный компонент. Стандарты для событий (схема, формат, гарантии). Выявление 5-7 наиболее критичных типов событий для старта.

Месяцы 7-12. Первые producer’ы. События SIM и устройства из core-систем. События взаимодействия с клиентом из CRM. Биллинговые события. Часто это серьёзная работа — legacy-системы нужно либо изменять, либо обернуть в адаптер.

Месяцы 13-18. Первые consumer’ы. Anti-fraud подписан на события SIM. Маркетинг — на события использования. NBA — на события поведения клиента. Real-time use case начинают работать.

Месяцы 19-24. Расширение и operating model. Дополнительные типы событий. Дисциплина SLA. Мониторинг потока событий. Replay для отказоустойчивости.

Месяцы 25-36. Устойчивая модель. Большинство операций интегрировано через события, batch-загрузки только для исторических отчётов.

К трём годам у оператора рабочий событийный фундамент. Это не «один проект» — это перестройка способа, которым работают операции.

Что часто становится барьером

Legacy-системы, не поддерживающие публикацию событий. Старый биллинг написан без понятия событий. Чтобы он начал публиковать события, нужны либо патчи к биллеру (что часто вендор не разрешает), либо внешние адаптеры, которые читают логи биллера и преобразуют в события. Оба варианта несовершенны.

Vendor lock-in. Вендоры core-систем могут не быть готовы к event-интеграции. Некоторые требуют использовать свой проприетарный слой интеграции вместо стандартной event bus.

Операционная дисциплина. Событийная модель требует другого operations mindset. Если команда привыкла «выгрузки утром есть — значит система работает», переход к мониторингу потока событий требует обучения.

Стоимость. Инфраструктура event bus плюс модернизация core-систем плюс сборка адаптеров плюс обучение — серьёзная инвестиция. Совет директоров часто требует ROI, который не очевиден до того, как первые real-time use case заработают.

Навыки. Событийный инжиниринг — отдельный набор навыков. Локальный talent в регионе ограничен. Либо инвестировать в обучение, либо нанимать с премией.

Что часто идёт не по плану

Сборка event bus без commitment к event-driven operations. Bus есть, но команды продолжают работать через batch — bus недоиспользуется.

Миграция всего сразу. Big-bang-переход редко работает. Поэтапно по типам событий и по типам consumer — единственно стабильный путь.

Вендор обещает «event-driven из коробки», но реально предоставляет batch с короткими циклами. Различие критичное — спрашивайте технические детали, не презентацию.

Event schema без дисциплины. Каждая команда создаёт свои события со своей схемой, без общего стандарта. Через год — сотни типов событий, нет когерентности между системами.

Без replay capability. События идут в реальном времени, но если consumer падает, события потеряны. Без durable event log отказоустойчивость не работает.

Когда event-driven не приоритет

Если организация в острой фазе базовой операционной стабильности (биллинг ненадёжен, реконсилиация плохая), фокус на стабильности core важнее.

Если real-time use case пока не критичны (anti-fraud управляем, маркетинг на месячном цикле работает приемлемо), event-driven build даёт мало немедленной отдачи.

Если бюджет ограничен на 18-24-месячную инвестицию без видимого ROI в первый год, build будет отменён в первой фазе.

Если внутренние навыки слабы и наём невозможен, event-driven превращается в дорогую вендорскую консультацию.

Если C-level не committed на operations-трансформацию, build остаётся технологическим без операционных изменений.

Что обсудить на committee

Какие 3-5 use case требуют real-time прямо сейчас или в обозримые 18 месяцев? Это и есть business case.

Какова текущая архитектура core-систем — поддерживают ли публикацию событий? Какой пробел?

Кто owner трансформации архитектуры? Если просто IT — проекты не затрагивают операции.

Какой 24-36-месячный инвестиционный commit нужен и есть ли он?

Какова кооперация со стороны вендоров core-систем? Если несовместима — это ключевой блок.

Что может сделать SamaraliSoft

Event-Driven Architecture Transformation — анализ текущей архитектуры, маппинг бизнес-требований к событийным фундаментам, дизайн event bus и стандартов схем, оценка вендоров для интеграции core-систем, поэтапный roadmap с явными контрольными точками и пилот первого real-time use case в течение 6-9 месяцев.

Внутренние ссылки

• /architecture/telecom-around-core-architecture/ — слой вокруг BSS/OSS
• /insights/telecom-subscriber-intelligence-operating-model/ — operating model
• /insights/telecom-sim-swap-banking-fraud/ — fraud в реальном времени
• /insights/telecom-anti-scam-layer/ — anti-scam в реальном времени

Источники

• Министерство цифровых технологий — телеком инфраструктура УЗ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — рынок телекома
• ЦБ РУ — биометрическая верификация digital banking
• MNP.UZ — портабельность