Миграция с UTM 5

Миграция из биллинга UTM 5 делается через промежуточный набор таблиц в формате DBF . Таблицы выгружаются из UTM с помощью специального скрипта на Python или Perl . Далее с помощью специального инструмента DBF-файлы загружаются в АСР «Гидра», где происходит сопоставление справочников и выполняется собственно миграция данных.

Упрощения и допущения

1. Юрлица и физлица находятся в одной таблице и отличаются только специальным признаком.
2. Из реквизитов юрлица выгружается только его название, остальное требует ручного ввода.
3. Текущий объём потреблённых услуг (трафик, минуты) никак не мигрирует, поэтому трафика включенным абонентам в момент миграции придётся накинуть как будто начался новый учётный период, но дата окончания текущего периода смигрирует, поэтому весь остаток трафика нужно будет потратить за время, оставшееся до этой даты.
4. Подробности тарифов (периодичность, пороги, единицы измерения, стоимость и т.д.) не мигрируют, а перебиваются вручную и затем сопоставляются. Системы тарификации в UTM и АСР «Гидра» отличаются слишком сильно, и автоматическая миграция при небольшом числе тарифных планов приведёт к бОльшим трудозатратам, нежели полуавтоматическая. То же касается и других небольших справочников, таких как классы трафика, валюты и т.д.

Проблемы

1. В UTM абонент может одновременно находиться в нескольких группах, тогда как в АСР «Гидра» — только в одной. Кроме того, в UTM с помощью групп сделаны многие настройки (разделение на физических и юридических лиц, привязка к файрволам и другому оборудованию). У нас это реализовано по-другому, нужно найти правильный подход.
2. Нужно разобраться, откуда лучше брать данные для привязки абонента к DHCP-серверу и файрволам. Можно, например, смотреть прямо по группе, к которой принадлежит абонент, а можно включить в привязки.

Таблицы, выгружаемые из UTM

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

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

Таблица STATUS

Если используется всего два состояния (включен, отключен), то смысла в справочнике нет. В таблицах, которые на него ссылаются, можно использовать просто отдельный столбец с признаком активности.

Справочник сетевых служб

Таблица NS_LIST

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

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

Таблица GROUPS

Справочник услуг и тарифных планов

Таблица SERVICES

Примечание: В этот справочник выгружаются все ТП, а из услуг только те, которые не входят в ТП, например, услуга "Реальный IP-адрес"

Справочник лицевых счетов

Таблица ACCOUNTS

Привязки абонента к сетевым службам

Таблица NETSERV

Примечание: В эту таблицу выгружаются логины и пароли на VPN, на личный кабинет, SIP-аккаунт и на другие ресурсы, которые контролирует биллинг. При этом в целях безопасности пароли при тестовых выгрузках нужно заменять на звёздочки или случайные строки. Настоящие пароли будут выгружаться всего один раз, при окончательной миграции.

Участие абонентов в группах

Таблица GROUPLINK

Подписка абонентов на услуги

Таблица SUBSCR

Оконечное оборудование абонентов

Таблица EQUIP

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

Таблица USERS

Примечание: Список атрибутов для личных данных абонента может быть расширен по необходимости.