Уже много лет занимаюсь разработкой Биллинговых систем высокого класса с интеграцией в различнейшие структуры - ISP, CallCenter's, ....
Однако, ИМХО это всё ВОДА. нет реальных советов. Общий обзор так сказать...
Почему бы тогда Вам не написать нечто подобное, но уже с реальными советами. Думаю, что это было бы весьма интересно и полезно всем, кто пишет биллинговые системы.
дочитал до :
В худшем случае для каждого из типов услуг прийдется разрабатывать свой
коллектор, но если повезет - что-то удастся унифицировать. Технологии,
которые могут помочь при создании коллекторов - SNMP, Radius, NetFlow.
Дальше читать не стал.... зачем было время тратить писать сие чудо - если ничего реально не предложено ?!
Скорее всего это статья подойдёт для самых-самых зелёных. Так сказать новичков. Я как бы уже смотрю со своей коллокольни и поэтому не могу оценить статью в полной мере..
>Привет тоже диплом связан с биллингом,я только начал этим заниматься, можеш сказать
>чем именно ты занимаешся.
>Заранее Спасибо!
>Award
Я занимаюсь разработкой концепции, так же принимаю решения об используемых средах разработки, технологиях. Большую часть времени пиннаю других программеров. Ну и иногда беру определённую часть програмного обеспечения на собственную реализацию..
Разработка биллинговых систем - достаточно сложная задача, т.к. сейчас биллинг должен спокойно работать с нагрузками не менее, чем 200 000 абонентов.(Это и интернет, телевидение, VoIP, IPTV, Media-Intranet-Traffic, VideoConf...)
>Привет тоже диплом связан с биллингом,я только начал этим заниматься, можеш сказать
>чем именно ты занимаешся.
>Заранее Спасибо!
>Award
Я дипломов не пишу. Просто работаю сисадмином.
Биллинг пытался делать по всякому. Начал с учета траффика.
Пытался ставить готовые программки. Ни одна не работала так, как мне надо.
Тогда разобрался поглубже с iptables и сделал свою считалку траффика.
Пока она меня устраивала, но сейчас думаю все-таки приобщаться к стандартным методам сбора статистики - изучаю SNMP.
И еще сейчас делаю учет комп техники и комплектующих.
>Я дипломов не пишу. Просто работаю сисадмином.
>Биллинг пытался делать по всякому. Начал с учета траффика.
>Пытался ставить готовые программки. Ни одна не работала так, как мне надо.
>
>Тогда разобрался поглубже с iptables и сделал свою считалку траффика.
>Пока она меня устраивала, но сейчас думаю все-таки приобщаться к стандартным методам
>сбора статистики - изучаю SNMP.
>И еще сейчас делаю учет комп техники и комплектующих.
Сбор данных о трафике - это всеголишь малая и не основная часть биллинговой системы ISP типа.
Прочитал - прослезился.
Содержание статьи в точности соответствует моим планам, мыслям и, не побоюсь этого слова, мечтам.
Я ведь тоже не первый год страдаю, создавая свое средство биллнга. Мои выводы после страданий в точности совпадают с содержанием статьи. Одна беда - статья мне не сообщила ничего нового. А вот начинающему (я кинул ссылку почитать товарищу), эта статья тоже мало чем помогла. Буквально к каждому абзацу он непонимающе задавал вопросы типа:"А это зачем?", "А что такое ...?", "А почему именно ...?".
Мой вывод: статья на самом деле является четким прекрасным оглавлением к более углубленному описанию систем биллинга для начинающих.
В любом случае - спасибо за проделанную работу.
Автор, видимо, сам новичок в биллинговых системах вообще. Как только увидел в статье привязку к биллингу ИТ-услуг, то дальше читать не стал. Человек не знаком со всей областью, а лишь с 10%.
>статье привязку к биллингу ИТ-услуг, то дальше читать не стал. Человек
>не знаком со всей областью, а лишь с 10%.
Если биллинг не умеет учитывать стоимость прокладки кабеля, настройки рутеров клиентам и прочие сопутствующие услуги, то это не биллинг, а простая считалка трафика.
>>статье привязку к биллингу ИТ-услуг, то дальше читать не стал. Человек
>>не знаком со всей областью, а лишь с 10%.
>
>Если биллинг не умеет учитывать стоимость прокладки кабеля, настройки рутеров клиентам и
>прочие сопутствующие услуги, то это не биллинг, а простая считалка трафика.
>
В том то и дело, что понятие сервисов(услуг) должно быть абстрактным и представленным в виде объектов.
На личном опыте могу сказать, что для описания сервисов очень удобно использовать XML. А корпорация Oracle сделала революцию в этой области реализовав "фичу" XQuery. К сожелению не многие могут себе позволить Oracle 10R2 :( Будем ждать аналогов от ОпенСурс сообщества.
А вобще, есть желающие писать OpenSource Billing ? Давно есть такая мысля, но людей нет :( Всё, что я проектировал было комерчискими проектами и имели ограничения на воображение.. :(
Если говорить о встраивании в СУБД поддрежки XQuery, то можно смотреть не только в сторону Oracle... Не понимаю в чем проблема использовать XQuery в стороне от СУБД? Если денег не хватает, можно использовать XQuery как он есть на самом деле, прямо из XML и XSL схем, а данные хранить в базе в сыром XML (а оно нам надо?)...
Вот тебе бесплатное решение от Microsoft - SQL Server 2005 Express, там тебе в нагрузку еще и Reporting Services перепадут и средства разработки, так сказать, наша радость была бы неполной... Но высоченной производительности от экспреса ожидать не стоит, хотя для фронт-энд решения, лично для меня, это самый аппетитный продукт.
Хочу. Такую систему, которая будет учитывать стоимость (а может, и технологию сразу???) прокладки кабеля (а с ГИСом она не завязана? А кабель какой???), неплохо бы еще и весь документооборот, начиная с создания (расчета) коммерческого предложения... Слабо???
Дайте ссылочку на такую биллинговую систему. А что, может и купим. Нафиг горбатиться, когда есть такие монстры...
Рис. 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
