Не могу настроить биллинг

Развертывание биллинга для небольшой сети с нуля

Предыстория:
Некие хорошие люди решили начинать провайдерский бизнес. Растянули и разварили оптику в небольшом районе, поставили ящички, засунули туда минимальные свичи, с помощью которых можно организовать VLAN-Per-User, закупили небольшой, для начала, канал у ближайшего магистрала. Встал у них вопрос о том, чем же считать пользователям трафик/денежки и нарезать скоростя.
Общая схема сети должна выглядеть следующим образом:

Кому интересно, далее под катом очень много букв и картинок.

Условности:
— Шлюз аплинка будет 1.2.3.3
— Сетевые адаптеры NAS смотрящие на аплинка будут в сети 1.2.3.3/24
— Сеть, предоставляемая пользователям, будет 172.16.0.0/18, или, если угодно, 255.255.192.0
— IP адреса 172.16.0.0-172.16.0.10 мы резервируем для серверов доступа и прочих собственных нужд
— Сервер пользовательской статистики будет доступен по адресу stat.isp и, учитывая бюджетность решения, будет находиться на одном хосте с биллинговым сервером, хотя хорошим тоном является не только разделять биллинг и трафик абонентов, но и разносить на раздельные хосты БД, ядро биллинга и веб-интерфейс.

Изначальные потребности были четко оговорены:
— Проектная емкость сети — до 10000 абонентов
— Раздача IP абонентам при помощи DHCP
— Авторизация либо по связке IP+MAC
— Несколько полностью безлимитных тарифов
— Трафик все же считать нужно для контроля
— Очень желательно видеть активность каждого отдельного пользователя
— Разделение прав касиров/бухгалтеров/менеджеров/администраторов
— Возможность масштабирования решения относительно роста количества абонентов
— Так как своей АС еще нету и в наличии имеются три с половиной айпишки, выданных аплинком, первых пользователей предполагается NAT-ить.
— Естественно все это максимально бюджетно 🙂
Беглое изучение ассортимента opensource биллинговых систем показало, что оптимальным в данной ситуации может оказаться Stargazer по следующим причинам:
— Проект открыт, активно развивается, новые версии выходят с завидным постоянством.
— Не страдает врожденной монстроидальностью и позволяет допиливать функционал не привязываясь к внутренней механике
— Ядро написано на C/C++ и категорически быстрое
— Большой выбор методов подсчета трафика
— На выбор поддержка хранения данных в Файлах/MySQL/Firebird/PostgreSQL
— Волшебный механизм исполнения команд на удаленных серверах
Установка будет проходить на голую FreeBSD 8.2-RELEASE, установленную в варианте kern-developer + порты. Весь трафик пользователей будем рулить через удаленный NAS на все
той же FreeBSD 8.2, производя по нему NAT/Shape/NetFlow и отрисовку графиков загрузки абонентского канала при помощи bandwidthd. В роли вебинтерфейса для stargazer 2.407-p1 у нас будет выступать последний на момент написания топика Ubilling 0.1.7, хотя выбор фронтендов у Stargazer довольно широк — от Win-конфигуратора до нескольких консольных и XML-RPC API.
Далее прямой копипаст из консоли с периодическими заострениями внимания на концептуальных моментах.

Итак приступим к настройке биллингового сервера.

1. Морально готовимся
2. Установка зависимостей

Для простоты isc-dhcp собираем без DHCP_PARANOIA

php5 должен быть собран как минимум с поддержкой CLI и модулем Apache (последний должен нормально подтянуться зависимостью)

Собираем жизненно необходимые расширения PHP, а именно: ставим галочки на MYSQL, MBSTRING и ICONV

3. Собираем сам stargazer и его консольные конфигураторы в две строчки 🙂

4. Разворачиваем текущую версию Ubilling

5. Делаем особую симлинковую магию

6. Запускаем Apache и MySQL

7. Устанавливаем новый пароль пользователя root для mysql (newpassword — для примера)
#mysqladmin -u root password newpassword

8. Приводим /etc/stargazer/stargazer.conf к следующему виду

