4775 читателей, 1103 поста
Администрация
Модераторы
Пока пузырь не лопнул во второй раз.
АСР «Реквест-Биллинг»
Каждая новая задача начинается с выбора инструментов, с помощью которых она будет реализована. И от того, насколько верно они выбраны зависит её win или fail. Мне довелось присоединиться к проекту с базовым языком программирования, весьма необычным и редкоиспользуемым. И это отнюдь не мешало его становлению и текущему успешному развитию. О чём это я?
Как вы могли уже догадаться по тегам, речь идёт о Smalltalk. Данный язык позволяет органично развивать и поддерживать код большой степени сложности, используя современные Agile-методологии, такие как Test Driven Development, Refactoring, Continuous Integration и т.п. Именно он был выбран в качестве средства разработки биллинговой системы в далёком 2001 году в Тверском интернет-провайдере «ТелеNET». Все эти годы Smalltalk (и биллинг, написанный на нём) оставался секретным оружием компании, пока было не принято решение выпустить джина на свободу, передав его разработку в компанию «Реквест». Так появился наш продукт — Автоматизированная Система Расчётов «Реквест-Биллинг».
Надо добавить, что к моменту моего вступления в команду разработчиков, у меня уже был опыт разработки биллинговых систем (открытая АСР TBilling, которая успешно используется в Тверском Государственном Университете), но в таком большом проекте я принимал участие впервые.
Как это сделано?
Мозгом биллинговой системы является сервер приложений, написанный на Dolphin Smalltalk, вся бизнес-логика заложена именно в нём. Он обрабатывает все данные с центров авторизации и сбора статистики/предбиллингов (о которых я расскажу чуть дальше), и сохраняет их в центральной базе данных под управлением Oracle. Благодаря выбору высокоуровневого средства разработки удалось достичь фантастической гибкости всех компонентов системы; для примера рассмотрим модуль тарификации. У нас были реализованы без особых усилий тарифные планы, в которых еженедельная скидка рассчитывалась исходя из наработки за предыдущую неделю или автоматически добавлялась к пользователям, которые подключились к провайдеру более года назад. Естественно, что посчитать обычные безлимитные тарифы не составит никакого труда.
Предбиллинги работают с разными типами серверов доступа и АТСками. Спектр оборудования, с которым работает предбиллинг весьма широк и благодаря этому есть возможность обрабатывать данные разных типов доступа: широкополосный интернет, dialup, обычная и ip телефония, карточная платформа. Предбиллинг также интегрирован с собственной системой хостинга и почтовым сервером.
Ещё одной важной частью нашей системы является сервер обработки платежей. Он позволяет проводить платежи из самых разных источников: 1С, системы моментальной оплаты, банкоматы; специальный модуль 1С позволяет обмениваться с этим сервером другими данными по клиентам.
Графический интерфейс биллинга является унифицированным как для сервера, так и для клиентских мест (абонентский отдел, техподдержка, и т.п.) и его функциональность определяется профилем конкретного пользователя. Для абонентов предусмотрен веб-интерфейс, через который можно посмотреть статистику наработки, баланс и т.п.
Как мы работаем?
Отличительной особенностью нашей компании является возможность полного аутсорсинга услуг биллинга для операторов связи. Это успешно опробовано нашими партнёрами и доказало свою эффективность. Фактически у оператора отпадает необходимость в собственной службе биллинга; наши ежемесячные услуги вполне сравнимы с затратами на содержание среднего специалиста по биллинговым системам в замкадье.
Куда мы идём?
А идём мы к расширению способов получения данных биллинга. Для этого нами разрабатывается веб-интерфейс биллинговой системы на основе Seaside и система генерации отчётов на базе Ruby On Rails. Кроме того мы постоянно работаем над расширением функционала нашей системы для удовлетворения нужд наших клиентов.
Готов буду рассказать подробнее о каком-либо аспекте работы АСР «Реквест-Биллинг» и о биллинговых системах в целом или даже может быть о Smalltalk, задавайте вопросы в комментариях.
UPD По просьбам трудящихся добавляю скриншот окна редактирования договора:
комментарии (90)
С удовольствием расскажу о технических подробностях. Что вас интересует? Предбиллинг, Cisco-Radius, Netflow? Подробности реализации ядра биллинга? Интеграция с платёжными системами?
Из чего состоит предбиллинг, какой механизм обеспечивает актуальность информации которая в нем хранится?
Умеет ли система работать с Cisco ISG, если да, то ограничивается ли ее интеграция предбиллингом или он таки «вжился» глубже?
А почему «Cisco-Radius»? Или под этим «термином» прячется что-то типа упомянутого SSG/ISG?
А это уже не совсем вопрос, скорее недоумение: нафига в биллинге NetFlow?!?
С Cisco ISG не работает.
NetFlow, как и IP Accounting — способы учета трафика.
Мы давно пришли к выводу (а в Cisco по-моему всегда так думали), что использовать NetFlow для учета трафика очень неудобно. Все данные и него в SQL не запихаеш, а использовать для него отдельный агрегатор — лишнее, часто очень ненадежное, звено.
IP accounting, NetFlow, Radius — предбиллингу есть чем занятся :) При использовании ISG все гораздо проще.
ISG это классно, но пока у текущих партнёров его нет.
А Смолтолк с тех пор мой любимый язык. Вместе с Лиспом. Правда я ничего крупнее самодельного веб-сервера на Смолтолке не писал, слишком он громоздкий для моих задач был, так что любовь моя к Смолтолку эдакая теоретическая-платоническая :)
На скриншоте не лог-файлы, а списки договоров. Списки. У вас есть альтернативный способ как их показать?
«Халява» возле галочки, что за фамильярность в серьезном продукте? :)
А что означет «Отключать по выработке тарифа» я могу только догадываться :( Очень распостраненная проблема (сами страдаем), такой себе внутренний жаргон провайдера. По собственному опыту знаю, как такие терминологические выходки ставят в тупик оператора, который систему видит первый раз. Усугубляется этот эффект еще и тем, что он до этого использовал другую систему, в которой жаргон был похлеще :)
«Отключать по выработке тарифа» это сокращение фразы «Отключать клиента по исчерпанию трафика, входящего в обязательную ежемесячную абонентскую плату тарифного плана». Тоже пережиток прошлого.
Что за ханжество на серьёзном хабрахабре?
это динамический, насколько я понимаю, список, которые чутко реагирует на любое нажатие клавиши и мгновенно применяет фильтры.
Это вопрос Spotlight vs TotalCommander, не находите?
Я за аскетичные, но не в ущерб понятности, интерфейсы. Такие и стараемся делать.
Мне ничего в голову не приходит кроме как прятать неиспользуемые поля в отдльные формы
в биллинге особенно красиво будет смотреться :)
Если ориентация на маленьких провайдеров.
К тому же еще язык который никто не знает ( это не перл-си-питон-пхп )
Система неизвестная, не проверенная. Да и АПИ закрытый наверно. А даже если и открытый то из-за смолтолка будет гемора нереально.
Маленькие провайдеры, конечно, хорошо, мы им рады, но лучше если будут средние, это наш размерчик :)
Система проверенная, работает с 2001 года. API предбиллинга открытый, там не Smalltalk, а в самом ядре все операции осуществляются через стандартный интерфейс, там копаться негде.
5 инсталляций биллинга, конечно не цифра, но тем не менее гарантирует достаточную «проверенность».
при этом модулей практически нет. Другие биллинги и стоят дешевле, и модулей больше ( и история дольше, и комьюнити больше-как у бгбиллинга)
Поэтому сравнивая чисто по функционалу и цене, вы выпадаете. Кстати техподдержка тоже дорогая, как у Billmaster практически.
Поэтому цена должна быть сильно ниже. Или например вы все делаете бесплатно и если система заказчику понравилась, то он тогда платит.
В стоимость техподдержки входят все услуги, связанные с обслуживанием и администрированием. Если вы готовы от этих услуг отказаться — мы предложим вам специальные цены.
> Или например вы все делаете бесплатно и если система заказчику понравилась, то он тогда платит.
Это какая-то странная бизнес-модель.
С удовольствием узнаю название «другого» биллинга.
>> Какой вопрос? Про другой биллинг? Я не занимаюсь этими вопросами но точно знаю, что их много. Не очень понятно почему вы думаете что другой биллинг окажется эталоном совершенства…
Вас там точно один человек пишет под этим ником?
Да, на мой взгляд, принцип «лучшее — враг хорошего» в IT переформулируется так: «лучшее — враг работающего» :)
По результативному окончанию напишу впечатления.
Из того, что я видел такого рода — Traffic Inspector почти без вариантов.
Но думаю это будет не в этом году.
Я даже не говорю про закон 152 ФЗ.
Про 152 ФЗ думаем.
2) Логика обработки данных вся вынесена или часть реализована средствами Oracle?
3) Поддержка контентного биллинга?
4) DIAMETER?
5) Есть возможность разбора CDR? И если есть, то на сколько развит инструментарий?
6) Можете чуть-чуть поподробнее «предбиллинг» описать таки?
7) RADIUS самописный. Разные «реалмы» умеет? Проксировать с модификацией пакета тоже?
2) Вся логика вынесена. Планировалась легкая портируемость с одной системы БД на другую. Есть в запросах какие-то специфичные оракловые вещи, но сказать, что привязка жёсткая нельзя.
3) Расшифруйте, пожалуйста. Увы, это не общепринятое понятие.
4) Надо?
5) Делаем как бинарные, так и plain-text разборы наиболее распространённых платформ. Если не будет хватать вашего формата — сделаем для вас бесплатно.
6) Можно. Давайте только отдельно статьёй.
7) См. 6, напишем.
В общем, настораживает меня ваша архитектура.
3) Самая представительная железка Cisco CSG. Направление перспективное. Особенно для Wi-Fi сетей. И вполне общепринятое понятие.
4) Ну как бы диаметр — эволюция радиуса, и возможностей побольше и попроще, мне по крайней мере. Жаль железки го плохо пока поддерживают.
5) Т.е. возможности настроить разбор самостоятельно, без привлечения разработки нет?
6) Пишите, очень мне интересно будет почитать.
Cisco CSG пока не поддерживаем.
Что такое diameter я знаю. Я спрашивал, зачем поддерживать ещё и его.
Мы настраиваем все ваши форматы CDR на этапе инсталляции.
8) Опишите систему отчетности.
9) Руководство пользователя — хлам. Перепишите.
9) Знаем, извините. Пока оно deep under construction.
Модель лицензирования и ценообразования понятна — предоставить клиенту сервис и чтобы он ни о чем не парился, а только башлял каждый месяц. А тот кто предоставляет сервис постарается все один раз настроить и потом спокойно собирать деньги. :-) Однако, я бы не сказал, что она оптимальна с точки зрения операторов связи. :-) У оператора связи всегда есть свой/свои админ/админы, а у оператора среднего размера — даже зачастую программист. ;-) Платить кому-то ежемесячно за сопровождение совершенно не интересно, учитывая, что все равно должен быть человек, который худо-бедно знает и понимает биллинг, чтобы грамотно ставить сопровождающим задачи и грамотно их контролировать. Ну, а раз он уже худо-бедно понимает, то все приходят к тому, чтобы он его и ковырял. :-) Это не умозаключения, а реальная жизнь, проявления которой я видел неоднократно. И именно в этой связи наиболее оптимальна все-таки схема лицензирования и вообще характеристики BGBilling'а: достаточно высокая плата за вход (но и не заоблачная — в 100 штук плюс-минус укладывается все-все-все), бесплатные обновления после покупки и максимально открытая документация. Хочешь новый функционал — плати, но хотя бы понятно, за что платишь. Не хочешь платить и сам весь из себя умный — читай доки, ковыряй API и сам пиши примочки, благо все на Яве, а ее сейчас только ленивый не знает.
В общем, я бы будучи руководителем со всем этим хозяйством связываться не стал. Зачем себя привязывать за свои же деньги к поставщику, который будет продолжать тебя «доить» и с продуктом которого будут проблемы в поддержке (попробуйте найти специалистов по Smalltalk)? Я ни в коем случае не умаляю возможных достоинства выбранного языка и качеств продукта, но не вполне уверен в том, что это то, что нужно массовому рынку.
На вопросы выше попытался чуть подробнее ответить.
Ну у нас тоже есть партнеры-операторы связи — они тоже ни о чём не парятся. Мне кажется, многие вещи здесь вы говорите как админ, а не как руководитель предприятия. Понимаете, ковырять надо там, где шаг влево-шаг вправо расстрел. У нас ковырять ничего не надо, всё уже сделано, или будет сделано при лучшем соотношении цена/качество.
Мы не хотим быть еще одним бгбиллингом, ланбиллингом, нетапом. Когда клиент заплатил деньги, а потом имеет секс с программой за собственные деньги. Ваш биллинг — наша головная проблема. И у нас не возникнет проблем с пониманием требований заказчика. Как, собственно, и заказчика не будет волновать, на чём это написано — на Smalltalk или бейсике.
Опять же, аутсорсинг у нас в стране развит слабо и руководителю любого уровня будет не вполне понятно, зачем он должен платить деньги вам, когда у него в штате есть -дцать админов/программеров и обслуживание биллинга входит в их компетенцию. При этом работая с вами процесс явно усложняется: одно дело вправить мозги и наорать на своего сотрудника, а другое — взаимодействовать и коммуницировать с посторонней организацией, от которой все время надо всего добиваться… Короче, административные/организационные/транзакционные издержки больше и чтобы это понять — не нужно быть семи пядей во лбу.
Такого, чтобы ничего не надо было ковырять — не бывает. Биллинг — это, к сожалению, не унифицированный продукт и приходится либо изначально раздувать его функционал, либо делать доступным тот же API, чтобы заказчику было иметь секс с биллингом максимально просто и комфортно. :-) Т.е. в теории у вас все, конечно, верно — насчет разделения труда и ответственности и все такое, — но практика немного иная получается. Такая, что одна половина операторов связи пишет биллинги сама (совершенно не круто и нетехнологично, а как им удобнее и как им нравится), а другая, которая все-таки использует покупные решения (все-таки их существенно быстрее разворачивать и меньше проблем с сертификацией), перманентно жлобится на тех.поддержку и оплату доп.услуг производителя и хочет как раз всякие API. Почитайте форум НетАпа — какая там эпопея длиной в несколько лет был насчет доступа к закрытому протоколу URFA по общению с ядром. И как народ сейчас счастлив тому, что хоть что-то получили, так что могут теперь — пусть косо, криво и не все, что хочется, но все-таки — самим чего-то дописывать и иметь секс с биллингом, что их совершенно не смущает и не коробит. :-) И про БГБиллинг тоже почитайте — как народ радуется изначально открытому API и какое удовольствие от секса с биллингом получает. :-)
Короче, тезис всего моего флуда очень прост: отечественному массовому потребителю АСР не нужны продукты под ключ и он не хочет отдавать кому-то обслуживание биллинга на аутсорсинг (кстати, пришел в голову еще один аргумент за это — ведь в биллингах зачастую куча «черной» информации, которую боятся слить на сторону). Подчеркиваю — массовому потребителю. Вы вполне можете иметь свою нишу — несколько клиентов, с которыми вы вплотную работаете, которых обслуживаете и для которых вы по сути — если говорить прямо — и пишите свой биллинг. В этом нет ничего плохого, просто надо это осознавать. И если вы хотите идти на массовый рынок, то что-то менять и о многом дополнительно думать.
Все вышесказанное, конечно же, исключительно мое личное мнение, не претендующее на объективность. :-) Но мне кажется, что я не так уж и неправ. :-)
ps: Отдача бух.учета на аутсорс не считается — из-за своей банальности, очевидности и т.п. ;-) Вот будет у вас много клиентов — попробуйте тех.поддержку 1-го level'а на аутсорс отдать. :-) Дык нет же — предпочтете пару студентов посадить на телефон. :-)
На самом деле, нас просто ещё никто не спрашивал про API именно для сервера, поэтому и не заморачивались на эту тему.
И так далее, и тому подобное. В сфере банального районного провайдинга огромное количество всяких разных возможностей, услуг и т.п. — я уж не говорю о более серьезных уровнях. Учесть их всех изначально — невозможно. Особенно, если вы небольшая организация. Поэтому API — это единственный адекватный путь расширения.
Но, повторяюсь, если вы не нацелены на широкий рынок — то вам должно быть по фиг. :-)