From: Денис Шергин <http://diesel.sherdart.net/>
Date: Mon, 21 Nov 2005 14:31:37 +0000 (UTC)
Subject: Принципы разработки биллинговой системы
Введение
Биллинговая система - программный комплекс, осуществляющий учет объема
потребляемых абонентами услуг, расчет и списание денежных средств в
соответствии с тарифами компании.
Не обязательно бежать писать свою биллинговую систему после прочтения
этого материала, вполне возможно, что эта информация поможет вам
сориентироваться и выбрать для себя биллинг из уже предлагаемых
решений (как коммерческих, так и некоммерческих), которых уже
понаделано достаточное количество. Однако, зная извечную склонность
системных администраторов (и линуксоидов в особенности) к изобретению
велосипедов, не исключено, что кто-то на базе этих рекомендаций
создаст биллинг своей мечты. Весомыми аргументами в пользу разработки
собственного биллинга являются цена коммерческих аналогов и
несовершенство некоторых широко распространенных решений среднего
ценового диапазона.
Итак, постараемся подумать над тем, как создать биллинг на базе Linux
и open source ПО.
Задачи
Чтобы спланировать внутреннюю архитектуру полнофункциональной
биллинговой системы, в первую очередь нужно выделить задачи, которые
она должна решать.
* сбор информации о потребляемых услугах (аккаунтинг)
* аутентификация и авторизация абонентов
* контроль денежных средств на счетах абонентов и списание средств в
соответствии c действующей тарифной сеткой
* пополнение счетов абонентов
* внесение изменений в тарифы
* предоставление статистики по операциям (клиентская и операторская
части)
Кстати, не стоит путать аутентификацию и авторизацию - это разные
понятия. Так, аутентификация - процедура идентификации пользователя
(обычно сводящаяся к проверке указываемых им данных на совпадение с
хранящимися в системе). Авторизация - процесс принятия решения о
правомерности доступа пользователя к какому-то конкретному ресурсу
(например, к файлу на диске или к определенной услуге связи).
Схема системы
Исходя из задач и запросов бизнеса, можно набросать схему системы.
Чтобы не обсуждать какого-то абстрактного сферического коня в вакууме,
будем рассматривать типовой пример оператора связи, продающего трафик
абонентам.
* коллекторы информации о потребленных услугах
* система аутентификации абонентов
* ядро (бизнес-логика)
* многоуровневая БД
* модуль авторизации
* модуль анализа типов трафика (локальный, пиринговый, etc)
* модуль разграничения доступа
* модуль статистики
* административный интерфейс для ручного управления абонентами
* интерфейс управления счетами абонентов и тарифами для отдела
продаж
Рис. 1. Структура биллинговой системы ISP
Основной принцип проектирования системы - строгая модульность, которая
в последствии позволит легко модернизировать отдельные компоненты
системы в зависимости от меняющихся задач бизнеса. Как в любой сложной
системе, придется искать компромисс между сверхуниверсальным комбайном
и узкоспециализированным решением.
Коллекторы
Услуги могут быть разными (например - VPN-доступ, dial-up пул, обычный
неинкапсулированный трафик, Proxy, VoIP, etc), надо обеспечить
доставку ядру системы в единообразном виде информации о том, какой тип
услуги, какой абонент, в каком объеме и в какое время потребил. В
худшем случае для каждого из типов услуг прийдется разрабатывать свой
коллектор, но если повезет - что-то удастся унифицировать. Технологии,
которые могут помочь при создании коллекторов - SNMP, Radius, NetFlow.
Многоуровневая база данных
Многоуровневая БД нужна для того, чтобы не работать все время с
массивами максимально детальной информации, т.к. это значительно может
снизить быстродействие всей системы.
Логично выделить 3 уровня:
1. максимально детализированная информация без какой-либо обработки
2. классифицированная и первично агрегированная информация
3. оперативная информация
База первого уровня может понадобиться для разрешения спорных моментов
с клиентами. Важно сохранять ее в исходном виде, т.к. возможно будет
необходимо постфактум произвести перерасчет выставленных к оплате
счетов с учетом скорректированных тарифов или, например, уточненных
границ сетей, по которым делится трафик.
Не для каждого сервиса можно получить детализированную информацию о
соединениях, но к этому надо стремиться. По крайней мере, при подсчете
трафика через Web Proxy это решается автоматически, использование
NetFlows тоже позволяет делать полную детализацию. Минусом является
значительный объем, требующийся для хранения всех этих данных. Однако,
т.к. эта информация нужна не очень часто, ее более логично хранить в
виде обычных файлов, а не в базе - это уменьшит нагрузку на ваш сервер
БД и является более компактным способом хранения.
База второго уровня компактнее, чем первая, поэтому ее можно хранить
за более продолжительный период времени. Например, после классификации
трафика можно не хранить информацию о локальном трафике, если за него
не взимается плата. Также с большой долей вероятности можно считать
одним соединением несколько соединений с одним и тем же хостом,
произошедшие в приблизительно одно время (типичная ситуация с
многопоточными сетевыми клиентами).
Оперативная информация - наиболее грубая по отношению к остальным двум
базам, но зато операции с ней можно совершать очень быстро, что
позволяет сократить время реакции системы, которое будет обсуждаться
ниже. На основе этой базы осуществляется принятие решений о
предоставлении или прекращении предоставления услуг конкретному
клиенту.
Бизнес-специфика
Если упустить некоторые пункты из нижеописанного на этапе
проектирования - потом возможно прийдется подвергать систему серьезной
модификации уже на этапе эксплуатации, что крайне нежелательно.
Основные технические требования, диктуемые бизнесом: гибкость,
точность расчетов, устойчивость к сбоям.
Учет перспективы
Задумайтесь над тем, какие с какими услугами ваш биллинг должен будет
уметь работать, при этом планируйте на будущее. Сегодня наиболее часто
считают трафик, но завтра могут возникнуть потребности в новых услугах
- платный контент, VoIP, веб-хостинг, что-нибудь еще.
Конечно, для малого бизнеса это не так актуально, но вполне вероятно,
что в перспективе у вас возникнет необходимость работать с платежами
по временным картам доступа.
Погрешность расчетов
Как показывает практика, учет трафика может работать с ненулевой
погрешностью, а при больших объемах потребления даже доли процента -
это уже значительные деньги. Чтобы застраховаться от подобных
неприятных особенностей, можно учитывать это в тарифах, хотя это уже
не технический вопрос.
Помимо всего прочего, есть еще паразитный трафик. Ничего с ним
поделать нельзя, нужно просто помнить о нем, если у вас много реальных
IP-адресов.
Если вы перепродаете трафик, не забудьте при расчетах о том, что ваш
головной ISP может под мегабайтом понимать вовсе не 1048576 байт, а,
например, 1000000, что в результате дает почти 5% расхождения.
Дополнительные проблемы могут составлять направления - некоторые
головные провайдеры выставляют счета за входящий трафик, некоторые -
за исходящий, а в ряде случаев учитывается превышающее направление.
Время реакции системы
Принятие решения о блокировке абонента при окончании средств на его
счету на практике происходит не мгновенно, этот факт тоже надо
учитывать. Например, если блокировка срабатывает раз в минуту - при
скорости соединения 1 Мбит/с абонент может скачать лишних 7,5 мегабайт
в худшем случае.
Устойчивость к сбоям
Биллинг считает деньги, поэтому нужно быть предельно аккуратным. При
сбоях (которые все равно будут, ничего идеального нет) система должна
по умолчанию блокировать доступ, т.е. политика "запрещено по
умолчанию". Естественно, жизненно необходима надежная система
резервного копирования данных. Помните, что стоимость дополнительного
дискового пространства зачастую намного меньше финансовых потерь,
связанных с утерей информации.
Актуальность данных
При классифицировании трафика необходимо следить за актуальностью
границ сетей, т.к. интернет - динамичная система. Можно использовать
актуальные копии статических списков сетей, с которыми у вашего
головного провайдера заключены пиринговые соглашения (и,
соответственно, трафик, связанный с ними, тарифицируется по-иному),
периодически скачивая их от ISP. Альтернативой может быть
использование протоколов динамической маршрутизации, например - RIP, с
помощью которых можно получать границы пиринговой сети (если ваш
головной ISP предоставляет такую услугу).
По отношению к тарифной сетке справедливо то же самое - ваша
билинговая система должна всегда производить расчеты, основанные на
актуальных для вашей организации тарифах.
Статистические отчеты
Помимо классического уже веб-интерфейса к статистической информации о
потребленных услугах и состоянии счета неплохо предоставлять клиентам
услугу рассылки наиболее важной для него информации на e-mail или
посредством SMS.
Отключение абонентов
Если для вашей организации приемлемым является предоставление услуг в
кредит, желательно предоставить каждому отдельному пользователю самому
принимать решение о том, будет ли он немедленно отключен при
исчерпании средств на счете, или же продолжит работать в кредит.
Тарифы
Сразу же желательно продумать систему задания тарифов, даже если вы
изначально занимаетесь всего лишь продажей трафика по одной
фиксированной цене. Технически эту задачу можно формализовать так:
тарифы должны рассчитываться в кусочно-линейной зависимости от
некоторого параметра - либо времени суток и дня недели, либо объема
уже потребленных абонентом услуг. При этом желательно, чтобы система
позволяла не очень технически грамотному персоналу управлять тарифными
планами.
Кроме этого, очень желательно хранить архив тарифов для возможности
восстановления счетов спустя время.
Бухгалтерия
Полезно подумать об интеграции вашего биллинга в общую бухгалтерию
вашей организации, например - с 1С или еще чем-то, что у вас
используется для этих целей.
При планировании структуры базы данных учтите тот факт, что у одного
абонента может быть несколько разных счетов (на разные услуги), и он
по идее должен иметь возможность либо объединять, либо изолировать их.
Еще довольно часто встречается ситуация, когда несколько разных
пользователей работают с одним счетом.
Система должна в идеале позволять работать в кредит.
Лицензирование
Если у вас 100% легальный бизнес, необходимо использовать только
сертифицированные в Министерстве связи РФ решения. Проблема в том, что
иногда они не доступны по цене, выбор их не богат, да и зачастую эти
решения далеки от идеала. В целом, вопрос с наличием лицензии на
биллинг каждый решает для себя сам.
Практический пример
Разберем теперь конкретные варианты технической реализации такой
системы. Например - биллинг для небольшой локальной сети, продающей
трафик.
Один из часто используемых способов простого учета трафика -
использование счетчиков iptables на пограничном маршрутизаторе. Плюсы
такого решения - простота и гибкость, возможность разграничения типов
трафика на уровне правил пакетного фильтра. Минусы - прийдется весь
трафик, который вы хотите учитывать, маршрутизировать через один PC,
что, в общем-то, не сильно критично при небольшой загрузке. В качестве
коллектора в таком случае может выступать небольшой PERL-скрипт,
анализирующий вывод iptables. При этом рекомендую использовать флаг
-Z, который обнуляет счетчики iptables после вывода их значений - так
вы избежите потенциально возможного переполнения счетчиков,
регистрируя лишь разницу между измерениями.
Рис. 2. Структура цепочек правил iptables
Модуль разграничения доступа, по сути, является простым скриптом,
модифицирующий набор правил файрвола, что в результате открывает или
закрывает доступ определенному клиенту.
В случае использования VPN (например, для продажи трафика это одно из
наиболее оптимальных решений, т.к. в сетях, построенных на дешевых
хабах без возможности Port Security, идентификация пользователя по IP
является крайне ненадежным решением) вполне логично интегрировать
модуль авторизации клиентов в скрипты /etc/ppp/ip-up и
/etc/ppp/ip-down, которые вызываются демоном pppd при подъеме и
опускании ppp интерфейса (а зачастую VPN-соединения представляют собой
по сути, соединения, использующие PPP как транспорт для
инкапсулированного трафика). Аналогичным образом можно организовать
авторизацию для dial-up соединений.
Завершает основную часть системы небольшой демон (или просто
программа, с определенной периодичностью вызываемая средствами crond),
который анализирует оперативную информацию и на ее основе принимает
решения об отключении абонентов, если у них на счету закончились
средства (в таком случае просто соответствующее правило файрвола
меняется на запрещающее). По сути, этот компонент и заключает в себя
основную часть бизнес-логики, т.к. именно он ответственен за
финансовые расчеты.
Модуль административного интерфейса и веб-статистики являются
достаточно тривиальными задачами, и их вряд ли стоит подробно
рассматривать. Единственное, на чем хочется акцентировать внимание -
это то, что эти модули должны быть разработаны с максимальным учетом
бизнес-спефики, которая обсуждалась выше.
Заключение
Если вы все же решили создать свою собственную биллинговую систему, то
пусть она всегда считает точно, не доставляя вам лишних хлопот.
Статья написана по материалам доклада на семинаре, посвященном
применению Linux и open source ПО, прошедшем 29.10.05 в г. Томске.
PS: автор благодарит TLUG (Tomsk Linux Users Group) за
конструктивные замечания по теме статьи.
Vova
