Jump to content

На что слезть с Lanbilling

Сейчас используем Lanbilling 2. Около 2к абонентов ПД, немного телефонии, 15к абонов кабельного ТВ.

 

LB это боль и страдание какое-то. Вот почему.

 

1. Очень странная схема разработки. Нормальные люди сначала фиксят баги, а только затем вводят новые фичи. А здесь с каждым обновлением делается и то, и другое. В итоге с каждой сборкой получаем решение одних проблем, но появляются новые косяки с новыми фичами. Поэтому у нас ни одного обновления не прошло гладко. При этом сама модель поддержки продукта вынуждает постоянно обновляться т.к. иначе глюки никто не исправит. Честно говоря, надоело работать бета-тестером.

 

2. Команда разработчиков, похоже, не общается с техподдержкой. К примеру, крайний раз нам скинули версию радиус сервера, которая использует функции, не реализованные в ядре. В другой раз при очередном обновлении сломалась функция, получающая список агентов. Она используется чуть ли не на каждой странице админки и поэтому большая ее часть загружалась минут по пять пока функция не возвращала ошибку.

 

3. Крайне странная документация. SOAP API вроде есть, но половина функций документирована поверхностно. К примеру, непонятно, какие данные функция принимает на вход и что точно возвращает. Приходится выяснять опытным путем. Хорошо хоть БД открыта и документирована весьма полно.

 

4. Админка на extjs родом из 2008 года. Банально не работает кнопка «назад» в браузере потому что везде используются POST-запросы. Нет нормальной валидации вводимых данных на ходу. Приходится работать с тремя-четырьмя вкаладками в браузере. Боль и страдание короче.

 

5. Механизм подключения отчетов тоже странный, как и сама аналитика. Вроде что-то похожее на MVC, но без контроллера. В итоге забили на это дело и перенесли всю аналитику и отчетность на CodeIgniter + Twitter Bootstrap + JQuery. В итоге работает раз в десять быстрее, любой отчет экспортируется в PDF и вообще выглядит вполне прилично. Появилась даже мысль переписать админку.

 

6. Просто нереальное количество багов – последний перл это падение радиуса при переводе логлевела в дебаг. Или проблема обработки стоп-пакетов в том же радиусе. Неделю убеждали ТП, что это у них проблема. Мы сначала какджый раз переключали логи в дебаг, а потом забили и стали писать дебаг постоянно. Только с ротацией раз в час.

 

7. Элементарные фичи реализовываются спустя пару лет. К примеру, для того, чтобы списать с пользователя деньги за подключение или платный вызов монтажника, до недавнего времени требовалось заводить пользователю отдельную учетку на агенте периодических услуг и снимать деньги им. Сейчас это можно сделать просто на агенте радиус. Счастье-то какое привалило, до сих пор баги выгребаем.

 

Вышеперечисленное это то, что пришло сходу на ум.

 

Так что сижу я и думаю, что делать дальше. Есть два варианта – либо остаться на ЛБ, дожать разрабов по поводу исправления текущих глюков и забить на обновления. Либо съехать на что-то другое.

 

В пользу первого можно отнести более-менее известную архитектуру решения. По крайней мере, известно, что можно делать, а что не стоит. Но с другой стороны, чем больше ЛБ развивается, тем сложнее становится система и тем сложнее ее поддерживать. К тому же ядро с бизнес-логикой написано на C, а это боль и страдание для проекта такой сложности. Почему, к стати, не использовали ту же яву – непонятно.

 

По поводу переезда – нет никакой гарантии, что новый биллинг не будет таким же конструктором для взрослых. В презентациях все говорят хорошо и красиво, но на деле можно выяснить косяки только при эксплуатации.

 

 

Посмотрели на BGBilling – все в общем нравится, особенно открытость бизнес-логики для разработки. С другой стороны для него требуется не сисадмин с навыками MySQL/Python/PHP, а больше кодер на яве.

 

Гидра – пока ковыряли только веб-демку, визуально все хорошо. Однако было бы неплохо посмотреть, что там внутри. И да, требование к Oracle при 2к, ну пусть 3к абонентов выглядят странно.

 

Carbon – по виду конструкор на питоне + FreeRADIUS и скрипты. Но с другой стороны разрабы обещают внедрение чуть ли не любой хотелки. И да, бизнес-логика на питоне, так что посмотреть что внутри не сложно.

 

 

В общем, вопрос таков. Что из вышеперечисленного кем-нибудь использовалось и есть ли положительные отзывы по результатам внедрения?

