?

Log in

No account? Create an account
dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
GSM: почему биллинг делается так долго? 
20th-Nov-2006 04:14 pm
(заказной пост для en_vision) Допустим, ваш оператор делает биллинг (готовит ежемесячные счета) в течении 5-10 дней? Почему так долго? Казалось бы, делов-то - "select sum(rated_amount) from rated_calls group by contract_id", и вперед - печатать счета. Давайте попробуем разобраться, где же порылась собака.

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

За месяц получаем: 2*10^6 * 20 * 30 = 12 * 10^8 (1 млрд 200 млн). Это количество записей, прошедших через rating.

Что делает процесс биллинга в простейшем случае? Для каждого из 2-х млн абонентов он смотрит, какие контракты принадлежат каждому абоненту, выбирает звонки, сделанные контрактами, суммирует их, добавляет все необходимые ежемесячные абонплаты, и начисляет сверху налоги. По окончании расчета полученные данные засовываются в красивую печатную форму (например, в виде PostScript).

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

Все? Нет, не все. Стрижка только начата. Это мы построили самый простой биллинг, практически - сферический биллинг в вакууме.

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

Давайте также добавим в картину мира так популярные нынче "бесплатные" (или входящие в абонплату) минуты/SMS-ы/MMS-ы и т.п. В терминах нашей модели это означает, что для каждого контракта существует некое кол-во минут N, и определенные (не все) звонки суммарной продолжительностью не более N должны быть исключены из счета. Учтем, что, как правило, N бесплатных минут не будут исчерпаны при помощи целого числа звонков - будет какой-то звонок, который попадет "на границу" и его придется порезать на две части - платную и бесплатную. И это тоже делает биллинг.[2]

Давайте еще учтем смену тарифных моделей. Если у абонента была модель A (X_1 грн в месяц, Y_1 "бесплатных" минут) и он 20-го числа поменял ее на модель B (X_2 грн в месяц, Y_2 бесплатных минут), то с абонента надо снять X_1*(20/30) грн и дать ему Y_1*(20/30) минут в рамках модели А, а в рамках модели B снять X_2*(10/30) грн и дать ему Y_2*(10/30) минут - пропорционально времени, которое он провел в каждой тарифной модели. Да, попутно надо не забыть пересчитать все абонплаты, которые зависят от месячной активности.[3]

Как, все еще помещаемся в пару часов? Сомневаюсь.

Погодите, но кроме счетов для абонента есть еще бухгалтерия. Надо показать, какие звонки абонента "закрывают" те или иные его платежи. Другими словами, если абонент заплатил два раза по 100 грн, а наговорил на 200 грн, то биллинг должен для каждого звонка указать, к какому платежу он "отнесен" - к первому или второму. И так для всех звонков всех абонентов.[4]

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

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

На реплики "так это ж можно распараллелить на 100 серверов!" я, наверное, реагировать не буду, уж извините :)

PS
Предваряя отдельный рассказ про Intelligent Network, NextGenerationOSS, конвергентные, hot, almost-hot и другие "быстрые" решения, хочу закинуть такую "удочку": в системе, которая Сразу после события подбивает достоверный и окончательный баланс абонента, и абонент не может уйти в минус, невозможна нормальная реализация услуг, описаных в пунктах [1],[2],[3],[4].

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

UPD: тем не менее, многие все-таки решили написать мне о том, как прекрасно параллелится биллинг и, в частности, как прекрасно разделяется для этого на части база данных. Коллеги! Я сам придерживаюсь мнения, что среди биллингописателей множество идиотов. Множество - но не все. Подумайте о том, почему такое, казалось бы, тривиальное решение не было реализовано на практике кем-то из major players. А еще подумайте о том, что биллинг - он раз в месяц, а все остальные 27 дней с этой базой и этой таблицей тоже что-то происходит. Причем очень активно происходит, практически без перерыва. И разделение базы на части для этих процессов .... ээээ ... ну, скажем, не самое лучшее решение.
Comments 
24th-Nov-2006 02:12 pm (UTC)
Сколько всяких извратов и наворотов у Билайна в плане тарифных планов, маркетинговых акций и прочего, обьяснять, думаю, не надо. Получается, биллинг, который считает все в реальном времени, сделать можно. Вопрос - что я не так понял?

Надо, надо объяснять. На какой из тарифов на http://www.msk.beeline.ru/tarifs/tarif.wbp смотреть?

Едем дальше.

Во-первых различаем rating (процесс определения стоимости) и billing (процесс формирования ежемесячного счета). Вполне может быть решение, в котором realtime rating, а биллинга нет вообще, или же realtime rating, а биллинг идет 4 дня (я подозреваю, что именно это имеет место у билайна)

