В данной статье речь пойдет о том, как наилучшим образом организовать хранение данных абонентов, оборудования, ресурсов с точки зрения их дальнейшей выгрузки в информационные системы СОРМ 3. Все, что вы прочитаете далее, носит исключительно рекомендательный характер. Все положения основаны на реальном опыте взаимодействия с решениями СОРМ 3 от ведущих поставщиков соответствующих решений.
Справочник абонентов
Первый вопрос, который необходимо осветить в контексте разговора о СОРМ3 - организация хранения персональных данных абонентов. Справочник параметров договора биллинга позволяет гибко настроить тот набор, который необходим оператору для организации работы с абонентом. Однако понятие минимального набора обязательных параметров никак биллингом не регламентируется. Это приводит к тому, что нет унифицированного способа получения обязательных данных по абоненту. Об обязательных параметрах мы поговорим далее.
В технической документации к решениям СОРМ 3 есть так называемые структурированные и неструктурированные поля для выгрузки данных. Первые, как следует из названия, разделены по смысловой нагрузке на атомарные единицы, хранящие в себе строго определенные данные. Вторые - это большие строки произвольной длины, в которых, в общем случае, может быть записано что угодно и как угодно. Да, формально, можно сказать, что необязательно хранить данные в биллинге структурированно, ведь есть поддержка неструктурированных данных. Но опыту работы с УФСБ разных регионов операторам приходится приводить свои данные в структурированный вид. К таким данным можно отнести следующее:
- ФИО абонента
- Сведения о документе, удостоверяющем личность
- Адрес регистрации (для физических лиц)
- Юридический адрес (для юридических лиц)
- Адрес установки конечного абонентского оборудования
Рассмотрим каждый вид более подробно.
ФИО абонента.
Рекомендуется завести 3 отдельных текстовых поля, хранящих отдельно Фамилию, Имя, Отчество. Для удобства работы, если в качестве комментария договора выступает не ФИО, а какой-либо шаблонный номер, можно использовать дополнительное четвертое текстовое поле, в котором аккумулировать результат структурированных полей. Правда, для этого необходимо написать скрипт, который бы при наступлении события изменения параметра договора, формировал данные в этом сборном поле.
Сведения о документе, удостоверяющем личность
К документам, удостоверяющим личность можно отнести следующие документы:
- Паспорт гражданина РФ
- Заграничный паспорт
- Паспорт СССР
- Удостоверение военнослужащего
- Паспорт иностранного гражданина
- и другие, установленные законодательством РФ
Важное замечание! Водительское удостоверение не является документом, удостоверяющим личность.
Характеристики документов, удостоверяющих личность, которые рекомендуется хранить по отдельности:
- серия документа, удостоверяющего личность
- номер документа, удостоверяющего личность
- дата выдачи документа, удостоверяющего личность
- кем выдан документ, удостоверяющий личность
Рекомендуем завести отдельный списковый параметр, в котором перечислить все используемые оператором типы документов, удостоверяющих личность. Даже если в этом списковом параметре будет лишь одно значение - Паспорт РФ, это значительно поможет унифицировать и автоматизировать выгрузку справочника типов документов, удостоверяющих личность, потому что при добавлении нового значения не придется править скрипты для выгрузки.
Адреса регистрации для юридических и физических лиц, а также адреса установки конечного абонентского оборудования
Рекомендуется хранить в структурированном виде с использованием параметра типа Адрес. Список обязательных полей для адреса:
- почтовый индекс
- страна
область/регион
район, муниципальный округ
город/посёлок/деревня/аул
улица
номер дома
корпус адреса
квартира/комната/офис/помещение
Некоторые параметры адреса (например, регион, индекс) возможно хранить в качестве доп. параметров адресного параметра. Обращаем внимание, что не нужно при заполнении адресного справочника использовать сокращенные названия структурных единиц, которые обозначают данную часть адреса. Например: "г.", "ул.", "д." и т.п.
Список обязательных полей
Для физических лиц рекомендуется хранить следующий минимальный набор параметров
- ФИО (структурированно)
- Данные о документе, удостоверяющем личность (структурированно)
- Адрес регистрации (структурированно)
- Адрес установки оконечного оборудования (структурированно)
- Дата рождения (поле типа дата)
Для юридических лиц рекомендуется хранить следующий минимальный набор параметров
- Полное наименование юридического лица (текстовое поле)
- Юридический адрес (структурированно)
- Адрес установки абонентского оборудования (структурированно)
- ИНН юридического лица
- Банк, в котором у юридического лица расположен расчетный счет для взаиморасчетов с оператором (текстовое поле)
- Номер расчетного счета
- ФИО контактного лица (текстовое поле, структурировать не нужно)
- Контактные данные контактного лица (текстовое поле, содержащее телефон)
Рекомендуем все параметры, содержащие в себе дату (дата рождения, дата выдачи документа и т.д.), хранить в параметре типа Дата, а не в текстовом поле. Это связано с тем, что в выгрузках требуется выгружать даты в определенном формате, а при использовании текстовой строки в общем случае вообще невозможно распознать хранящуюся там дату.
Платежи абонентов
По-возможности рекомендуется максимально подробно сохранять дополнительную информацию по платежу в комментариях: номера счетов, коды транзакций, реквизиты документов и т.д.
Справочные данные
К справочным данным можно отнести следующую информацию:
- Номенклатура тарифов
- IP-ресурсы
- Типы платежей
- Коммутаторы
Далее рассмотрим некоторые особенности.
IP-ресурсы
Рекомендуется заполнять периоды действия для ресурсов - по мере добавления новых диапазонов добавлять дату добавления.
Также рекомендуется не смешивать в одной категории белые и серые ip-ресурсы.
Коммутаторы
В данном случае под коммутаторами понимаются устройства модуля Inet, nas'ы модуля Dialup, Voiceip, Phone. Аналогично ip-ресурсам рекомендуется выставлять дату начала действия устройства.
Зачастую требуется выгружать физический адрес установки коммутатора. В случае использования модуля Inet, например, можно использовать параметры устройства, в котором завести адресный параметр.
Зеркалирование flow/radius-потоков.
Решения СОРМ 3 требуют зеркалировать flow/radius потоки на их железо для дальнейшей привязки к выгруженным справочникам данных. Это можно делать напрямую с оборудования оператора. Необходимо следить за тем, чтобы в radius/flow-данных были те идентификаторы (логины, адреса), которые выгружаются в справочниках, чтобы решение СОРМ 3 могло соотнести между собой эти данные.