# Service Provisioning: как биллинг управляет оборудованием сети

Источник: https://fw-t.ru/articles/sistema-upravleniya-oborudovaniem-i-service-provisioning
Опубликовано: 2020-04-08 · Обновлено: 2026-09-15

Как решение биллинга становится командой на коммутаторе: плагины под оборудование, проверка выполнения, действия по расписанию и восстановление после сбоя.

**Коротко.** Service Provisioning переводит решение расчетной системы о состоянии услуги в команду на сетевом оборудовании и подтверждает результат. Между биллингом и коммутатором этот слой нужен потому, что набор команд свой у каждого вендора: без него расчетная система обрастает знанием о каждой модели оборудования и ломается при его замене.

Между решением расчетной системы и его исполнением на сети лежит работа, которую видно только когда она не сделана: абонент оплатил услугу, в биллинге она активна, а на коммутаторе ничего не изменилось.

Service Provisioning отвечает именно за этот участок. Состав продукта — на странице [Forward SP](/products/fw-sp).

## Что делает система

| Задача | Как решается |
| --- | --- |
| Перевод решения в команду | Целевое состояние услуги из биллинга превращается в набор команд для конкретной модели оборудования |
| Подключение оборудования | Плагины: библиотека из более чем двухсот и возможность писать свои |
| Контроль выполнения | Проверка результата каждой команды и журнал на стороне системы |
| Сбои | Заданный алгоритм при отказе: повтор, откат или эскалация |
| Массовые операции | Запланированные команды по расписанию для сегмента базы |
| Отладка | Предварительное тестирование команд до применения на живой сети |

## Почему это отдельная система

Первый коммутатор расчетная система обычно настраивает напрямую. Дальше появляется второй вендор со своим набором команд, третий — со своим синтаксисом и своей логикой подтверждения. Знание о парке оборудования оседает в биллинге, и замена железа на сети превращается в доработку расчетной системы.

Второй довод — ответственность за результат. Отправить команду мало, нужно убедиться, что она выполнена, и знать, что делать, если нет. Эта логика — повторы, откаты, эскалации, журнал — не имеет отношения к расчетам и в биллинге выглядит чужеродной.

## Что это дает поддержке

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

Отдельно стоит журнал: он отвечает на вопрос, что именно было сделано с услугой конкретного абонента и когда. Разбор жалобы без такого журнала превращается в реконструкцию событий по косвенным признакам.

## Граница с AAA-сервером

Рядом работает [Forward AMS](/products/fw-ams), и это разные задачи. SP меняет состав услуг, AAA-сервер — параметры доступа сессии. Первое происходит при изменении подписки абонента, второе — при каждом его подключении к сети.

## В проектах

Платформа работала в контурах [«Т-Мобайл»](/cases/project-tinkoff), [«Алма ТВ»](/cases/project-almatv) и [«Транстелеком»](/cases/case-ttk) — в каждом из них несколько типов оборудования и требование к тому, чтобы услуга включалась в момент оплаты, а не ночным регламентом.

## Вопросы и ответы

**Что делает Service Provisioning?**

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

**Зачем отдельный слой между биллингом и оборудованием?**

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

**Как подключается новое оборудование?**

Плагином. Библиотека Forward SP содержит более двухсот плагинов к оборудованию разных вендоров и проектные наработки. Заказчик может дополнять библиотеку самостоятельно, не обращаясь к вендору платформы, поэтому ввод нового типа оборудования не зависит от очереди на доработку.

**Что происходит при отказе оборудования?**

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

**Можно ли проверить команду до применения на живой сети?**

Да. Система позволяет предварительно протестировать результат выполнения команд и провести отладочные процедуры. Это особенно важно для составных команд со сложной логикой и для массовых операций: ошибка в них затрагивает сразу сегмент базы.

**Чем это отличается от AAA-сервера?**

Предметом. Service Provisioning меняет состав услуг на оборудовании: подключить, отключить, перенастроить. AAA-сервер управляет параметрами конкретной сессии абонента: кто подключился, что ему разрешено сейчас, сколько он потребил. Продукты работают в связке и обычно внедряются вместе.