Потом, я ж не говорил, что вообще ни за что и никогда нельзя сделать realtime rating. Вот тут описано, как устроен realtime rating для IN-based prepaid-а. Возможно, именно такое решение использует Beeline.

Теперь посмотрим, что же (как я утверждал) нельзя сделать при realtime rating-е.

Realtime rating подразумевает, что стоимость события известна непосредственно после его завершения (или еще в процессе). Соответственно (мне казалось, что этот перехо очевиден) непонятно, что делать с событиями, стоимость которых неизвестна.

Например, если в тарифах написано "звонки - 10 коп/минута, если наговорили больше часа в день - то 8 коп/минута", то сразу после совершения звонка известна только приблизительная стоимость, а окончательная может быть рассчитана только по истечении суток. Теперь заменяем "день" на "месяц". Что у нас там получается с realtime rating-ом? Правильно - ничего не получается. Прийдется пересчитывать стоимость и корректировать баланс по истичении месячного периода.

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

Что и требовалось доказать - быстрый рейтинг возможен, но ограничивает полет мысли сотрудников отдела маркетинга :)
24th-Nov-2006 03:00 pm (UTC)
Anonymous
Спасибо, теперь понятно.

Тарифный план у меня какой-то древний, видимо, этот
http://www.msk.beeline.ru/tarifs/tarif.wbp?tarif_id=55839262-d47c-4190-a2ed-cd52d831b907&archive=, но Prepaid-тарифные планы у билайна меняются в реальном времени (при этом со счета списывается определенная сумма), поэтому, в принципе, все ранво, какой.

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

На моем тарифном плане принципиально не может быть акций типа "если наговорил больше 10 минут в день, то платишь меньше" и т д, приводящих к пересчету баланса, либо вещей "скидка в месяц 10%", т.к. нет понятия "тарфиикация каждый месяц". Но в принципе, это можно реализовать, если по-другому называть. например "10$ на счет тому, кто проговорит в месяц больше часа" или "получи 10 бесплатных минут" и т. д. - это уже работа как раз отдела маркетинга и плясать их, видимо, в Билайне заставляют от возможностей биллинга, а не наобортот.
26th-Nov-2006 03:28 pm (UTC)
это уже работа как раз отдела маркетинга и плясать их, видимо, в Билайне заставляют от возможностей биллинга, а не наобортот.

Если так, то я им по-доброму завидую :)
11th-Jan-2008 04:09 pm (UTC)
"Например, если в тарифах написано "звонки - 10 коп/минута, если наговорили больше часа в день - то 8 коп/минута", то сразу после совершения звонка известна только приблизительная стоимость, а окончательная может быть рассчитана только по истечении суток. Теперь заменяем "день" на "месяц". Что у нас там получается с realtime rating-ом? Правильно - ничего не получается. Прийдется пересчитывать стоимость и корректировать баланс по истичении месячного периода."

не по истичении месяца, а по пересечении "рубикона" - в приведенном примере, когда разговоры за сутки перевалят за час, сделать пересчет.
11th-Jan-2008 06:46 pm (UTC)
Нет, для простых случаев можно извернуться - никто ж не спорит. Но. как известно, аппетит приходит во время еды и реализовав простой случай, сразу хочется (маркетингу) реализовать что-то посложнее.

А для этого надо, как минимум, хранить историю звонков в объеме, позволяющем сделать пересчет.

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

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

11th-Jan-2008 08:19 pm (UTC)
Спасибо за ответ

Скажите, я правильно понимаю, что:
- сделать real-time billing можно для практически любой тарифной модели, но перестройка с тарифа на тариф будет очень геморойной
- реализация его, для особо изощренных тарифных планов, потребует такое количество ресурсов, что постоение real-teme billing'а будет экономически неоправдано
18th-Jul-2008 09:14 am (UTC)
Именно так, кроме того сделать то можно идеально, но маркетингу надо на вчера, с наивысшего уровня приходит указание делать костыль до понедельника, потому что рекламная копмания уже запущена. Менеджер принимает мужское решение что лучше потом решать тысячи претензий силами дешёвых ресурсов колцентра, чем сегодня вытягивать неизвестно откуда дороженных девелоперов, которые всё равно физически не способны сделать за три дня то на что надо месяц, и количество девелоперов не поможет, девелоперы не сервера, кластеризировать не получается.

Адепт ещё не описал весёленького процесса мигрирования с услуги на услугу сотен тысяч клиентов. Каковой приходится делать очень часто, потмоу что маркетинг очень часто любит осчастливливать клиентов переходом с тарифа нового на суперновый, в таких периодах что нередно старый "новый" тариф ещё не успели толком реализовать.
This page was loaded Oct 14th 2019, 8:49 am GMT.