Девять важных факторов при выборе биллинга

[Robot_NagNews]

Материал:

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

 

Полный текст

[Saab95]

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

 

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

 

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

[vop]

Сначала:

 

"Биллинговая система необходима большинству бизнесов, которые предлагают услуги по модели подписки: интернет-провайдерам, дата-центрам, поставщикам контент-услуг, облачным сервисам, бюро кредитных историй или управляющим компаниям."

 

И все скатывается к:

 

"С технической точки зрения важна поддержка биллингом BRAS, софтсвичей и другого оборудования, а в случае услуг по обеспечению доступа в интернет — наличие возможности автоматизации схемы доступа по технологии IPoE."

 

Вот и думаешь, нафига управляющим компаниям поддержка софтсвичей. :)

[YuryD]

В общем, масло маслянное, а вода мокрая. Статья ни о чём. Главное в АСР - сертификат соответствия. И чем дешевле, тем лучше. А уж привязывание к АСР СРМ и прочее - оно конечно полезно, но дорого.

[s.lobanov]

Согласен с Saab95, что статья ни о чём, а проще говоря унылое говно. И даже согласен с тем, что потрахушки с установкой это неприкольно. Все нормальные люди подобные приложения дают (в том числе) как appliance/образ виртуалки (требующие много внешнего ПО - БД, веб-сервер и т.п.)

 

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2" и кривыми сетями, требующими для сервис-активации залезать на свитчи доступа и там что-то править в конфиге. Я вот знаю пару мест, где ничего не умеющий UTM5 успешно работает и ничего не делает кроме списания/внесения денег, rad auth и rad PoD. Всё просто до неприличия и не требует миллиона фич, которые меняют своё поведение от версии к версии (тот же самый ланбиллинг, который либо совсем не тестируют перед релизом, либо этим занимается команда макак с клавиатурами)

[SergoINFOLAN]

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2"

тут не соглашусь, всё же маркетинг главнее технарей, вот например тарифы на ГИГАБИТ надо давать, и плевать на старые свичи.

[megahertz0]

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2" и кривыми сетями, требующими для сервис-активации залезать на свитчи доступа и там что-то править в конфиге. Я вот знаю пару мест, где ничего не умеющий UTM5 успешно работает и ничего не делает кроме списания/внесения денег, rad auth и rad PoD. Всё просто до неприличия и не требует миллиона фич, которые меняют своё поведение от версии к версии (тот же самый ланбиллинг, который либо совсем не тестируют перед релизом, либо этим занимается команда макак с клавиатурами)

 

+1.

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

Во-вторых service activation должен быть реализован стандартными протоколами (RADIUS), а не кучкой мутных скриптов, делающих 10 разных операций в 5 местах. К примеру, мы слезли с ISG + DHCPD с самодельными скриптами и еще куча всякой обвязки на модель IPoE, где все разруливается через RADIUS CoA. Ну и еще AAA через RADIUS. Схема service activation стала проста как мычание. Работать стало в разы проще.

В третьих биллинг должен иметь открытию и документированную архитектуру и нормальный API. А не представлять собой черный ящик, который как-то работает. Рано или поздно придется интегрировать биллинг со внешними системами (платежные системы, бухгалтерия, банки, какая-нибудь аналитика и т.д.) и это все понадобится. Т.к. на определенном этапе становится дешевле платить своим программистам, чем бегать за разработчиками.

[A4on.TV]

Обычная рекламная статья. Хвалим то, что есть в своем билинге и ругаем все чего нет.

[X-RaY™]

Я как раз с гидрой общаюсь на тему внедрения...

[LostSoul]

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

 

 

Вот оно как..... нет я знаю один типа-биллинг где невозможно проследить историю платежей)

Старгейзер называется.

Но всерьез обсуждать его в статье для провайдеров?

 

Ощущение что автор пишет пересказ того что услышал от кого-то из технарей и понял неправильно.

[Ivan Rostovikov]

>Я как раз с гидрой общаюсь на тему внедрения...

а я как раз внедряю уже второй раз.

пиши если есть вопросы. помогу

[zhenya`]

Перл устаревшая технология...

[20Ilya]

Перл устаревшая технология...

Я это уже лет 10 слышу... Но что-то вот всё никак не устареет и не умрёт... ;)

[zhenya`]

Да это микротик стайл

[s.lobanov]

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2"

тут не соглашусь, всё же маркетинг главнее технарей, вот например тарифы на ГИГАБИТ надо давать, и плевать на старые свичи.

 

вы неправильно поняли. где я сказал, что продавать гигабит это плохо? (пусть даже не имея тех.возможности обеспечить - это на вашей совести). я лишь пытаюсь донести, что пора завязывать со всяким дерьмом типа приведи друга и получи XXX бонусных баллов, на которые потом можно "купить" ускорение интернета или 1.5 дня интернета. всё это слишком сложно/костыльно реализовывать в условиях того, что все биллинги проприетарны (ну есть конечно смешные поделия типа abills и ещё какая-то фигня, но никто же не воспринимает их всерьёз). все эти "акции" приводят к тому, что нужно постоянно платить за доработки или делать их самим костылями, которые не факт что отработают корректно и как следствие, негатив со стороны абонента