9. Редактируем конфиг /etc/stargazer/rules оставля аж одно нужное нам направление, а именно интернеты.

10. Добавляем наш первый NAS в /etc/stargazer/remote_nas.conf

10. запускаем/останавливаем stargazer

11. Убеждаемся, что умолчальная БД развернулась

12. Редактируем /usr/local/etc/sudoers, добавляя туда пользователя, под которым будет работать Web интерфейс

13. Разворачиваем дамп Ubilling

14. Убеждаемся, что все хорошо

15. Редактируем файл config/billing.ini, доводя его до кондиции:

16. Разворачиваем заготовки стартовых скриптов

17. И делаем прибивание IP+MAC в скрипте /etc/stargazer/OnConnect

18. Редактируем конфиг /etc/stargazer/config, прописывая в него текущие параметры MySQL

19. Аналогично редактируем конфиг config/mysql.ini

20. Запускаем stargazer и меняем пароль администратора по умолчанию

21. приводим наш /etc/rc.conf к виду

22. Добавляем служебную зону «.isp» в /etc/namedb/named.conf

и в /etc/namedb/master/isp

23. Создаем стартовый скрипт запуска stargazer в /etc/rc.d/billing

и назначаем ему нужные права

24. Прописываем нужные виртуалхосты в /usr/local/etc/apache/httpd.conf

25. Правим глобальный шаблон по которому будут генерироваться конфиги dhcp, он находиться вот здесь: /usr/local/www/data/billing/config/dhcp/global.template

26. Выставляем нужный уровень логирования для dhcpd в /etc/syslog.conf

27. Можем сделать профилактический ребут чтобы посмотреть как все подымается, либо поперезапускать все, что мы уже понастраивали вручную.

28. А теперь самое интересное ради чего все затевалось 🙂

Заходим на наш servername.isp/billing и логинимся с логином и паролем по умолчанию admin/demo (не забываем сразу же сменить) и видим следующую картину:

Добавляем нужный нам класс трафика:

Добавляем сеть и сервис (напоминаю, что мы резервируем первых 10 IP под свои нужды)

Добавляем сети обработчик DHCP

и применяем к нему свой шаблон подсети

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

Проверяем, удачно ли создается конфиг dhcpd.conf в справочнике «Сети»

Добавляем свой первый тариф, пусть он будет зваться Unlim-1 и будет безлимиткой с абонплатой 50 денег в месяц

Навешиваем на него симметричную скорость в 1 мегабит/с

Добавляем наш сервер доступа который мы будем настраивать чуть пожже

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

Ну и вроде все, регистрируем нашего первого абонента

Назначаем ему MAC, тариф, вписываем Ф.И.О. и все что нужно в «редактировании», и, в общем-то, он должен работать.

Настройка NAS сервера.

Опять же, имеем Голую FreeBSD 8.2, от которой хотим, чтобы она выступала шлюзом по умолчанию для наших пользователей.
Нужные модуля можно и просто подгрузить, но это дело привычки, так что соберем ядро руками с попутным выкидыванием всего что нам не нужно.

Заменяем в конфиге нашего нового ядра ident GENERIC на NAS1

И собираем/ставим его в одну строчку:

Следим за тем, чтобы наш /etc/rc.conf имел где-то такой вид:

Устанавлиеваем thttpd, которым будем показывать графички

Отличный сенсор NetFlow

И умеренно врущий, но идеально простой в настройке bandwidthd для отрисовки per-user графиков

PHP собираем с поддержкой CLI

И модуль MYSQL к нему

Приводим наш /etc/firewall.conf к виду:

Выставляем правильные права на наш скрипт инициализации фаервола

Собираем rscriptd и обеспечиваем его запуск при ребуте

редактируем /etc/rc.d/rscriptd, приводя его к виду

и назначаем ему правильные права

Разворачиваем заготовки скриптов Ubilling

Редактируем конфиг /etc/rscriptd/config, прописывая в него текущие параметры MySQL для того, чтобы скрипты GetSpeed, GetUpSpeed, GetMAC могли нормально получать информацию о пользователях.
Также, не забываем поправить /etc/rscriptd/OnConnect, указав в нем входной интерфейс для шейпинга, который в нашем случае

