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

Справочник абонентов

Первый вопрос, который необходимо осветить в контексте разговора о СОРМ3 - организация хранения персональных данных абонентов. Справочник параметров договора биллинга позволяет гибко настроить тот набор, который необходим оператору для организации работы с абонентом. Однако понятие минимального набора обязательных параметров никак биллингом не регламентируется. Это приводит к тому, что нет унифицированного способа получения обязательных данных по абоненту. Об обязательных параметрах мы поговорим далее.

В технической документации к решениям СОРМ 3 есть так называемые структурированные и неструктурированные поля для выгрузки данных. Первые, как следует из названия, разделены по смысловой нагрузке на атомарные единицы, хранящие в себе строго определенные данные. Вторые - это большие строки произвольной длины, в которых, в общем случае, может быть записано что угодно и как угодно. Да, формально, можно сказать, что необязательно хранить данные в биллинге структурированно, ведь есть поддержка неструктурированных данных. Но опыту работы с УФСБ разных регионов операторам приходится приводить свои данные в структурированный вид. К таким данным можно отнести следующее:

ФИО абонента
Сведения о документе, удостоверяющем личность
Адрес регистрации (для физических лиц)
Юридический адрес (для юридических лиц)
Адрес установки конечного абонентского оборудования

Рассмотрим каждый вид более подробно.

ФИО абонента.

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

Сведения о документе, удостоверяющем личность

К документам, удостоверяющим личность можно отнести следующие документы:

Паспорт гражданина РФ
Заграничный паспорт
Паспорт СССР
Удостоверение военнослужащего
Паспорт иностранного гражданина
и другие, установленные законодательством РФ

Важное замечание! Водительское удостоверение не является документом, удостоверяющим личность.

Характеристики документов, удостоверяющих личность, которые рекомендуется хранить по отдельности:

серия документа, удостоверяющего личность
номер документа, удостоверяющего личность
дата выдачи документа, удостоверяющего личность
кем выдан документ, удостоверяющий личность

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

Адреса регистрации для юридических и физических лиц, а также адреса установки конечного абонентского оборудования

Рекомендуется хранить в структурированном виде с использованием параметра типа Адрес. Список обязательных полей для адреса:

почтовый индекс
страна

область/регион
район, муниципальный округ
город/посёлок/деревня/аул
улица
номер дома
корпус адреса
квартира/комната/офис/помещение

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

Список обязательных полей

Для физических лиц рекомендуется хранить следующий минимальный набор параметров

ФИО (структурированно)
Данные о документе, удостоверяющем личность (структурированно)
Адрес регистрации (структурированно)
Адрес установки оконечного оборудования (структурированно)
Дата рождения (поле типа дата)

Для юридических лиц рекомендуется хранить следующий минимальный набор параметров

Полное наименование юридического лица (текстовое поле)
Юридический адрес (структурированно)
Адрес установки абонентского оборудования (структурированно)
ИНН юридического лица
Банк, в котором у юридического лица расположен расчетный счет для взаиморасчетов с оператором (текстовое поле)
Номер расчетного счета
ФИО контактного лица (текстовое поле, структурировать не нужно)
Контактные данные контактного лица (текстовое поле, содержащее телефон)

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

Платежи абонентов

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

Справочные данные

К справочным данным можно отнести следующую информацию:

Номенклатура тарифов
IP-ресурсы
Типы платежей
Коммутаторы

Далее рассмотрим некоторые особенности.

IP-ресурсы

Рекомендуется заполнять периоды действия для ресурсов - по мере добавления новых диапазонов добавлять дату добавления.

Также рекомендуется не смешивать в одной категории белые и серые ip-ресурсы.

Коммутаторы

В данном случае под коммутаторами понимаются устройства модуля Inet, nas'ы модуля Dialup, Voiceip, Phone. Аналогично ip-ресурсам рекомендуется выставлять дату начала действия устройства.

Зачастую требуется выгружать физический адрес установки коммутатора. В случае использования модуля Inet, например, можно использовать параметры устройства, в котором завести адресный параметр.

Зеркалирование flow/radius-потоков.

Решения СОРМ 3 требуют зеркалировать flow/radius потоки на их железо для дальнейшей привязки к выгруженным справочникам данных. Это можно делать напрямую с оборудования оператора. Необходимо следить за тем, чтобы в radius/flow-данных были те идентификаторы (логины, адреса), которые выгружаются в справочниках, чтобы решение СОРМ 3 могло соотнести между собой эти данные.