[s.lobanov]

Перл устаревшая технология...

Я это уже лет 10 слышу... Но что-то вот всё никак не устареет и не умрёт... ;)

 

не, ну реально % использования Perl в новых проектах близок к нулю. мне 28 лет и почти никто из моих ровесников на Perl не пишет, люди постарше - да

 

и тут самое главное тренд(http://www.w3cook.com/programminglanguage/perl ) - Perl'ом пользуются всё меньше и меньше и скоро программисты Perl будут как сис.админы какого-нибудь AIX, они вроде бы и не нужны, но когда надо - особо и не найдешь

[Sergey Gilfanov]

они вроде бы и не нужны, но когда надо - особо и не найдешь

"Когда надо" - это новое написать или прочитать, понять, починить/поправить то что есть? Если править - то понятно, почему нет. Оно в большинстве случаев не слишком читаемо.

[vop]

ну есть конечно смешные поделия типа abills и ещё какая-то фигня, но никто же не воспринимает их всерьёз

 

Ну да, не воспринимает. Слишком мало надо за них платить. :)

[SergoINFOLAN]

В целом же, нужно не биллинг пилить под извращённые акции и кривожопые бизнес-процессы, а завязывать со всяким булшитом типа "приведи друга и через месяц полтора месяца пользуйся инетом на скорости x2"

тут не соглашусь, всё же маркетинг главнее технарей, вот например тарифы на ГИГАБИТ надо давать, и плевать на старые свичи.

 

вы неправильно поняли. где я сказал, что продавать гигабит это плохо? (пусть даже не имея тех.возможности обеспечить - это на вашей совести). я лишь пытаюсь донести, что пора завязывать со всяким дерьмом типа приведи друга и получи XXX бонусных баллов, на которые потом можно "купить" ускорение интернета или 1.5 дня интернета. всё это слишком сложно/костыльно реализовывать в условиях того, что все биллинги проприетарны (ну есть конечно смешные поделия типа abills и ещё какая-то фигня, но никто же не воспринимает их всерьёз). все эти "акции" приводят к тому, что нужно постоянно платить за доработки или делать их самим костылями, которые не факт что отработают корректно и как следствие, негатив со стороны абонента

именно что и бонусная система нужна со сложными правилами и плевать на проблемы технарей, нужно именно полтора дня!

[20Ilya]

Отвечу про Perl ссылкой, которую случайно нашёл несколько дней назад...

http://habrahabr.ru/post/245659/

[Wingman]

Куча спорных моментов :)

 

Особенно понравился пассаж, восхваляющий схему постоянно вычисляемого баланса абонентов вместо хранимого значения. Идеологически всё может быть и верно (для сферического билинга в вакууме), а на практике..

 

В Гидре баланс абонента не выбирается из БД, а получается вызовом stored procedure. И всё бы ничего, но, блин!

- Оно МЕДЛЕННО!

- Оно НЕУДОБНО!

- При выводе в црм-ке пары сотен абонентов с балансом, нам прямым текстом "не порекомендовали" так делать, т.к., судя по анализу быстродействия, отображение этой странички (десяток раз за день) давало одну из самых больших нагрузок на i/o в системе.

- Простая сортировка абонентов по балансу требует дёрнуть хранимую процедуру N тысяч/десятков тысяч раз, что а) аццки грузит сервер, б) оооочень не быстро. Особенно это весело, когда хочется сделать по-быстрому кучу выборок.

 

 

А в целом билинг хороший :)

Edited January 24, 2016 by Wingman

[vop]

Вообще-то, делается очень просто. Делаются временные маркеры обновления истории платежей, и временной маркер баланса. И в процедуре чтения баланса проводится элементарное сравнение этих двух времен. Если история платежей имеет время обновления/изменения позже, нежели маркер баланса - баланс пересчитывается.

 

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

[Saab95]

Вообще-то, делается очень просто. Делаются временные маркеры обновления истории платежей, и временной маркер баланса. И в процедуре чтения баланса проводится элементарное сравнение этих двух времен. Если история платежей имеет время обновления/изменения позже, нежели маркер баланса - баланс пересчитывается.

 

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

[Sergey Gilfanov]

А сами пересчеты будут происходить не часто.

Зависит от того что и как считают. А то, может, там каждую минуту снимается дельта от количества прошедших байт (да-да, по всем пользователям, что в online) и, соответственно, записывается дельта по деньгам. Каждый раз пересчитывать баланс - ну, немного напряжно.

[dimas]

"Когда надо" - это новое написать или прочитать, понять, починить/поправить то что есть? Если править - то понятно, почему нет. Оно в большинстве случаев не слишком читаемо.

 

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

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

 

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

 

В одном соглашусь - софт на перле в эксплуатации сейчас дороже остального, если нет маньяков из старой гвардии :)