1. Разработка или покупка готового?

[vop]

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

У меня обработка запускатеся один раз в минуту.

 

На сколько в минус даете "зайти" пользователю?

В пределах рубля. Максимум, доллара.

 

И что потом делаете с этим минусом? Оставляете или сбрасываете в ноль?

Оставляем, пока клиент не добавит денег на счет.

 

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

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

Изменено 21 февраля, 2007 пользователем vop

[_Alexandr_]

А в профессиональных системах как считается? Если абонентов тыщ 30 ?

Интересно, а есть билинги которые считают "на лету"? На какую нагрузку они расчитаны?

[vop]

А в профессиональных системах как считается? Если абонентов тыщ 30 ?

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

 

1. Условно называется метод плюс-поинта. Метод достаточно прост, хотя, с моей точки зрения, не совсем честный по потношению к клиенту. По этому методу определяется максимально-возможная стоимость получения услуг между двумя "замерами", и эта стоимость устанавливается в качестве дебетной границы отключения. Например, билиннг проверяет статистику один раз в 5 минут. За 5 минут клиент может накачать, например, на 2 рубля. Значит система и устанавливает 2 рубля, как границу отключения. Метод фиговый, честно говоря, но он кое-где применялся.

 

2. Другой метод, условно наывается методом выделенной квоты. При каждом "замере" статистики, система вычисляет количество оставшихся услуг не в денежном эквиваленте, а в эквиваленте тех услуг, которые предоставлетсяб например, мегабайт, секунд и т.д. И на уровне системы, предоставляющей услугу, идет локальное сравнение. При следующем "замере", остаток квоты пересчитавается и используется для сравнения до следующего замера. Такой метод намного правильней предыдущего.

 

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

 

Интересно, а есть билинги которые считают "на лету"? На какую нагрузку они расчитаны?

Есть, но опять-таки замечу, что смысла в счета "на лету" нет никакого. Высокие накладные расходы при мизирном эффекте? Тем более, подавляющее число провайдеров в мире давно считают не мегабайты, а, в крайнем случае, сутки :) Ну, типа, клиент оплатил 90 суток интернета, значит, 1-го мая мы его отключим, если не оплатит дальше.

Изменено 22 февраля, 2007 пользователем vop

[mikevlz]

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

[_Alexandr_]

У нас составляется план-заказ и там пока заложена информация такая:

 

Платформа биллинга Unix/Win - бинарный файл (имеется ввиду не PHP или Perl, а уже скомпилированный)

Время обновления БД - 1 минута (30 секунд).

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

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

Поддержка RADIUS, NETFLOW, SNMP 1/2/3.

Резервирование БД - 1 час.

Время резервной БД - 1 месяц.

 

Таким образом, подсчет происходит в "реальном врмени" по мере поступления информации от сенсоров (всяческих агентов), все это держится в ОЗУ и раз в минуту (30 секунд) скидывается в БД. БД каждый час делает свою копию на резервный диск где она хранится 30 суток.

 

Таким образом, есть основная БД которая стоит на RAID, ее ориентировочный размер 100 Мб, каждый час делается копия которая хранится 30 суток, копия делается на другой сервер. На том сервере понадобится около 70 Гб дискового пространства.

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

[buster]

Наша фирма сначала писала под себя биллинг, но ввиду неудачности выбора разработчика и неудачности тех.задания, отказались от этого занятия. Сейчас мы купили биллинг, смотрим на его достоинства/недостатки и теперь подумываем на его основе написать своё (клиента и pl/sql процедуры). Частично уже переписано под себя.

[_Alexandr_]

Если можно, то технические параметры вашего билинга, как я описал свои (см выше).

[Shiva]

P.S. Не берите АСР "Фастком"(г.Москва) , есть такой говёный биллинг, уже обожглись

Ага, помню в 2004 писал вебморду к этому чуду, так как что-либо сделать в нём надо было открыть 100500 окошек...

[ichthyandr]

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

Как хоть чуть вырастает - совмещать не удаётся. Догадайтесь, куда отправляется биллингописательство?

+100 Ибо нужно определиться - что делать будем )

[snark]

Некрофилы.