Настраиваем bandwidthd для того, чтобы он рисовал красивые графики, которые мы потом должны лицезреть в Ubilling:

В файл /usr/local/bandwidthd/etc/bandwidthd.conf вписываем сеть наших пользователей

добавляем периодический SIGHUP для bandwidthd в crontab -e

И опять страшная симлинковая магия, чтобы наш thttpd мог нормально показывать графички

Обеспечиваем при загрузке запуск

И как последний штрих, добавляем более-менее универсальные вещи, помогущие хоть как-то поднять быстродействие в дальнейшем в /etc/sysctl.conf

После перезагрузки получаем работающий NAS, получающий удаленно команды от биллинга, отправляющий ему сведения о трафике и все остальное, что от него требовалось.
Хотелось бы еще написать о настройке кабинета пользователя, недокументированых «фичах» с переходом на следующий месяц и прочих вещах, на которых можно споткнуться в первое время. Но статья и так уже получилась слишком монстроидальной и нудной. Обещаюсь, если карма позволит, на недельке описать все эти вещи в отдельном сказании.

Источник

Как там биллинг делается: когда заказчик и разработчик говорят на разных языках

Биллинг — не просто калькулятор

Биллинговые системы давно не просто ведут баланс клиента и выставляют счета. Они глубоко интегрированы в бизнес: обеспечивают контроль трафика, управляют процедурой предоставления доступа к услугам, предоставляют клиенту отчет о расходах в разных разрезах — за месяц, за год, с момента последнего платежа. Плюс биллинговая система, как правило, должна поддерживать множество балансов пользователя: монетарный и несколько вещественных (бонусы, минуты разговора, гигабайты трафика и т.д.). Не говоря уже о партнерских программах и прочих вариантах кросс-продаж. То, что называется современный конвергентный биллинг. Реализуется он за счет интеграции тарификатора с другими модулями и подсистемами: CRM, PRM, BPM и т.д. Для разработчиков это не “сокровенное” знание. Как говорится, разделяй функции и властвуй. Но для пользователей биллинга, даже технически грамотных, мысль, что с “калькулятором” сложновато общаться напрямую, порой оказывается новой.

Пример из нашей практики. Клиент — небольшая, но перспективная компания. У них не хватало бюджета на биллинговый комплекс целиком, они попросили убрать модуль BPM (business process management). Нужно отдать должное, там работали достаточно продвинутые в техническом смысле ребята. Сказали, возьмут open source решение, настроят, интегрируют с системой. Мы согласились. А через четыре месяца “утонули” в их обращениях в техподдержку по поводу некорректных данных.

BPM — система, которая, помимо прочего, при подключении абонента занимается валидацией данных, и не пропускает тебя на следующий шаг, пока ты не заполнишь все необходимые параметры — технические и персональные. А они от BPM отказались, и нарисовали просто интерфейс для ввода данных. Люди, которые принимают заявки на подключение — не высокооплачиваемые специалисты, там большая текучка, малое время обучения персонала. Естественно они постоянно делали ошибки при внесении данных. Итог — в конце месяца компания выставляет счета, а тарификатору не хватает параметров. Он “ругается”, выдает сообщения об ошибках. Клиент звонит в поддержку. В конце концов, мы приняли решение подарить им BPM в дефолтных настройках. У них все стало сходиться, а у нашей техподдержки стало меньше головной боли. Теперь мы вообще не продаем биллинг без BPM, кроме случаев если он уже внедрен и есть варианты интеграции с ним. Если у клиента не хватает денег на минимально необходимый комплект, предлагаем аренду или аренду с возможностью выкупа через пять лет. Или, если это какой-то стартап, но видно, что люди серьезно относятся к делу и у них есть перспективы, предлагаем схему ревенью. В любом случае это бережет нервные клетки и нам, и руководству компании-клиента.

Гибкость — понятие растяжимое

