OSS Layer (Operations Support Systems)

Слой OSS отвечает за взаимодействие с сетью. Мы консолидируем сервисы для упрощения эксплуатации и снижения задержек при обработке сетевых событий.

Подход к проектированию: OSS-слой следует модели eTOM (enhanced Telecom Operations Map) от TM Forum — международного стандарта для операторов связи. В отличие от монолитных решений (BillMax, WHMCS), где сетевой функционал встроен в биллинг, наш OSS полностью отделён от BSS и взаимодействует через Protobuf-контракты и события. Это позволяет масштабировать сетевые компоненты независимо и поддерживать мультивендорную среду (Mikrotik, Huawei, Eltex, Cisco, Juniper).

Роль слоя OSS

OSS — это источник технической правды о ресурсах и доступе:

• Какие ресурсы есть (оборудование, порты, VLAN, IP-пулы, топология, ёмкость).
• Кому что выделено (какой порт/ONT/IP/login принадлежит какой услуге).
• Как сейчас работает доступ (сессии, профили, параметры, блокировки/редиректы).
• Что реально потреблено (usage: трафик, время, телеметрия, сетевые события).
• Какова утилизация сети (загрузка портов OLT, ёмкость BRAS, заполненность IP-пулов).

Если BSS отвечает на вопрос "что продано и оплачено", то OSS отвечает на вопрос "что фактически включено и как это работает в сети".

Взаимодействие BSS ↔ OSS

Ключевой принцип: BSS не знает, какое оборудование стоит у абонента, OSS не знает, сколько стоит услуга. Связь — только через события и команды:

Границы ответственности

• OSS делает:
  • техническое исполнение команд (активация/блокировка/смена параметров);
  • управление доступом (AAA/DHCP/session control);
  • учёт ресурсов и связей (inventory/IPAM/topology);
  • сбор и нормализацию usage/событий сети (mediation).
• OSS не делает:
  • расчёт денег, тарифов и скидок;
  • договорную модель клиента (это BSS);
  • бизнес-оркестрацию "сквозных" процессов (это OMS/Workflows).

Владение данными (технические сущности)

Стратегия провижининга: Desired State + Reconcile

Чтобы провижининг был устойчивым и повторяемым, полезно мыслить не "выполнили команду", а "привели сеть к желаемому состоянию". Этот подход заимствован из практик Infrastructure as Code (Kubernetes, Terraform) и адаптирован для телеком-оборудования.

• Desired State формируется из параметров услуги (из BSS/OMS) и технических политик.
• Reconcile loop регулярно сверяет desired state с фактическим состоянием и чинит расхождения (drift).
• Идемпотентность: повтор команды (из-за ретрая брокера или рестарта воркера) не должен ломать сеть — операции проектируются как "upsert".

Reconciliation: типичные drift-сценарии:

Ключевые сервисы

1. Network Inventory Service

Единый реестр физических и логических ресурсов.

• Объединяет функции:
  • Physical Inventory: Учет оборудования (OLT, Switch, Router) и клиентских устройств (CPE).
  • Logical Inventory (IPAM): Управление IP-адресами, VLAN, VRF, пулами.
  • Topology: Связи между портами и устройствами, uplink-цепочки.
• Цель: Знать всё о сети в любой момент времени.

ConnectRPC API (основные методы):

События (Exchange: isp.events.inventory): port.reserved, port.released, resource.exhausted, device.status_changed.

2. Access Control Service (AAA)

Единая точка управления доступом и сессиями.

• Объединяет функции:
  • AAA: Аутентификация, Авторизация, Аккаунтинг (FreeRADIUS).
  • DHCP/IPoE: Выдача адресов, Option82.
  • Session Control: Мониторинг активных сессий, CoA (Change of Authorization), сброс сессий.
• Взаимодействие: Напрямую работает с NAS/BNG оборудованием. Получает профили доступа от Provisioning.
• Ссылки: детали RADIUS/CoA и атрибутов — в разделе Интеграция с FreeRADIUS.

ConnectRPC API (основные методы):

3. Provisioning Service

Исполнитель команд на оборудовании. Ключевой сервис OSS-слоя.

• Функции: Преобразует высокоуровневые бизнес-команды ("Включить услугу") в вендор-специфичные команды (CLI, SNMP, Netconf, API).
• Интеграция: Слушает очереди RabbitMQ (команды от BSS/Orchestrator).
• Поддержка вендоров: Huawei, Cisco, Juniper, Mikrotik, Eltex.

Provisioning State Machine:

Vendor Adapter Pattern:

Каждый вендор оборудования реализует единый интерфейс. Provisioning Engine выбирает адаптер по device.vendor:

// internal/provisioning/adapter/adapter.go
// Vendor Adapter — интерфейс для вендор-специфичных операций.
type VendorAdapter interface {
    // ActivatePort включает порт и применяет параметры (скорость, VLAN).
    ActivatePort(ctx context.Context, device Device, port Port, params ServiceParams) error
    // DeactivatePort отключает порт.
    DeactivatePort(ctx context.Context, device Device, port Port) error
    // SetSpeed применяет ограничение скорости (Rate-Limit / QoS).
    SetSpeed(ctx context.Context, device Device, port Port, downloadMbps, uploadMbps int) error
    // GetPortStatus запрашивает фактическое состояние порта на устройстве.
    GetPortStatus(ctx context.Context, device Device, port Port) (PortStatus, error)
    // HealthCheck проверяет доступность устройства.
    HealthCheck(ctx context.Context, device Device) error
}

