Что такое OSS-платформа и какие задачи она решает

У любого оператора связи есть две стороны. Первая обращена к клиенту — договоры, тарифы, счета, обращения в поддержку. Вторая обращена к сети — оборудование в стойках, свободные порты, каналы, аварии на магистрали. Клиентскую сторону обслуживает BSS, техническую — OSS.

Что такое OSS простыми словами

OSS расшифровывается как Operations Support System — система поддержки операций. Класс программного обеспечения обслуживает техническую сторону работы оператора связи, то есть сеть, оборудование, ресурсы и процессы их выделения абонентам.

Проще говоря, OSS отвечает на четыре вопроса:

• что у оператора есть физически
• кому эти ресурсы выделены
• работает ли все исправно
• что нужно сделать, если сломалось

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

Разница между OSS и BSS 

Задачи оператора распадаются на две группы. Коммерческие — договоры, тарифы, счета, обращения в поддержку. Технические — кабели, порты, каналы, аварии. Первую группу обслуживает BSS, вторую — OSS. 

К BSS относится:

• биллинг и тарификация;
• CRM и абонентское обслуживание;
• продуктовый каталог;
• управление заказами со стороны продаж;
• расчеты с дилерами и партнерами.

К OSS относится:

• инвентаризация сетевых ресурсов;
• активация и провижининг услуг;
• мониторинг аварий и производительности;
• управление инцидентами и нарядами;
• сбор и предварительная обработка технических данных.

Граница условная, и на практике модули пересекаются. Управление заказами существует в обеих плоскостях — коммерческий заказ рождается в BSS, а техническая его часть исполняется в OSS. Именно поэтому системы почти всегда рассматривают как единый стек OSS/BSS.

Из чего состоит OSS-платформа

Состав модулей зависит от масштаба оператора и типа сети, но набор функциональных блоков обычно одинаковый. 

Инвентаризация сетевых ресурсов

Модуль хранит полную картину инфраструктуры. Оборудование, порты, номерная емкость, IP-адреса, каналы, оптические волокна, лицензии, а также логическая привязка ресурса к конкретной услуге и абоненту.

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

Активация и провижининг

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

Провижининг напрямую влияет на срок подключения. Ручная настройка растягивает процесс на дни, автоматическая укладывается в минуты.

Мониторинг аварий и производительности

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

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

Управление инцидентами и наряды на работы

Trouble Ticketing фиксирует проблему, назначает ответственного, ведет историю решения и контролирует сроки. Если проблема требует выезда, по тикету оформляют наряд, а система распределяет задачи между полевыми бригадами с учетом их загрузки и географии. 

В этом месте техника пересекается с клиентским обслуживанием. Абонент звонит в поддержку и жалуется, что пропал интернет, а на узле в это же время видна авария — речь об одном событии. 

Контроль качества и SLA

Обычно в договоре с корпоративным клиентом прописана доступность канала, например 99,9% в месяц. Это примерно 40 минут простоя, дольше — уже нарушение. Модуль считает фактические простои, сравнивает их с нормативом и по итогам периода показывает, уложился оператор в обязательства или нет. Если не уложился, система дает основание для перерасчета.

Сбор и предварительная обработка данных

Медиация, или предбиллинг, собирает записи о потреблении услуг, проверяет их корректность, приводит форматы к единому виду и передает дальше — в биллинг, аналитику или системы отчетности.

Но источников у оператора десятки. Коммутаторы отдают файлы со звонками, оборудование пакетной сети — объемы трафика, телевизионная платформа — данные о просмотрах. Каждый вендор использует свою структуру файла и свои единицы измерения, где-то трафик в байтах, где-то в килобайтах, где-то длительность звонка округлена до секунды, а где-то нет. Медиация сводит все к одному формату

OSS за пределами телекома

Логика операционного контура давно вышла за границы связи. Ресурс, его выделение потребителю и контроль состояния — задача многих отраслей.

Где применяют похожие решения:

• энергетика и водоснабжение, где считают приборы учета и обслуживают сети;
• кабельное и спутниковое телевидение;
• дата-центры и облачные провайдеры;
• транспортные компании с распределенной инфраструктурой;
• крупные предприятия с собственными сетями связи.

Отраслевая специфика меняет справочники и метрики, но архитектура остается прежней.

Чем зрелая платформа отличается от набора систем

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

Признаки, по которым отличают целостное решение:

• единая модель данных, где ресурс описан один раз;
• сквозной статус заказа от продажи до активации;
• открытые API вместо файловых выгрузок между системами;
• корреляция событий, а не поток разрозненных алертов;
• возможность добавить новый тип оборудования без правки ядра;
• прослеживаемость каждой операции для разбора инцидентов.

Разрозненный ландшафт держится, пока абонентов немного и услуги однотипные. Но с расширением деятельности компании, каждая новая услуга требует отдельной доработки в четырех местах.

Что меняется в OSS сейчас

Архитектура операционных систем меняется вслед за сетями. Раньше ресурс всегда имел физическое воплощение — плата в стойке, порт, отрезок оптики. Теперь маршрутизатор или межсетевой экран разворачивают программно на обычном сервере за минуты и точно так же удаляют, когда нужда отпадает. Инвентарь из-за этого меняет назначение. Он ведет учет не только оборудования, которое можно потрогать, но и виртуальных функций. 

Основные направления развития:

• переход от монолитов к микросервисам и контейнерам;
• открытые API вместо проприетарных интеграций;
• автоматизация типовых операций без участия оператора;
• предиктивная аналитика, которая прогнозирует отказы по динамике показателей;
• миграция на отечественный стек и российские СУБД;
• сближение OSS и BSS в единый цифровой контур.

Компания «айФлекс» с 2005 года разрабатывает интеграционные платформы, системы управление заявками, маршрутизации трафика LCR, другие компоненты операционного и бизнес-контура для операторов связи, банков и промышленных предприятий. Общий вектор очевиден — платформа должна меняться быстрее, чем меняются услуги оператора, иначе она будет тормозить бизнес.