Вопрос
"Меня вот интересует вот какой вопрос. А как этот мегамоск под названием “процесс биллинга” программируется под необходимую логику? Допустим пришел манагер, и сказал что надо тариф такой-то вот с такой-то логикой (дальше обычно идет что-то, что нормальному человеку в голову ни за что не придет). И что в этом случае делают люди саппортящие биллинг? Не переписывают же кусок кода для реализации этой “мечты идиота”?"
Короткий ответ
Бывает по всякому - может быть и такое, что надо писать код.
Длинный ответ
Начну с определений терминов рейтинг и биллинг, которые я буду использовать. Очень часто их взаимно подменяют друг другом, и большой беды от этого не происходит, но в сегодняшний пост как раз затрагивает существенные и принципиальные различия между этими процессами, и я постараюсь их не путать :)
Итак, рейтинг - это процесс вычисления стоимости (rate) какого-то события. Договоримся, что событие - это акт потребления услгу пользователем в самом широком смысле этого слова :)
С рейтингом тесно связан биллинг - процесс формирования счетов, накладных и прочих бухгалтерских документов, выполнения “закрытия финансового периода”, уведомления абонентов о их текущем балансе и задолженностях и прочих подобных танцев с бубнами.
Первое существенное различие между рейтингом и биллингом - это то, что биллинг - это неспецифичный для телекома процесс. Биллинг присутсвует и в компании, подающей в квартиры горячую воду, и на сайте www.livejournal.com (для платных аккаунтов), и во множестве других сервисных организаций.
Рейтинг же - процесс, специфичный для телеком-компаний. Провайдеры мобильной связи, провайдеры Internet, операторы фиксированных сетей - все они так или иначе реализуют у себя процесс рейтинга.
Кстати, по подобному критерию - специфичности для телекома - все информационные системы оператора мобильной связи часто делят на две категории - OSS (operator support systems) и BSS (business support systems). В OSS попадают вещи типа рейтинга, управления учетными записями абонента, а в BSS - вещи типа систем отчетности, систем управления предприятием (ERP), CRM-систем и т.п. (внимательный читатель мог заметить, что аббревиатура BSS применительно к оператору мобильной связи может иметь минимум два значения - business support system и base station subsystem. Это может служить (и зачастую - служит) поводом для мелких и не очень недопониманий)
Впрочем, я отвлекся. Вернемся к теме. Сегодня нас будет больше интересовать рейтинг, так как про биллинг я уже писал.
Что такое рейтинг, и как его реализуют
Попробуем очутиться в шкуре архитектора или програмиста биллинговой системы.
Абстрактно говоря, рейтинг в мобильной связи есть функция, которой в качестве аргументов даются атрибуты события и атрибуты абонентов, принимавших в нем участие.
Самый популярный набор аргументов для функции рейтинга такой: тарифный план абонента А, номер абонента B, тип события, время события, длительность (Здесь и далее абонентом A (или A-party) я буду называть того, кто звонит, а абонентом B (B-party) того, кто принимает звонок.).
Самый популярный вид самой функции рейтинга: линейная зависимость (a * x + b) стоимости от длительности события, где коэффициент ‘a’ берется из тарифного плана, а ‘b’ - так называемая “плата за соединение” (call setup fee).
Если мы договоримся, что стоимость у нас всегда линейно зависит от длительности, то это сильно упростит нам жизнь при написании системы. Мы, скорее всего, пойдем самым простым путем и получим …
Табличный рейтинг (table-driven rating)
Сердцем нашей системы будет таблица, хранящая записи вида (rating_plan_id, event_type, destination, price_per_unit). Каждая запись будет описывать, почем стоит секунда звонка (или call forward-а, или 1 sms, …) на указанное направление в указанном тарифном плане.
Словом направлением называют телефонный номер или какую-то его часть - например, “звонки в Англию” часто называют “звонками на направление +44”, а звонки в Киев - “звонками на направление +38044”.
Соответственно, в нашей таблице могут быть записи типа (“Супер-шара”, “звонок”, "*“, 0.01) - в тарифном пакете”Супер-шара" звонки куда угодно - по копейке секунда :)
Как будет работать наш рейтинг? Очень просто. Берем запись о событии (call detail record, CDR) , из нее - номер абонента А. Находим его в базе абонентов. узнаем его тарифный план. Тип события нам известен, номер B - тоже (все это есть в CDR). Найдя в таблице тарифов запись с нужным направлением (для этого используют поиск самого длинного префикса, regexp match, glob match, … ) , мы узнаем цену за секунду. Умножаем ее на длительность - и вуаля, рейтинг сделан!
Для такой системы, как правило, не является препятствием большое кол-во абонентов и одновременно большое кол-во тарифных планов. Единственное неудобство - GUI настройки такой системы, как правило, представляют из себя примитивный DB Grid, и при большом кол-ве тарифных планов их изменение превращается в отупляющую рутинную работу. Зато система Аццки Быстра(тм), что позволит нам на долгое время забыть о необходимости апгрейдить рейтинговые сервера :)
Впрочем, стоит заметить, что в дикой природе такие примитивные системы практически не встречаются - они или вымерли, или эволюционировали в …
Табличный рейтинг, попытка номер 2
Заметим, что table-driven систему достаточно просто можно расширить возможностью задавать не только линейную зависимость стоимости от времени. Изменим схему нашей базы так: тарифы будут храниться в записях (rating_plan_id, event_type, destination, function_id), где function_id - указание на одну из нескольких жестко прошитых в коде системы функций. Такой апгрейд позволит нам, например, создавать тарифные планы с фиксированной стоимостью звонка или планы вида “первые пять секунд - бесплатны”.
Впрочем, жестко зашивать в коде бесплатный интервал в пять секунд - некрасиво. Добавим в нашу табличку полей - (rating_plan_id, …, function_id, const_1, const_2, const_3, const_4, …, const_9). После этого мы сможем писать в ней (“МегаДрайв”, “звонок”, "*“,”Фикс_цена_с_беспл_интервалом“, 5, 10, NULL, NULL, …, NULL), что будет означать, что в тарифном плане”МегаДрайв" все звонки стоят 10 рублей, независимо от стоимости, причем первые пять секунд - бесплатно.
Работать этот рейтинг будет чуть медленнее - для каждой записи надо будет не просто умножить два числа, а вызвать какую-то функцию. Но он все равно будет Аццки Быстр (тм), особенно если функцию напишут люди, у которых руки не ростут из задницы. Во всем остальном (удобство конфигурирования, гибкость и т.п.) это решение будет идентично предыдущему.
Несмотря на кажущийся примитивизм, такие системы как правило и используются для рейтинга prepaid абонентов на IN-платформах. Самое большое ограничение этих систем - невозможность создания своих функций рейтинга (обычно производитель продает услуги расширения рейтинга за отдельные деньги) и раз и навсегда определенный набор параметров, от которых может зависеть цена. Что приводит нас к ….
“Компонентный” рейтинг
Делаем еще один шаг по эволюционной лестнице. Дадим пользователю системы возможность самому писать функции рейтинга. Чтобы пользователи сильно не радовались, можно сделать этот процесс тяжелым, медленным, и тяжелоотлаживаемым. В лучшем случае, пользователю надо будет писать фукнции на PL/SQL, в худшем - писать их на внутреннем “скриптовом” языке, который представляет собой кастрированый C, в реальности иногда им и является, и компилируется в DLL-и, вызываемые ядром рейтинга, которое, таким образом, будет с грохотом падать при любой серьезной ошибке в пользовательском коде.
Как вариант - пользователю можно не давать возможность что-то писать самому, зато он сможет выбирать из широкого набора доступных DLL-ек (компонент), покупать их у фирмы-производителя оптом или в розницу, и самостоятельно подключать к своему биллингу. Как это все будет настраиваться и конфигурироваться - слабонервным лучше не смотреть :)
Как правило, у подобных систем есть четко описанное API, через которое компоненты могут лазить в систему и извлечать оттуда нужные им данные. С целью сохранения пристойной производительности, через API дается доступ только к ограниченному подмножеству данных об абоненте, тарифном плане и т.п.
Таким образом, самым существенным ограничением подобной системы будет невозможность выйти за рамки этого API. Например, если через API нельзя получить дату подключения абонента, то нельзя будет сделать тарификацию вида “если вы с нами год - скидка 10%, если два - 20%, …”
Rule-based рейтинг
Вариацией на ту же тему будет “рейтинг с возможностю написания правил” (rule-based). Пользователю дается внутренний язык описания правил рейтинга, с помощью которого, как правило, можно дотянуться до всех мыслимых и немыслимых данных об абоненте, его тарифном плане, его сервисах, его истории, и так далее.
Как правило, такие системы рейтинга являются частью (или тесно связаны с ) каких-то BSS-систем, и понятия, которыми оперируют BSS-системы, тоже могут быть доступны во время рейтинга.
Например, можно будет использовать в рейтинге сумму последнего счета (и рассчитывать на ее основании скидку) или же количество обращений абонента с жалобами в call center :)
Понятно, что такой рейтинг будет, пожалуй, самым медленным из всех. Если правила можно писать (руками), то настройка такой системы может быть легким и даже приятным делом. Но обычно правила надо навозюкивать мышкой в ублюдочном GUI, наподобие блок-схемы, что ставит процесс настройки на одну полку с настройкой table-driven системы.
Что же делать, если система уже куплена, а маркетинг хочет странного?
Если маркетинг хочет странного - чего-то такого, что не реализуется в имеющейся системе рейтинга (а хочет он его, как правило, “на вчера”), то вариантов, увы, немного.
- Послать маркетинг. Я слышал, что бывают такие компании, в которых это возможно, но на практике с таким не встечался, и даже не видел людей, которые в таких компаниях работали.
- Заказать изменение системы у поставщика. Как правило, это дорого, долго и означает геморрой с поддержкой решения в будущем.
- Сделать какой-то костылик. Как правило, это быстро, дешено, и означает геморрой с поддержкой решения в будущем.
Какого рода костылик имеется в виду? Например, маркетинг хочет, чтобы каждый третий звонок абонента был бесплатным. “Правильное” решение - заказать у поставщика функциональность, которая позволит назначать каждому абоненту счетчики событий разных типов и возможность использовать значения этих счетчиков в рейтинге. Допустим, это занимает три месяца, а функциональность нужна уже через 5 дней, т.к. надо опередить ближайших конкурентов, которые, по слухам, собираются предложить что-то подобное.
Универсальный костыль выглядит так: пишется программка, в которую попадают все CDR-ы непосредственно перед рейтингом. Эта программа ведет и обновляет таблицу (номер абонента A, кол-во звонков), и модифицирует CDR-ы с каждым третьим звонком таким образом, чтобы потом можно было “заметить” эту модификацию в системе рейтинга и поставить звонку нулевой тариф.
Например, можно в каждом третьем звонке дописывать к номеру абонента B префикс “666”, а систему рейтинга сконфигурировать так, чтобы все звонки на направление 666 были бесплатными. Маленький update базы перед биллингом не позволит префиксу попасть в детальные распечатки абонентов :)
Или же можно превращать каждый третий звонок в событие какого-то нового типа, и в рейтинге проставлять всем событиям такого типа нулевую стоимость.
Вариантов - масса. Каждый оператор имеет свой “стиль” и свой любимый набор костылей, который он холит, лелеет и растит. Периодически совокупная масса костылей превышает критическую, и происходит смена биллинговой системы на другую (или апгрейд на новую версию), в процессе чего костыли убираются и реализуются “правильным” образом. После чего процесс создания костылей начинается заново - по неизведаной доселе причине рынку нужны именно те функции, которых нет в текущей используемой версии биллинговой системы :)