The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Принципы разработки биллинговой системы (billing isp)


<< Предыдущая ИНДЕКС Правка src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: billing, isp,  (найти похожие документы)
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) за конструктивные замечания по теме статьи. Den aka Diesel © 2005

<< Предыдущая ИНДЕКС Правка src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, wsx, 09:32, 22/11/2005 [ответить] [смотреть все]
  • +/
    Уже много лет занимаюсь разработкой Биллинговых систем высокого класса с интеграцией в различнейшие структуры - ISP, CallCenter's, ....
    Однако, ИМХО это всё ВОДА. нет реальных советов. Общий обзор так сказать...
     
     
  • 2.5, Михаил, 11:51, 25/11/2005 [^] [ответить] [смотреть все] [показать ветку]
  • +/
    Почему бы тогда Вам не написать нечто подобное, но уже с реальными советами Дум... весь текст скрыт [показать] [показать ветку]
     
  • 1.2, RifleMan, 10:30, 23/11/2005 [ответить] [смотреть все]  
  • +/
    дочитал до :
    В худшем  случае для каждого из типов услуг прийдется разрабатывать свой
       коллектор, но если повезет - что-то удастся унифицировать. Технологии,
       которые могут помочь при создании коллекторов - SNMP, Radius, NetFlow.

    Дальше читать не стал.... зачем было время тратить писать сие чудо - если ничего реально не предложено ?!

     
  • 1.3, wsx, 10:32, 23/11/2005 [ответить] [смотреть все]  
  • +/
    Скорее всего это статья подойдёт для самых-самых зелёных. Так сказать новичков. Я как бы уже смотрю со своей коллокольни и поэтому не могу оценить статью в полной мере..
     
  • 1.4, morg, 18:36, 23/11/2005 [ответить] [смотреть все]  
  • +/
    нормальная статья, расказывает что такое биллинг. раскрывает общие понятия.
     
  • 1.6, SinGle, 08:23, 03/12/2005 [ответить] [смотреть все]  
  • +/
    Зря пинаете, пишу сейчас дипломку на похожую тему и такая информация мне, например, пригодится.
     
     
  • 2.12, Award, 07:24, 27/12/2005 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Привет тоже диплом связан с биллингом,я только начал этим заниматься, можеш сказ... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.13, wsx, 10:36, 27/12/2005 [^] [ответить] [смотреть все]  
  • +/
    Я занимаюсь разработкой концепции, так же принимаю решения об используемых среда... весь текст скрыт [показать]
     
     
  • 4.16, Award, 09:00, 28/12/2005 [^] [ответить] [смотреть все]  
  • +/
    ни когда не пытались расписать схему внедрения биллинга с помощью стандарта IDEF... весь текст скрыт [показать]
     
  • 3.14, Роман Парубенко, 10:51, 27/12/2005 [^] [ответить] [смотреть все]  
  • +/
    Я дипломов не пишу Просто работаю сисадмином Биллинг пытался делать по всяком... весь текст скрыт [показать]
     
     
  • 4.15, wsx, 10:58, 27/12/2005 [^] [ответить] [смотреть все]  
  • +/
    Сбор данных о трафике - это всеголишь малая и не основная часть биллинговой сист... весь текст скрыт [показать]
     
     
  • 5.17, Award, 12:00, 28/12/2005 [^] [ответить] [смотреть все]  
  • +/
    извини ты не сталкивался с описанием внедрения биллинга с точки зрения стандарто... весь текст скрыт [показать]
     
  • 3.21, Slash, 00:24, 06/11/2006 [^] [ответить] [смотреть все]  
  • +/
    начал работу над курсовой (читай - дальше диплом) по биллинговым системам в GSM компаниях. Если могёш помочь информацией, то не откажусь от таковой :)
     
  • 1.7, Роман Парубенко, 15:40, 03/12/2005 [ответить] [смотреть все]  
  • +/
    Прочитал - прослезился.
    Содержание статьи в точности соответствует моим планам, мыслям и, не побоюсь этого слова, мечтам.
    Я ведь тоже не первый год страдаю, создавая свое средство биллнга. Мои выводы после страданий в точности совпадают с содержанием статьи. Одна беда - статья мне не сообщила ничего нового. А вот начинающему (я кинул ссылку почитать товарищу), эта статья тоже мало чем помогла. Буквально к каждому абзацу он непонимающе задавал вопросы типа:"А это зачем?", "А что такое ...?", "А почему именно ...?".
    Мой вывод: статья на самом деле является четким прекрасным оглавлением к более углубленному описанию систем биллинга для начинающих.
    В любом случае - спасибо за проделанную работу.
     
  • 1.8, Коннел, 01:19, 11/12/2005 [ответить] [смотреть все]  
  • +/
    Автор, видимо, сам новичок в биллинговых системах вообще. Как только увидел в статье привязку к биллингу ИТ-услуг, то дальше читать не стал. Человек не знаком со всей областью, а лишь с 10%.
     
     
  • 2.9, Аноним, 11:20, 11/12/2005 [^] [ответить] [смотреть все] [показать ветку]  
  • +/
    Если биллинг не умеет учитывать стоимость прокладки кабеля, настройки рутеров кл... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.10, wsx, 11:56, 11/12/2005 [^] [ответить] [смотреть все]  
  • +/
    >>статье привязку к биллингу ИТ-услуг, то дальше читать не стал. Человек
    >>не знаком со всей областью, а лишь с 10%.
    >
    >Если биллинг не умеет учитывать стоимость прокладки кабеля, настройки рутеров клиентам и
    >прочие сопутствующие услуги, то это не биллинг, а простая считалка трафика.
    >


    В том то и дело, что понятие сервисов(услуг) должно быть абстрактным и представленным в виде объектов.
    На личном опыте могу сказать, что для описания сервисов очень удобно использовать XML. А корпорация Oracle сделала революцию в этой области реализовав "фичу" XQuery. К сожелению не многие могут себе позволить Oracle 10R2 :( Будем ждать аналогов от ОпенСурс сообщества.

     
     
  • 4.11, wsx, 12:28, 11/12/2005 [^] [ответить] [смотреть все]  
  • +/
    А вобще, есть желающие писать OpenSource Billing ? Давно есть такая мысля, но людей нет :( Всё, что я проектировал было комерчискими проектами и имели ограничения на воображение.. :(
     
     
  • 5.18, Vades, 05:57, 22/02/2006 [^] [ответить] [смотреть все]  
  • +/
    а зачем он нужен OpenSource ?
     
  • 4.22, c0smic, 10:19, 09/01/2007 [^] [ответить] [смотреть все]  
  • +/
    Если говорить о встраивании в СУБД поддрежки XQuery, то можно смотреть не только в сторону Oracle... Не понимаю в чем проблема использовать XQuery в стороне от СУБД? Если денег не хватает, можно использовать XQuery как он есть на самом деле, прямо из XML и XSL схем, а данные хранить в базе в сыром XML (а оно нам надо?)...
    Вот тебе бесплатное решение от Microsoft - SQL Server 2005 Express, там тебе в нагрузку еще и Reporting Services перепадут и средства разработки, так сказать, наша радость была бы неполной... Но высоченной производительности от экспреса ожидать не стоит, хотя для фронт-энд решения, лично для меня, это самый аппетитный продукт.
     
  • 3.19, Hbn, 16:37, 17/04/2006 [^] [ответить] [смотреть все]  
  • +/
    Хочу. Такую систему, которая будет учитывать стоимость (а может, и технологию сразу???) прокладки кабеля (а с ГИСом она не завязана? А кабель какой???), неплохо бы еще и весь документооборот, начиная с создания (расчета) коммерческого предложения... Слабо???
    Дайте ссылочку на такую биллинговую систему. А что, может и купим. Нафиг горбатиться, когда есть такие монстры...
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor