Предыстория
Примерно полтора года назад столкнулись с проблемой, заключающейся в том, что наша биллинговая система (кем-то и когда-то написанная, поддерживаемая местной контрой, в которой автора уже не было) ну никак уже не справлялась с возложенными на нее задачами.
Заказывать разработку новой системы под свои задачи — слишком дорого и слишком долго. Поэтому встала задача — найти подходящее решение. Выбор в итоге пал на 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 если появились какие-то вопросы — задавайте, постараюсь ответить.