Edited by megahertz0

Share this post


Link to post
Share on other sites

Да хотя бы цикл разработки был бы как у людей - этого бы хватило. А так каждая сборка - отлов существующих баков и отлов косяков в новых фичах.

Share this post


Link to post
Share on other sites

Нормальные люди сначала фиксят баги, а только затем вводят новые фичи. А здесь с каждым обновлением делается и то, и другое. В итоге с каждой сборкой получаем решение одних проблем, но появляются новые косяки с новыми фичами.

Это, имхо, в любом биллинге так. Если пофиксить все баги, а новых не плодить, кормиться будет не с чего.

Share this post


Link to post
Share on other sites

Тут выбор либо покупать недорогой, но конструктор, либо дорогой, но ничего не приходилось допиливать. Тем более, если речь идет о 2-3 тыс абонентов.

Share this post


Link to post
Share on other sites

megahertz0

А что вы хотели от самого дешёвого биллинга? (собственно он и UTM5 - два самых дешёвых по кап. затратам биллинга)

Судя по всему, они просто не могут себе позволить нормальный цикл разработки (заморозка и фиксинг багов), а работают по принципу - пофиксили 1 багу, 2 запилили.

 

Крайне странная документация. SOAP API вроде есть, но половина функций документирована поверхностно. К примеру, непонятно, какие данные функция принимает на вход и что точно возвращает. Приходится выяснять опытным путем. Хорошо хоть БД открыта и документирована весьма полно.

 

Вот с этим как раз особо проблем нет. Код админки это по факту и есть документация на API. Т.е. в коде админки всегда можно подсмотреть как что-то сделать или как воспользоваться функцией. Да, это не классическая документация

 

Вообще, не бывает хороших биллингов, а самописные - это боль и страдания после ухода ключевого(ых) разработчика(ов), с точки зрения бизнеса риски ещё большие чем рукожопость кодеров Ланбиллинга. Хотя бизнес на 2-3К абонентов не всегда и бизнесом-то можно назвать, часто это что-то типа хобби, а не миллионы $ на счетах в Швейцарских банках.

Share this post


Link to post
Share on other sites

SyJet

я не владелец бизнеса, а просто специалист, но видел и вижу бизнес-процессы по разные стороны баррикад.

если топикстартер имеют долю в предприятии, то самописный биллинг(или сильно модифицированный купленный) это огромные риски, если только он не будет его писать.

если ж он просто админ и хочет поменять ланбиллинг, то лично для него рисков минимум. будет плохо работать - можно сменить место работы (репутационные риски есть конечно, но не факт что оно всплывёт)

 

судя по тому, сколько в своё время было продано сетей на 2-3К абонентов, часто это дело либо не выгодное, либо состояние сети требует модернизации с большими затратами и проще её сплавить крупняку, который поймёт это не сразу (такие я видел не один раз)

Share this post


Link to post
Share on other sites

Свои 5 копеек вставлю.

У нас на порядок больше абонов. Раньше была пачка нетапов, перешли на гидру.

Внедрялись долго- т.к. мы сами тормозили процесс. Баги были по началу, сейчас если и натыкаемся, то оно на бизнес процесс никак не влияет и фиксят оочень быстро.

Телефония вся через через радиус.

авторизация на порту по опции 82, тоже всё работает.

Все сотрудники очень вменяемы.

Из минусов- много кликов, чтобы завести клиента, хотя всё логично.

Договора и прочие бумажки можно прям из биллинга печатать- автозаполнение работает, так как нам надо. Впрочем как и счетов.

Массовое формирование счетов и актов для юр лиц и публикование их в ЛК+ оправка Юрику ссылку на ЛК.

------------

Проблемы есть, но они не значительны.

Вообщем 2 года, пробег отличный.

з.ы. а оператор связи. кому нужны подробности в личку пишите- скину телефон.

Share this post


Link to post
Share on other sites

...Посмотрели на BGBilling – все в общем нравится, особенно открытость бизнес-логики для разработки. С другой стороны для него требуется не сисадмин с навыками MySQL/Python/PHP, а больше кодер на яве....

 

 

Не нужен там такой админ.

Смело переезжайте. Все стабильно работает годами.

На этом биллинге почти с самого его начала.

Хотелки делают быстро и не дорого, при этом ни чего не ломая.

Нужды в постоянном обновлении нет. Одно время сидели на одной из версий более трех лет.

Пришлось обновиться только из-за того, что хотелки пишут только под последнии, текущие версии.

