Бизнес-сценарии и Оркестрация

Этот раздел описывает, как система управляет сложными процессами (Workflows), используя брокер сообщений (RabbitMQ) для асинхронного взаимодействия и устойчивости к сбоям.

Почему оркестрация, а не хореография? В ISP-домене бизнес-процессы (подключение, dunning, замена оборудования) затрагивают 4–8 сервисов, требуют строгого порядка шагов, таймаутов и компенсации. Хореография (чистый event-driven) быстро превращается в "спагетти событий", где невозможно понять, на каком шаге процесс и кто за него отвечает. Централизованный оркестратор (Saga Orchestrator) делает процессы наблюдаемыми, отлаживаемыми и воспроизводимыми. Этот подход используется в зрелых BSS-платформах (Hydra Billing Workflows, Splynx Scheduling, CSG Ascendon).

0. Принципы Workflows (чтобы оно не ломалось в реальности)

Сквозные процессы в телеком-домене почти всегда длительные: люди, выезды, ожидание оплаты, ретраи оборудования. Поэтому “просто вызвать 5 сервисов по HTTP” быстро превращается в хаос.

Ниже — практики, которые считаем обязательными:

• Correlation ID / Causation ID: каждое событие/команда несут correlationId (цепочка процесса) и causationId (кто породил).
• Идемпотентность: повтор команды/события не должен создавать “двойную активацию” или “двойной платёж”.
• Outbox / Inbox:
  • outbox гарантирует публикацию событий после коммита БД;
  • inbox (дедуп) гарантирует “обработали 1 раз” при повторной доставке.
• Retry policy: ретраи только для временных ошибок (timeout, lock, 5xx), с backoff и лимитами.
• DLQ + ручная обработка: нештатные кейсы не должны блокировать очередь и скрываться — они должны быть видимыми и разруливаемыми.
• Таймауты и дедлайны: шаг процесса имеет SLA/TTL (например, “резерв порта держим 48 часов”).
• Human-in-the-loop: шаги с выездом/складом/поддержкой моделируются как ожидание внешнего события (FSM/Ticket), а не как “висящий запрос”.

1. Оркестрация (OMS)

Мы используем централизованный оркестратор для координации длительных процессов. Его задача — держать состояние (state machine), управлять таймерами и инициировать команды, не залезая внутрь доменов.

OMS (Order Management System) — это центральная система управления заказами, которая:

• Хранит статус заказа (Created → InProgress → Completed/Failed) и историю шагов
• Управляет таймерами и дедлайнами (TTL резервирования ресурсов, SLA процессов)
• Отправляет команды в BSS/OSS через RabbitMQ для выполнения действий
• Обрабатывает события от микросервисов для переходов состояний
• Интегрируется с FSM для выездных работ

FSM (Field Service Management) — система управления полевыми работами:

• Планирование выездов: создание задач для монтажников/техников
• Управление складом: резервирование и выдача оборудования
• Мобильное приложение: для монтажников с навигатором и чек-листами
• Отчётность: фото/видео подтверждения выполненных работ
• Интеграция: сообщает OMS о завершении/проблемах через API

Статусная модель заказа (FSM)

Таймауты и дедлайны

Каждый шаг процесса имеет SLA/TTL. При истечении — автоматический переход или алерт.

// internal/oms/domain/order.go — пример TTL для шага
type OrderStep struct {
    Name      string
    Status    StepStatus
    StartedAt time.Time
    TTL       time.Duration
    Retries   int
    MaxRetries int
}

func (s *OrderStep) IsExpired() bool {
    return time.Since(s.StartedAt) > s.TTL
}

Saga: компенсация при ошибках

При ошибке на любом шаге OMS запускает компенсирующие действия в обратном порядке:

Дерево ошибок (Error Decision Tree)

Как OMS решает, что делать при ошибке:

2. Ключевые Процессы (Workflows)

Сценарий 1: Подключение нового абонента (Lead-to-Cash)

Этот сценарий демонстрирует полный цикл от заявки до активации услуги с участием OMS и FSM.

Нюансы (то, что обычно забывают):