Непродуманная архитектура биллинговой системы оборачивается не только техническими сбоями. По нашему опыту, в 70% случаев необходимость замены биллинга возникает из-за недостаточной ее маркетинговой гибкости. Телеком-рынок сейчас перенасыщен, и заполучить себе новых клиентов компании могут, только отбив их у конкурентов. Даже крупные провайдеры, осваивая новые ниши и расширяя территорию присутствия, начинают демпинговать, а уж новым игрокам на рынке “сам бог велел” привлекать к себе внимание уникальными предложениями. Разворачивается настоящая война тарифов. И тут уже маркетологи хватаются за голову: “Мы сможем вывести в продажи ваш новый инновационный тариф “Супер-Новогодний” только к июлю”, — приходит сообщение от IT-отдела.

В чем проблема. В очень небольшом числе биллинговых систем есть, например, отдельный модуль продакт-каталог, который позволяет легко комбинировать услуги в пакеты и настраивать акции. Параметры которыми он оперирует могут быть как услуги так и отдельные параметры такие как минуты разговора, пакеты трафика или услуги предлагаемые партнерами(так называемые услуги третьих лиц), например билеты в кино или поездки на такси. Есть мнение, что продакт-каталог — это вообще элемент CRM-системы, а не биллинга. Но да будь оно даже так, не во всех компаниях есть отдельная CRM. Многие обслуживание абонентов ведут прямо в биллинговой системе. А это значит, любая новая услуга, новый тариф, новая акция — и “айтишникам” нужно не собрать ее в конструкторе, а добавлять поля и писать строчки кода. Вот уже и июль не за горами.

Правда, маркетологи обычно не понимают, что имеет в виду вендор, говоря, что его система “достаточно гибкая”. Достаточно для чего? “Комерсантов” в первую очередь интересует time-to-market, время, необходимое, чтобы выпустить услугу на рынок. Однажды представители клиента — регионального оператора, в чей регион пришла федеральные игроки — прямо на презентационную встречу принесли нам описания 3 кейсов конкурентов которые они не смогли реализовать у себя. Поставили вопрос ребром: за какой срок сможете настроить в вашей системе? Не грех похвалиться — один кейс в тестовой среде мы настроили прямо при них, пока шла презентация. Вообще, при продуманной архитектуре биллинга любой и использовании продукт -каталога любой пакет или акцию можно настроить и вывести на рынок за 2-3 дня, не считая времени маркетингового и функционального тестирования. Проверять, может ли это конкретный биллинг, лучше еще на этапе знакомства. Потому что нередки случаи, когда настройка нового тарифа в “достаточно гибкой” системе на самом деле занимает несколько месяцев.

Между централизацией и автономией

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

Но есть одно извечная проблема, которую распределенные системы решить не в силах — это банальный фрод на местах. У нас было несколько таких примеров. В частности на Украине, где мы внедряли централизованный биллинг, перенося данные из недавно приобретенных региональных филиалов. Когда мы мигрируем данные, мы делаем ряд проверок и сравнений, все несоответствия попадают в соответствующие отчеты, и после этого обычно начинает шевелиться служба безопасности компании-заказчика. Чего там только не находится. Абоненты, подключенные мимо учетных систем, “нулевые” тарифные планы и т.д… Было и откровенное мошенничество: компанию продали, а квитанции абонентам еще какое-то время выставляли на левые реквизиты.
Организация единого расчетного центра делает все такие ситуации прозрачными, в регионах остается только функция абонентского информационного обслуживания поэтому возможности для фрода практически не остается. Плюс большая клиентская база, сведенная в единую систему, позволяет на совершенно ином уровне анализировать и прогнозировать поведение клиентов. Мы постепенно начинаем применять к таким большим данным наши системы аналитики построенные на машинном обучении. Например, можем выделить в клиентской базе “группы риска” — тех, кто в ближайшее время может отказаться от услуг компании. Это выявляется по тому, как люди платят, как они пользуются сервисами, личным кабинетом, как общаются с колл-центром, сколько и по каким причинам у них блокировой.