Share this post


Link to post
Share on other sites

Это, имхо, в любом биллинге так. Если пофиксить все баги, а новых не плодить, кормиться будет не с чего.

Так мы не против платить за сервисный контракт. Он ведь подразумевает не только обновления, но и лимитированное время реакции на запросы. Вот и будет доход разрабам с поддержки продукта.

 

megahertz0

А что вы хотели от самого дешёвого биллинга? (собственно он и UTM5 - два самых дешёвых по кап. затратам биллинга)

Судя по всему, они просто не могут себе позволить нормальный цикл разработки (заморозка и фиксинг багов), а работают по принципу - пофиксили 1 багу, 2 запилили.

 

Крайне странная документация. SOAP API вроде есть, но половина функций документирована поверхностно. К примеру, непонятно, какие данные функция принимает на вход и что точно возвращает. Приходится выяснять опытным путем. Хорошо хоть БД открыта и документирована весьма полно.

 

Вот с этим как раз особо проблем нет. Код админки это по факту и есть документация на API. Т.е. в коде админки всегда можно подсмотреть как что-то сделать или как воспользоваться функцией. Да, это не классическая документация

 

Вообще, не бывает хороших биллингов, а самописные - это боль и страдания после ухода ключевого(ых) разработчика(ов), с точки зрения бизнеса риски ещё большие чем рукожопость кодеров Ланбиллинга. Хотя бизнес на 2-3К абонентов не всегда и бизнесом-то можно назвать, часто это что-то типа хобби, а не миллионы $ на счетах в Швейцарских банках.

 

А вы в курсе, что админка может не использовать все функции API? Это как приводить конфиги оборудования вместо документации по нему. А вдруг понадобиться что-то, выходящее за пределы конкретного конфига? Нормальная документация необходима, если ты не сам разработчик.

 

Да, еще такой момент. Количество абонентов это не единственный показатель прибыльности бизнеса. Одно дело иметь домонет с физиками, другое - работать с юриками и крупными клиентами.

 

 

 

Edited by megahertz0

Share this post


Link to post
Share on other sites

Нормальная документация необходима, если ты не сам разработчик.

 

Ой, не факт. Если продукт ведется 10-15 лет, то документация хорошая даже разработчику порой помогает не слабо. :)

Share this post


Link to post
Share on other sites

я знаю пару чел которые работали в ЛБ, и вроде нормально разбираются, в настройках и коде, так что если решите остаться на ЛБ, могу дать контакты .... свой лб не обновлял уже 3 года, все что нужно пишут отдельно...

Share this post


Link to post
Share on other sites

я знаю пару чел которые работали в ЛБ, и вроде нормально разбираются, в настройках и коде, так что если решите остаться на ЛБ, могу дать контакты .... свой лб не обновлял уже 3 года, все что нужно пишут отдельно...

Так ЛБ мы и сами изучили вдоль и поперек. Разве что я ядре не ковырялись т.к. нет исходников.

Share this post


Link to post
Share on other sites

Плюсану за Bgbilling

 

Простите, но что хорошего в BGBilling?

 

1. Как в нем просматривать данные клиентов просто перемещаясь стрелками по абонентам? Например нужно посмотреть какие IP адреса у абонентов? Сначала требуется получить список договоров, потом открыть договор, зайти в нужный модуль и только тогда можно все увидеть. Про получить данные скриптами разговор не ведем.

 

2. Копирование данных из биллинга - даже банального пункта в ниспадающем меню "копирование" нет. Приходится комбинациями на клавиатуре пользоваться.

 

3. Опять же прямого копирования IP адресов, или вставки IP адресов в модуле IPN нет, нужно вставлять по группам.

 

4. Меню вообще кривое - крестики закрытия окон внизу.

 

5. Личный кабинет скудный, кривой и выглядит как из начала 90 годов.

 

6. Отсутствует встроенный механизм контроля дубликатов данных, например можно завести одни и те же IP адреса разным абонентам, что создаст конфликты.

 

И еще много много других проблем по мелочи.

Share this post


Link to post
Share on other sites

А почему никто не задал вопрос ТС

А зачем вы постоянно обновляетесь??

у нас тоже ланбиллинг, поэтому я отвечу.

можно не обновляться. какое то время. но когда нибудь наступит момент, когда ТП скажет: баг пофиксили в новой версии.

а обновится на нее лучше с предыдущей.

а если сидишь на версии трехлетней давности, то, соответсвенно, имеешь проблемы

 

