СОРМ по приказу №573: что выгружать и почему выгрузка — не главное

Про СОРМ у операторов есть два разговора. Первый — с вендором о железе и договоре. Второй, менее заметный, — про данные: что именно провайдер обязан отдавать и в каком виде. Первый решается деньгами. Второй упирается в то, как в биллинге заполнены карточки абонентов, и решается только работой.

Эта статья про второй.

Из чего состоит выгрузка

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

Каждый файл имеет фиксированный набор колонок и формат значений: адреса приводятся к структуре, IP-адреса и маски записываются в шестнадцатеричном виде, даты — в своём формате. Ошибка в одной колонке делает файл непригодным целиком.

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

Где выгрузка ломается на самом деле

Самая частая ситуация выглядит обманчиво благополучно: задание отработало, файлы сформированы, отправка прошла. А внутри — пустые паспортные данные у трети абонентов, адреса, записанные строкой в комментарии, и юрлица, у которых не заполнены ИНН и КПП.

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

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

flowchart TD
  A[Карточки абонентов] --> B[Проверка готовности<br/>чего не хватает]
  B -->|списки на исправление| A
  B --> C[Формирование файлов<br/>по формату вендора]
  C --> D[Отправка на сервер<br/>по расписанию]
  D --> E[История выгрузок<br/>и уведомления]
  E -.->|сбой| F[Оповещение ответственному]

Формат — это данные, а не код

Вендоров СОРМ на рынке несколько, и набор файлов у них различается: где-то другое имя файла, где-то лишняя колонка, где-то свой разделитель. Исторически это решалось правкой кода под конкретного вендора — с очевидным следствием: смена вендора превращалась в доработку системы.

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

Здесь же уместна осторожность: автоматическое обновление таких пакетов по умолчанию лучше держать выключенным. Формат отчётности — не то место, где приятно обнаружить неожиданные изменения постфактум.

Расписание, история и уведомления

Выгрузка настраивается один раз и дальше должна работать без участия человека — но с обратной связью. Три вещи, без которых это не работает:

• Расписание. Регулярная отправка в заданное время, а не «когда вспомнили».
• История. Что и когда ушло, сколько файлов, сколько строк, чем закончилось. При проверке это первое, что понадобится.
• Уведомление о сбое. Не письмо в общий ящик, а сообщение конкретному ответственному. Сбой отправки, замеченный через месяц, — это уже не техническая проблема.

Несколько юрлиц

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

Чего система не делает

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

Как устроены отчёты, проверка готовности и вендорские пакеты — в документации.

Как это работает в СмИТ Биллинге

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

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

Формат вендора — это данные, а не код: профиль описывает разделители, кодировку и состав отчётов, поэтому переход на другой пункт съёма не требует доработки системы.

Схемы по теме все схемы →

Поток данных Выгрузка СОРМ