Биллинговые системы провайдера: из чего они состоят

Абонент видит от биллинга одну строчку: «спишется столько-то числа». Внутри же это самая ответственная система оператора: она пускает людей в сеть, меряет потреблённое, считает деньги и отвечает перед бухгалтерией за каждую копейку. Сбой сайта оператор переживёт, сбой биллинга значит, что несколько тысяч абонентов либо сидят без сети, либо пользуются ею бесплатно. Разберём, из чего состоит такая система, которую в отрасли называют АСР: автоматизированной системой расчётов.

Путь абонента через биллинг

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

Модули современной АСР

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

Коробка, SaaS или своя разработка

Малые сети начинают с коробочных систем: поставил на свой сервер, завёл тарифы, работаешь. Плюс в контроле и разовой цене, минус в том, что обновления и резервные копии на вас. Облачные АСР снимают эксплуатацию, беря абонентскую плату за учётную запись: для сети на несколько тысяч абонентов это часто дешевле зарплаты администратора. Свою разработку выбирают операторы с нестандартной моделью: виртуальные операторы, провайдеры с посуточной тарификацией, сервисы, где биллинг и есть продукт. Это самый дорогой путь, зато без ограничений чужой архитектуры.

На что смотреть при выборе

• Поддержка вашего оборудования. Авторизация и сбор счётчиков должны работать с конкретными моделями ваших коммутаторов и BRAS, а не «в целом».
• Скорость блокировки. Сколько проходит между нулём на балансе и реальным отключением: часы разницы это подаренный трафик.
• Перерасчёты. Смена тарифа задним числом, возвраты, обещанный платёж: именно на этих сценариях коробки ломаются чаще всего.
• Открытое API. Кабинет, сайт и мобильное приложение будут жить дольше, если их можно строить поверх API, а не внутри чужого шаблона.
• Нагрузочный запас. Система, бодрая на тысяче абонентов, может встать на пятидесяти тысячах в день массового списания.

Отдельная статья расходов: миграция. Переезд со старой АСР тянет за собой историю балансов, незакрытые периоды и обещанные платежи. Хороший подрядчик начинает с инвентаризации именно этих хвостов, плохой с демонстрации красивого кабинета. Запланируйте параллельную работу двух систем хотя бы на один расчётный период: сверка начислений по живым абонентам находит то, чего не покажет ни один тест.

Типичные ошибки внедрения

• Биллинг после сети. Сначала строят сеть, потом прикручивают расчёты. Правильно наоборот: схема авторизации и учёта диктует выбор оборудования.
• Тарифы «как у соседа». Система умеет гибкие тарифы, а в неё заводят три строчки. Потом каждая акция превращается в ручные перерасчёты.
• Один сервер на всё. База, RADIUS и кабинет на одной машине работают до первого дня массовых списаний. Хотя бы базу стоит отселить заранее.
• Нет тестового контура. Обновления катятся сразу в бой, и первая же ошибка тарификации стоит дороже тестового стенда за всю его жизнь.
• Резервная копия без проверки восстановления. Копии делаются годами, а восстановление впервые пробуют в аварию. Прогон восстановления раз в квартал обязателен.

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

Если вы подбираете систему под растущую сеть, полезно смотреть не на список функций, а на два вопроса: как она переживает день списания и насколько просто вынести из неё данные при переезде. Остальное наращивается, эти два свойства закладываются архитектурой. Про смежную инфраструктуру сети мы писали отдельно: обзор типов серверов в сети поможет разложить по полочкам, где в этой картине место самого биллинга.