как то так... мы обновляемся не реже раза в год и каждый раз это боль и страдание, хотя, посмотрев на стоимость гидры, могу сказать, что ланбиллинг своих денег стоит.

Share this post


Link to post
Share on other sites

Привет !

 

Вот мои 5 копеек , LanBilling полный отстой ,как не админь его .... Переходим на Гидру. Достойный биллинг , адекватные ребята .

Share this post


Link to post
Share on other sites

Вот мои 5 копеек , LanBilling полный отстой ,как не админь его .... Переходим на Гидру. Достойный биллинг , адекватные ребята .

 

Может быть Гидра и достойный биллинг, но посмотреть его работу без оплаты производителю нет возможности. У всех других биллингов есть полнофункциональная демоверсия, которую можно попробовать, посмотреть, потестировать, и после принять решение переходить или нет.

Share this post


Link to post
Share on other sites

Вот мои 5 копеек , LanBilling полный отстой ,как не админь его .... Переходим на Гидру. Достойный биллинг , адекватные ребята .

 

Может быть Гидра и достойный биллинг, но посмотреть его работу без оплаты производителю нет возможности. У всех других биллингов есть полнофункциональная демоверсия, которую можно попробовать, посмотреть, потестировать, и после принять решение переходить или нет.

Вы вообще хоть на их сайт заходили? Заполняете анкету и по вас развертывают на месяц виртулку полнофункциональную

Edited by SyJet

Share this post


Link to post
Share on other sites

Вчера на стэнде решили накатить обновление с 08 до 014. В итоге вылезло следующее:

 

Выдержка из документации.

 

Начиная со сборки 011 АСР LANBilling 2.0 для обновления структуры БД необходимо вы-

полнить один скрипт «update.sql». При этом:

1. время обновления зависит от состояния структуры БД на момент обновления;

2. применявшиеся в предыдущих сборках скрипты «deleting_zero_charges» и «day_revision»

не используются;

3. скрипт «procedures-sales» выполняется после выполнения основного скрипта, с целью об-

новления процедур модуля финансовой отчетности;

4. организована следующая поддержка многоразового запуска процесса обновления:

— этап 1 – сравнение структуры обновляемой БД с эталоном;

— этап 2 – изменение структуры обновляемой БД (при наличии расхождений);

— этап 3 – обновление данных БД;

5. функционал обновления структуры БД включает в себя автопроверку данных на уни-

кальность и связность данных между таблицами. При возникновении исключительных ситуаций

выдаются соответствующие ошибки. Процесс обновления, при этом, не прерывается;

6. таблица, содержащая более 10 млн записей, может быть автоматически пересоздана и сек-

ционирована (разбита на логические части с целью повышения скорости обработки данных).

Время операции зависит от ресурсов сервера и количества записей в таблице.

 

Вечером оставили на сервере выполнять update.sql, утром сервак наглухо завис. По SSH не отвечает, подключили к монитору - нет изображения. Перезагрузили с кнопки - не загружается даже BIOS. Перезагрузили hard reset по питанию - грузиться до монтирования Mount local filesystems и уходит в глубокую задумчивость.

 

Вечером последний processlist перед уходом был такой:

 

mysql> show processlist;

+----+------+-----------+---------+---------+------+-------------------+-----------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
| Id | User | Host      | db      | Command | Time | State             | Info                                                                                                | Rows_sent | Rows_examined | Rows_read |
+----+------+-----------+---------+---------+------+-------------------+-----------------------------------------------------------------------------------------------------+-----------+---------------+-----------+
|  1 | root | localhost | billing | Query   | 6933 | copy to tmp table | ALTER TABLE `auth_history` MODIFY `mac` varchar(255) NOT NULL  default ''  COMMENT 'MAC-адрес' |         0 |        191851 |    191851 |
|  2 | root | localhost | NULL    | Query   |    0 | NULL              | show processlist                                                                                    |         0 |             0 |         0 |
+----+------+-----------+---------+---------+------+-------------------+-----------------------------------------------------------------------------------------------------+-----------+---------------+-----------+

2 rows in set (0.00 sec)

 

Табличка auth_history весит 20 гигов, tmp_table_size и max_heap_table_size были выставлены на 256M, по их рекомендациям, что соответствует свободной памяти. C livecd сейчас при попытке монтирования ФС уходит так же в глубокую задумчивость.

 

При попытке смонтировать получил такое. Оживить пока что ни как не получается, думайте сами.

post-95497-005776300 1427287045_thumb.jpg

Edited by hsvt

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.