// internal/provisioning/adapter/huawei_olt.go
type HuaweiOLTAdapter struct {
    sshPool *sshpool.Pool
}

func (a *HuaweiOLTAdapter) ActivatePort(ctx context.Context, dev Device, port Port, params ServiceParams) error {
    session, err := a.sshPool.Get(ctx, dev.ManagementIP)
    if err != nil {
        return fmt.Errorf("ssh connect to %s: %w", dev.Hostname, err)
    }
    defer session.Close()

    commands := []string{
        fmt.Sprintf("interface gpon %s", port.Number),
        fmt.Sprintf("ont add %d sn-auth %s omci ont-lineprofile-id %d", port.ONTIndex, params.ONTSN, params.LineProfileID),
        fmt.Sprintf("ont internet-config %d ip-index %d", port.ONTIndex, params.IPIndex),
        "commit",
    }
    return session.RunCommands(ctx, commands)
}

// internal/provisioning/adapter/mikrotik.go
type MikrotikAdapter struct {
    apiPool *routeros.Pool
}

// internal/provisioning/adapter/eltex.go
type EltexAdapter struct {
    netconfClient *netconf.Client
}

Выбор адаптера (Factory):

// internal/provisioning/adapter/factory.go
func NewAdapter(vendor string) (VendorAdapter, error) {
    switch vendor {
    case "huawei":
        return &HuaweiOLTAdapter{}, nil
    case "mikrotik":
        return &MikrotikAdapter{}, nil
    case "eltex":
        return &EltexAdapter{}, nil
    case "cisco":
        return &CiscoAdapter{}, nil
    default:
        return nil, fmt.Errorf("unsupported vendor: %s", vendor)
    }
}

Практики надёжности:

• Дедупликация по commandId/orderId (inbox pattern).
• Ретраи только для "временных" ошибок (timeout/lock), не для "логических" (нет порта).
• DLQ + ручная обработка для нестандартных инцидентов.
• Каждая команда — идемпотентна ("upsert" семантика).

События (Exchange: isp.events.provisioning): provisioning.success, provisioning.failed, provisioning.rollback.

4. Mediation Service

Сбор и первичная обработка телеметрии.

• Функции:
  • Сбор Netflow / IPFIX / sFlow с маршрутизаторов.
  • Сбор RADIUS Accounting логов.
  • Агрегация и нормализация данных в единый формат UDR.
• Поток данных: Стриминг нормализованных UDR в RabbitMQ для биллинга и аналитики.
• Anti-Corruption Layer: Billing получает уже нормализованные данные через ACL, не парсит сетевые протоколы. Подробнее — Доменная логика: ACL.
• Зачем нужен отдельный слой: разгружает биллинг от парсинга сетевых протоколов и обеспечивает единый формат UDR/метрик для разных источников.

События (Exchange: isp.events.mediation): usage.recorded, session.accounting.

5. CPE Management (TR-069 / ACS)

Удалённое управление абонентским оборудованием.

• Протокол: TR-069 (CWMP) — стандарт для массового управления CPE.
• Функции:
  • Автоконфигурация новых устройств (zero-touch provisioning).
  • Массовое обновление прошивок.
  • Удалённая диагностика (Wi-Fi, скорость, перезагрузка).
  • Изменение настроек Wi-Fi (SSID, пароль) из ЛК абонента.
• Интеграция: ACS-сервер общается с CPE напрямую, получает команды от OMS/Support.
• Зачем: Снижает количество выездов монтажников и ускоряет решение проблем.

Reconciliation (сверка desired vs actual)

Ключевой механизм надёжности OSS — периодическая сверка желаемого состояния (из Product Context) с фактическим (на оборудовании):

Рекомендации:

• Запускать reconciliation по расписанию (каждые 4 часа) и по событию (после provisioning.success).
• Логировать каждый drift с деталями (expected vs actual) для post-mortem анализа.
• Метрика isp_reconcile_drift_total — ключевой индикатор здоровья provisioning.

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

• Микросервисы: Каждый OSS-сервис подробно — Provisioning, Inventory, AAA, Mediation.
• Доменные модели: ER-диаграммы OSS-сущностей (Device, Port, IP, RadiusProfile) — Доменная логика.
• Бизнес-процессы: Сквозные сценарии и интеграция с OMS — Бизнес-сценарии (Workflows).
• RADIUS: Детали аутентификации, CoA и атрибутов вендоров — Интеграция с FreeRADIUS.
• API: Protobuf-контракты, RabbitMQ exchanges, Outbox — API-контракты.
• Legacy маппинг: Как gpon_node/ip/mac/login декомпозируются из book_orders — Маппинг Legacy CRM.
• Метрики: RADIUS auth rate, сессии, provisioning duration — Observability.
• Безопасность: Защита RADIUS, Network Policies, mTLS — Безопасность.
• Оборудование: BRAS, OLT, FreeRADIUS, Kustomize — Технологический стек.
• Принципы: Repository Pattern, DDD, Vendor Adapter — Принципы архитектуры.