Предыстория
Примерно полтора года назад столкнулись с проблемой, заключающейся в том, что наша биллинговая система (кем-то и когда-то написанная, поддерживаемая местной контрой, в которой автора уже не было) ну никак уже не справлялась с возложенными на нее задачами.
Заказывать разработку новой системы под свои задачи — слишком дорого и слишком долго. Поэтому встала задача — найти подходящее решение. Выбор в итоге пал на BGBilling. В итоге вот уже год как мы работаем с этой системы и в целом всем довольны. Почему мы выбрали именно систему и чем она хороша (минусы тоже постараюсь осветить) постараюсь подробно изложить ниже.
Введение
Итак, для кого в первую очередь предназначен пост? Для людей, подобно мне полтора года назад, озадаченных руководством, находящихся в поиске подходящего решения и ищущих описания различных систем, чтобы начать тестирование (да, есть замечательный ресур наг.ру, но лично мне он не импонирует, слишком уже хаотично все, поэтому хабру я верю больше). Так же думаю будет интересно тем, кто переживает/пережил бурный рост/выход на новую нишу и ощущает необходимость апгрейда/переезда на новую платформу.
Пожалуй, начнем.
О системе
Система — российская. Сайт — bgbilling.ru
Как я понял, система писалась для сети УфаНет, и потом выросла в отдельный продукт. Разработка идет где-то с 2003 года. Текущая версия 5.0 (у нас стоит 4.6, отличий от текущей — практически никаких, новая версия была вызвана окончанием действия сертификата), в разработке находится версия 5.1, в которой разработчики обещают много нового, но про нее пока я ничего сказать не могу.
Архитектура системы — серверная часть написана на Java. Первое время беспокоила производительность и стабильность такой системы. По прошествии года могу сказать — с производительностью и стабильностью нет никаких проблем. Но есть одно НО. Сервер требует последнюю Java, а с ней есть определенные проблемы на FreeBSD. Поэтому этой системы нет в списке поддерживаемых. Но зато есть — Windows, Linux. Конкретно у нас стоит на Fedora 10. Mac как поддерживаемая платформа не заявляется, но в целом мне ничто не помешало запустить сервер и клиент у себя на ноутбуке. СУБД — MySQL.
Документированность БД — изумительная. Идем на сайт dbinfo.bitel.ru и шаримся, смотрим что и как с чем связано, какие параметры могут быть. Честно признаюсь, для м��ня документированность БД была одним из решающих факторов. Было ясно, что функционал специфичный только для нас придется допиливать самому, поэтому такое подспорье как адекватная документация, меня как радовали, так все больше и радуют.
Клиент для оператора биллинга — отдельное GUI приложение.
Что следует отметить — в клиенте есть встроенные sql редактор, который из самого клиента позволяет выполнять зарпосы к бд и получать результаты в удобоваримом виде.
Стоимость, лицензии и прочее
Система — модульная. Каждый модуль имеет количество лицензий с которыми он может работать (или бесконечное количество). Чем больше лицензий — тем дороже модуль. Максимальная цена — за бесконечное количество лицензий.
Какие модули стоит выделить — модуль списания абонентский плат, модуль diap up, модуль ipn, voiceip. Рассчитать стоимость лицензии можно на сайте — bgbilling.ru/price_count.shtml
Какие модули кому нужны будут? Без модуля абонентских плат — никуда. Берем его, максмальная цена за бесконечное количество лицензий (бесконечное начинается с 10000 лицензий) — ~100тр.
А теперь смотрим чем мы занимаемся? Оператору КТВ по сути больше ничего не нужно. Провайдеру еще бы и модуль работы с сетью. Это или IPN или DialUP — и тот и другой максимально стоят тоже порядка 100тр.
Модуль телефонии — один из самых дорогих. Порядка 240тр.
Остальные модули — voiceip, модуль цифрового телевидения — по-моему не так популярны, их рассматривать не будем. Если интересно — можно посчитать на сайте.
Техподдержка, комьюнити
Спорный вопрос по техподдержке. Она платная. При покупке лицензии предлагается заключить контракт на техподдержку и приобрести пакет обращений. За 25тр можно получить 50 обращений на год. За 9тр — 15 обращений, тоже на год. Много это или мало? Мы использовали за год — 5 обращений. Сообщения об ошибках за обращения не засчитываются, но для их сообщения все равно нужен пакет хоть с одним обращением.
Бесплатная поддержка оказывается разработчиками на форуме, но в негарантированные сроки. Если через личный кабинет ответ будет дан в среднем через пару часов, то через форум придется подождать день-два. Но зато на форуме очень много таких же пользователей как и вы, которые подчас подсказывают и помогают оперативней.
Что и приводит нас к вопросу о комьюнити и вики-базе. Сообщество мне очень понравилось. На форуме можно найти помощи практически по любому вопросу. В последнее время и ко мне в аську начали с вопросами обращаться, с радостью подсказываю, если знаю что и как.
Производительность и факапы
Официальные данные представлены на соответствующей странице сайта — bgbilling.ru/program/speed.shtml. В целом им можно верить. АП списываются довольно шустро. Радиус(мы используем модуль DiapUP для доступа к сети) держит нагрузку при одновременной авторизации 1000-1500пользователей (пропадаение света в районе, а потом включение) вполне нормально. Радиус же занимается обсчетом нетфлоу статистики. Справляется с потоком от 6 цисок с гигабитом трафика на каждой.
Если не считать факапов вызванных своими кривыми руками, то был один довольно неприятный факап 1 января 2010 года. На каждый месяц автоматически создаются новые таблицы с балансом. Из-за какой то недоработки в логике в 2010 году новые таблицы не создались. Поэтому в момент списания АП у всех был 0 на счету. Благо БД очень хорошо документирована и есть функции групповых операций — это удалось очень быстро устранить (до того как большая часть абонентов отошла от похмелья и полезла в интернет).
Запуск, перенос существующих баз
Настройка и запуск системы осуществляются довольно просто, особо выделить даже нечего. Распаковать архив, добавить исполняемые .sh в автозапуск, загрузить структуру таблицы из файла дампа и пожалуй все — уже будет работать =).
Инетересный момент. Основные компоненты системы — сервер, радиус, шедулер — можно разнести на разные сервера, в настройках указать айпишники и все отлично будет работать, цепляться к серверу и распределять нагрузку.
Кстати про распределение нагрузки. Все задачи сваливаются в очередь, которую обрабатывает шедулер. Причем он практически никак не связан с сервером. Т.е. задача на выгрузку статистики, переобсчет трафика — нагрузит шедулер, но никак не скажется на производительности самого сервера биллинга — он будет работать в нормальном режиме, складывая задачи в очередь, будет давать доступ до бд радиусу и других модулям.
Заключение, сравнение с другими системами
В целом биллингом я доволен. Сейчас дописываю свой интерфейс (опять радуюсь документированности бд — написать нужные запросы к бд оче��ь легко)
Сравнить с другими системами особо возможностей и не было. По отзывам тех кто переезжает с UTM — небо и земля — документированность и открытость бд, возможность дописать свои скрипты, реализовать собственную бизнес логику.
PS если появились какие-то вопросы — задавайте, постараюсь ответить.