Правда, централизация биллинга приносит с собой другие проблемы. Нужно, чтобы региональные филиалы сохраняли долю технической независимости. Иначе, если вдруг центральный расчетный центр окажется “вне зоны доступа”, обслуживание абонентов в регионе может пострадать. Мы ее решаем за счет “выносов” на периферию: серверов авторизации, элементов сбора и обработки трафика, элементов сервис-провижининга. В частности для мобильных операторов наша препейдная платформа(Forward Fusion) может тарифицировать услуги автономно и ждать, когда восстановится связь, чтобы синхронизировать данные с биллинговым центром. Региональные абоненты при этом могут заметить, что стал недоступен личный кабинет, но деградации предоставляемого сервиса при этом не происходит.

Сервер, который поставил Джек: где хранятся данные?

Есть много вариантов, как и где разместить биллинговую систему. Часто компании переживают за сохранность данных клиентов, сами покупают сервера и ставят в своем дата-центре. Но не все могут потянуть их качественное обслуживание. Иногда у клиента что-то сломалось, а он даже не понимает, что это на его стороне. Звонит нам в техподдержку, и уже наши админы ему рассказывают, где поломка, какой сервер не отвечает. У нас система настроена так, что она постоянно “мониторит” по многим параметрам обслуживаемые системы, и поднимает тревогу, если что-то не так. Так что мы заранее можем сообщить, что кончается память или скорость какого либо важного процесса снизилась ниже нормы. Но это к сожалению не отменяет форс-мажоров.

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

Бываю ситуации когда наоборот, привозят свои сервера и ставят в наш сертифицированный по Tier III дата-центр.

Еще один распространенный вариант — у нас арендуют вообще все. Тогда мы полностью отвечаем и за “железо” — и за обслуживание, и за то, чтобы вовремя увеличивать необходимые мощности. По этой причине в определенный момент мы стали использовать частные облака. Если у нас выросла нагрузка, мы меняем настройки, и нам выделяются дополнительные вычислительные мощности. Не нужно бесконечно заниматься непрофильным для нас “апгрейдом” оборудования. Российские компании, которые сегодня предлагают услуги публичного облака, к большому нашему сожалению пока не могут предоставить тот уровень гарантированной производительности, которого требует биллинговая система. У них можно хостить сайты, можно разворачивать интернет-магазины или поставить 1С. Поэтому нам пока приходится активно участвовать оптимизации и тестировании решения для различных частных облаков, например недавно начали использовать OpenStack.

Базы данных: важно не только где, но и как

Важность выбора базы данных для биллинга сложно переоценить. Высокой производительности тут можно добиться, только оптимизировав биллинговую систему под конкретный продукт. Forward Billing оптимизирован под работу с двумя СУБД: Oracle Database и PostgreSQL). В прошлом году Forward Billing был включен в реестр российского ПО, разрешенного для использования в государственных компаниях. И вот недавно пришла новость, что через полгода из реестра начнут исключать разработки на базе иностранных СУБД. С точки зрения государства, это понятно. В условиях, когда чуть не каждый день под санкции попадают все новые российские компании, им хочется обеспечить полную независимость российского ПО. Но для вендоров это грозит приличными дополнительными затратами. Думаю в этом вопросе мы как и весь остальной рынок ждем от законодателей более четких разъяснений на этот счет и после этого будем корректировать свою стратегию.

SLA: определитесь с приоритетами

Где-то в идеальном мире уровень техподдержки от поставщика определяет четко прописанное SLA — Service Level Agreement, оно же Соглашение об уровне оказания услуг. Чем SLA отличается от просто договора, где фиксируются положенные клиенту часы поддержки? В нем прописаны конкретные требования к сервисному обслуживанию: скорость приема заявки, время решения проблемы — и система штрафов, которые накладываются на поставщика, если требования не соблюдены.

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

Часть сталкиваемся с тем, что небольшие компании, которые приобретают готовые “коробочные” решения для биллинга в случае возникновения проблем оказываются 376-ми в очереди на техподдержку. Часто для таких компаний более оперативной оказывается помощь сообщества пользователей этого продукта на интернет-форуме.

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

Источник