биллинговые системы: эффективная архитектура подсистем

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
БИЛЛИНГОВЫЕ СИСТЕМЫ:
ЭФФЕКТИВНАЯ АРХИТЕКТУРА
ПОДСИСТЕМ СБОРА И ОБРАБОТКИ ПТД
This article describes the flexible and effective subsystems of collecting and parsing Call Detail Records (CDR). Offered
solutions are based on many years experience of INOTECH Co. experts in area of development, introduction and installation
of billing systems.
ДМИТРИЙ КРИВЕНОК,
КОМПАНИЯ "ИНОТЕХ"
данной статье, являющейся продолжением цикла о комплексной
автоматизации бизнес-процессов оператора связи,
рассматривается организация надежной и эффективной подсистемы сбора и
обработки ПТД. Описанные
решения — результат работы специалистов компании "Инотех" в сфере разработки и внедрения биллинговых систем.
В
Современные биллинговые системы являются неотъемлемой частью единого информационного пространства предприятия (ЕИПП). К любой крупной биллинговой
системе сейчас предъявляются очень жесткие требования: надежность, функциональность, интегрируемость с
другими системами предприятия. Ввиду этого структура
биллинговых систем сильно усложнилась по сравнению
с первыми АСР. Сейчас нельзя представить АСР промышленного уровня без подсистем управления, мониторинга, интеграции, доставки документов, Web-подсистемы
и многих других. При этом ни одна биллинговая система
не может функционировать без подсистем сбора и обработки первичных тарификационных данных (ПТД).
Подсистемы сбора и обработки ПТД на первый
взгляд не кажутся сложными, однако именно от их правильной организации зачастую зависит скорость внедрения биллинговой системы в целом. Особенно актуально сказанное для малых и средних операторов связи.
В ЧЕМ СЛОЖНОСТЬ
Сложность внедрения систем ПТД связана с факторами, перечисленными ниже.
• Наличие большого количества источников ПТД
(ИПТД) от самых разных производителей. Сегодня у
операторов связи работают десятки источников ПТД от
различных производителей (например, АТС EWSD,
SI2000, Definity, NEC, Meridian, M-200, MD-110 и др.)
Такое разнообразие оборудования требует от подсистемы обработки ПТД высокой универсальности.
28
• Отсутствие унифицированного формата ПТД. Даже
в рамках конкретной модели ИПТД формат ПТД может
кардинально отличаться из-за различий в настройке
станции.
• Необходимость совместной работы с существующей биллинговой системой. При внедрении АСР, как
правило, выясняется, что новая система должна работать вместе со старой (по крайней мере какое-то
время).
• Очень жесткие требования к надежности и отказоустойчивости подсистем. Рассматриваемые подсистемы должны работать бесперебойно, так как в противном случае возможна необратимая потеря данных.
АНАЛИЗ РАЗЛИЧНЫХ АРХИТЕКТУР
Рассмотрим инфраструктуру среднестатистического оператора с точки зрения организации функционирования рассматриваемых подсистем АСР.
В простейшем случае эта инфраструктура состоит
всего из двух элементов: ИПТД и сервера биллинга.
ИПТД может непосредственно подключаться к серверу
биллинга (RS-232) или быть доступен через сеть.
Существуют два основных варианта построения архитектуры.
Объединение сбора и обработки ПТД
В данном случае подсистема на сервере биллинга
может представлять собой программу, в задачи которой входит:
• получение данных с ИПТД;
• препроцессинг полученных данных;
• закачка данных в базу данных биллинга для последующей тарификации;
• организация хранения ПТД.
Наш опыт показывает, что подобная архитектура
крайне ненадежна. Связано это прежде всего с тем, что
фактически в одной программе совмещены совершенно разнородные функции. Чем больше в системе звеньев, тем более она сложная и, как следствие, менее надежная. При таком подходе проблемы в звене препроцессинга могут стать причиной остановки сбора данных, что совершенно неприемлемо. Также усложняется
процедура замены программного обеспечения, так как
меняя одно звено, нужно менять и все остальные, что
влечет за собой остановку в сборе ПТД. И наверное, самый главный недостаток — невозможность повторной
обработки уже накопленных данных.
Однако у данного подхода есть и преимущества. Вопервых, данные "на лету" попадают в БД биллинга, что
особенно важно для систем реального времени (realtime). Во-вторых, отсутствуют проблемы разрывов записей о вызовах.
Разделение сбора и обработки ПТД
В данном случае на сервере должны работать несколько программ, выполняющих конкретные задачи. В
первую очередь это программа сбора ПТД — сборщик
(Receiver, Collector). К сборщику ПТД предъявляются
следующие требования:
• высокая надежность, стабильность и устойчивость
к ошибкам, так как ни при каких обстоятельствах сбор
данных не должен быть остановлен;
• возможность изменения конфигурации без остановки сбора ПТД — это свойство легко реализуется
средствами сигналов UNIX;
• простота.
Именно простота — основное достоинство сборщика ПТД, так как в его задачу входит сбор данных в течение заданного промежутка времени и запись этих данных в файл (с понятным и уникальным именем), и ничего более.
Следующий элемент — парсер (Parser) ПТД. К его
функции относится обработка CDR-файлов, собранных
сборщиком. Фактически парсер является преобразователем форматов. Он должен преобразовывать данные
из формата ИПТД в формат базы данных биллинга. Также должен быть предусмотрен режим преобразования
в формат, понятный для пользователя системы.
Сборщик и парсер — это элементы, которые работают независимо, однако логическая связь между ними
есть. Она реализуется универсальной подсистемой управления, в задачу которой входит организация обмена
CDR-файлами между сборщиком и парсером. Запуск
парсера инициируется благодаря данной подсистеме.
Также в задачу подсистемы управления входит организация надежного архива CDR-файлов.
Последним элементом описываемой архитектуры
является подсистема мониторинга, которая контролирует работоспособность сборщика и выдает разноплановую статистику. В случае возникновения проблем
подсистема мониторинга должна информировать администратора системы.
Подсистема мониторинга является достаточно
сложным элементом системы. В ее задачи входит:
• контроль работоспособности подсистемы сбора ПТД;
• анализ потока ПТД на предмет наличия аномалий;
• поиск ошибок в ПТД.
В реальных системах очень часто прослеживается
еще и защита на уровне БД (например, анализ дублирования данных), что делает систему еще более устойчивой.
Преимущества описанной архитектуры очевидны:
• простая реализация замены отдельных звеньев системы;
• простая реализация повторной обработки CDRфайлов;
• возможность закачки данных в базу данных биллинга почти "на лету";
• высокая надежность и мониторинг работы системы.
Описанные схемы являются до предела упрощенными
и ориентированы, прежде всего, на описание идеологических аспектов проектирования подсистем АСР. В реальности архитектура, как правило, несколько сложнее. Сбор,
обработка ПТД и собственно тарификация часто физически находятся на разных серверах, что является необходимым для обеспечения высокого уровня производительности системы, однако снижает общую надежность из-за наличия дополнительного звена — сети, по которой серверы
обмениваются данными. К ней предъявляются дополнительные высокие требования по отказоустойчивости, усложняя тем самым систему мониторинга.
Наш опыт показывает, что второй вариант построения
архитектуры практически лучше по всем показателям.
ВЫВОДЫ
В статье были предложены приемы, позволяющие
сделать подсистемы сбора и обработки ПТД более универсальными, расширяемыми и гибкими. Они могут
применяться не только в биллинговых системах, но и в
других элементах IT-инфраструктуры компании.
Главными достоинствами предложенной архитектуры являются надежность, отказоустойчивость, расширяемость, простота реализации и решение практически
всех проблем оператора. При использовании описанной технологии повышается скорость разработки, тестирования и внедрения подсистемы обработки ПТД.
29