• Резерв ресурсов: порт/слот/ONT/IP должны резервироваться с TTL и освобождаться при отмене/таймауте.
• Ветка “нет ресурсов”: если Inventory ответил “нет порта”, заказ должен уйти в Failed/WaitingExternal (расширение сети), а не зависнуть.
• Ветка “выезд не состоялся”: при FSM-ошибке оркестрация снимает резервы и закрывает заказ как Cancelled/Failed.
• Ветка “провижининг не применился”: Provisioning возвращает provisioning.failed → OMS либо ретраит (если это timeout), либо ставит в DLQ/ручную обработку.

Сценарий 2: Обработка платежа и включение (Unlock)

Внутри сервиса Billing & Finance происходит вся магия с балансами, а наружу улетает только команда на включение.

Нюансы:

• Идемпотентность webhook’ов: один и тот же платёж может прийти повторно — Billing должен дедуплицировать по paymentId/providerId.
• Разделяйте “приняли деньги” и “включили доступ”: включение — отдельный шаг, который может временно упасть (NAS недоступен).
• Прозрачный статус: для клиента важно видеть “Оплата получена, включаем доступ…” (и понимать, что это не мгновенно).

Сценарий 3: Блокировка за неуплату (Dunning)

Dunning — один из самых критичных процессов ISP. Ошибка здесь = заблокированный платящий абонент (churn) или бесплатно работающий должник (revenue leak). В зрелых системах (Hydra Billing, Splynx) dunning — это конфигурируемый multi-step pipeline с разными действиями на каждом шаге.

Ключевые бизнес-правила Dunning:

• Auto-resume: При поступлении оплаты, покрывающей задолженность, система автоматически снимает блокировку (CoA resume) без участия оператора. Задержка resume < 5 минут.
• Partial payment: Частичная оплата не снимает блокировку, но может отсрочить переход на следующий шаг dunning.
• VIP-клиенты: Для клиентов с пометкой VIP или с высоким LTV dunning-пороги увеличиваются (grace period).
• Юрлица: Для B2B-клиентов dunning-цикл длиннее (D+14 soft, D+30 hard, D+60 terminate), обязательна отправка актов сверки.
• Исключения: "Обещанный платёж" (promise-to-pay) — оператор может временно заморозить dunning на N дней.

Сценарий 4: Смена тарифа

1. Product Service: Проверяет совместимость.
2. Billing Service: Выполняет перерасчет.
3. Billing Service: Отправляет событие tariff.changed в RabbitMQ.
4. Provisioning: Слушает событие -> отправляет CoA на BRAS для смены скорости (Rate-Limit).

Нюансы:

• Effective date: тариф может вступать в силу “сейчас” или “со следующего биллингового периода”.
• Proration: перерасчёт/доначисление должны быть повторяемыми и аудируемыми.
• Компенсация: если CoA не сработал, у процесса должен быть fallback (ретрай/ручной тикет), но тариф в BSS уже поменялся — важно иметь “технический статус применения”.

Сценарий 5: Замена оборудования (RMA)

1. Техподдержка создает заявку в OMS/FSM.
2. Монтажник получает новое устройство.
3. FSM обновляет данные в Network Inventory.
4. Provisioning автоматически синхронизирует привязки в Access Control.

Нюансы:

• Разделяйте “логистику” и “доступ”: замена CPE может требовать ожидания склада/выезда, но доступ должен оставаться управляемым.
• Автосверка: после замены полезен reconcile-шаг: “сессия поднялась на новом устройстве? профиль применился?” (иначе тикет).

Ссылки по теме

• BSS-сервисы: Биллинг, CRM, продукты — BSS Layer.
• OSS-сервисы: Провижининг, AAA, инвентаризация — OSS Layer.
• Микросервисы: Каждый сервис подробно — Каталог сервисов.
• Доменные модели: ER-диаграммы и карта событий — Доменная логика.
• API: RabbitMQ-команды/события, Saga, Outbox — API-контракты.
• RADIUS: CoA при смене скорости/блокировке — Интеграция с RADIUS.
• Метрики: Провижининг, RabbitMQ queue depth, SLA/SLO — Observability.
• Термины: OMS, FSM, Dunning, Saga, DLQ — Глоссарий.