Carbon billing 5, обсуждение

[Saab95]

13 часов назад, intergeo26 сказал:

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

А что там за интерфейс? Одна страничка с выводом абонентов? И чем он на карбон похожий, ничего даже и близкого нет.

 

11 часов назад, tkama сказал:

А по поводу того что меньше года, ну все когда то были новичками. Да и уставной в 10к обычное дело.

Биллинговая система должна быть сертифицированная, должна быть связь с СОРМ, с разными платежными системами. Все надо установить и отработать.

 

А тут какие-то люди решили свой биллинг выставить на продажу, так подобных уже много было, тот же феликс, еще парочка подобных. Только где их довольные пользователи?

[Dude]

14 часов назад, Saab95 сказал:

А тут какие-то люди решили свой биллинг выставить на продажу, так подобных уже много было, тот же феликс, еще парочка подобных. Только где их довольные пользователи?

Видимо, они хотят на живых людях потренироваться, обрасти всякими интеграциями и т.п.

А потом уже и цену увеличивать ))

[ixi]

В 16.04.2025 в 03:30, tkama сказал:

Никто с RusBilling не сталкивался? чем то похож на 5 карбон биллинг, не отпочковался ли кто из бывших работников карбона? 

Цена интересная, но всё очень базово и нет даже упоминания о сертификации биллинга

[De1m0s]

Добрый день, коллеги. Подскажите, кто-нибудь обновлял базу данных Carbon Billing 5 до версии 5.0+? как прошло? есть ли заметные улучшения? какие подводные камни?

[Saab95]

Больше интересует сделали ли возможность удалять абонентов из корзины без закрытия периода.

[product manager CB5]

Добрый день. Обновление СУБД Firebird до 5 версии рекомендуется, в первую очередь, для крупных БД (5-10 тысяч абонентов) при использовании RADIUS. В этом случае существенно повышается быстродействие и отказоустойчивость. Переключение СУБД выполняется инженерами биллинга по согласованию заранее через HelpDesk. 

По поводу удаления абонентов из корзины задача в планах есть.

[De1m0s]

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

Насколько я понимаю, никакие скрипты управления не будут затронуты? то есть нам не нужно будет перенастраивать взаимодействие с NAS/BRAS? не сломается взаимодействие с банками? будет работать кастомная выгрузка данных в СОРМ?

Ну и если есть, хотелось бы услышать отзывы тех, кому БД обновили.

[De1m0s]

В тему удаления абонентов из корзины. Вопрос тоже интересует, но я бы предложил развить и реализовать ее следующим образом:
1. Возможность массового удаление абонентов из корзины абонентов, которые находятся там более 3х лет. Желательно с возможностью выбора адреса и/или тарифа на котором абонент был. 
Обоснование: руками удалять очень долго, если абонентов в корзине скопилось много. А 3 года - сроки давности сверх которых у нас уже ничего не запросят. Да, в теории, пропущенный срок давности можно восстановить, но это больше исключение, чем правило. Выбор тарифа или адреса обусловлен тем, что, например, у нас в курортном городе, некоторые абоненты могут и 4 года не приезжать, а потом приехать; таких мы восстанавливаем и они продолжают работать и мы точно знам, по каким адресам или тарифам человек может вернуться, а по каким с 99% вероятностью этого абонента у нас уже никогда не будет.
2. Возможность массово перемещать абонентов с тарифа для должников в корзину с указанием в комментарии (или другом поле) IP коммутатора, номера порта, серийного номера оборудования, с возможностью выбора периода на протяжении которого абонент находится в тарифе для должников.
Обоснование: руками удалять очень долго, так как нужно зайти карточку абонента, понять сколько времени он находится в тарифе для должников, далее зайти в учетную запись, скопировать все нужные данные, потом сохранить в комментарий и только после этого удалить абонента в корзину.

Еще полезная вещь, которую хотел бы предложить и, думаю, меня поддержат многие. Добавление возможности в автоматическом режиме вернуть абонента на тот тариф, который у него был с тарифа для должников при достижении необходимой для списания суммы на балансе.
Обоснование: это даст возможность разгрузить поддержку от этих операций и/или объяснений абоненту как это сделать в ЛК, а если у абонент потерял договор, то восстановить логин и пароль и т.п. О возможности взимания платы с должников через функционал пени я подумал, но это доп.услуга которая будет видна в списке услуг в ЛК, которая будет вызывать массу вопросов у абонентов (и крики благим матом у тех, кто подвержен сезонным обострениям) и которую в случае чего нельзя удалить из тарифа к которому подключены абоненты. С одной стороны с пеней мы фактически получаем то, что нужно, но очень неудобно.

[Saab95]

4 часа назад, De1m0s сказал:

2. Возможность массово перемещать абонентов с тарифа для должников в корзину

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

[De1m0s]

@Saab95 

В 23.10.2025 в 23:41, Saab95 сказал:

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

Все абоненты рассортированы по тарифам. Для каждого региона есть свои тарифы. Так же есть дополнительное деление для тарифов с IPTV и промо тарифов. Все группы тарифов объединены в группы тарифов. Все должники перемещаются в общий тариф для должников, все должники на одном тарифе. Но при перемещении на этот тариф не переопределяется привязанная линейка, равно как и после удаления абонента линейка тарифов не переопределяется. В случае с должником, если абонент может сам в ЛК себе все сделать проблем нет никаких, ему доступны тарифы только из его линейки он их активирует и все, если абонент сам не может, тот тут как раз было бы очень полезно описанное выше предложение о возврате абонента на предыдущий тариф при наличие достаточного количества средств для списания.
В случае с удаленным абонентом, он не сможет ничего сам сделать без вмешательства поддержки. Тут уже тот, кто его восстанавливает сам сможет поставить нужный тариф.

[Saab95]

12 часов назад, De1m0s сказал:

Для каждого региона есть свои тарифы. Так же есть дополнительное деление для тарифов с IPTV и промо тарифов. Все группы тарифов объединены в группы тарифов.

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

 

Многие провайдеры разделяют абонентов примерно таким образом:

 

1. Населенный пункт.

1.1. Тариф 100М.

1.2. Тариф 200М.

1.3. Тариф 300М.

2. Другой населенный пункт.

2.1. Тариф 100М.

2.2. Тариф 200М.

2.3. Тариф 300М.

 

И тут при смене тарифа 1.1. на тариф 1.3. нужно знать в каком населенном пункте абонент, с какого тарифа на какой переходит. Применительно к карбону у тарифа есть только одна привязка к группе. То есть нужна копия тарифов 1.1. и 2.1 - это один и тот же тариф, только дополнительная копия с другим идентификатором. И если населенных пунктов штук 50, то и копий тарифов должно быть 50, и это только один тариф по скорости. Если 3 тарифа в каждом, это уже 150 тарифов - какой-то абсурд.

 

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

[De1m0s]

@Saab95 
 

11 часов назад, Saab95 сказал:

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

И да и нет. Разделяем, но другим способом:
Тариф "1А", "А2".... "Аn" используем в городе А, все эти тарифы привязаны к линейке услуг А (линейки услуг можно создать в разделе Тарификация - Линейки услуг)
Такую схему применяем для N населенных пунктов с различными тарифными линейками.
Так же линейки услуг применяем для отделение бандлов с OTT и всевозможных Промо.
В общем древе абоненты рассортированы по папкам в соответствии с названиями тарифов. (создавать разные папки по населенным пунктам не видел смысла так как по названию тарифа нам понятно и так)
Преимущество Линейки тарифов в том, что она наследуется при переходе на тариф из другой линейки и абонент в ЛК видит только тарифы из своей линейки. Как по мне, так Вы можете реализовать задуманное: на каждый элемент структуры в Вашей иерархии - линейка тарифов.

 

12 часов назад, Saab95 сказал:

сами тарифы не придется множить.

 Да, это боль, у меня 100500 тарифов. Но я по крайней мере не создаю тариф через мастер создания и копирование тарифа поэтому у меня не множатся услуги для тарифов.

Положа руку на сердце, в тарифах не хватает возможности делать 2 названия - 1е служебное, которое видим мы, 2е - то, что видит абонент в ЛК (по аналогии с 1С - там есть печатная форма услуги и служебная для справочника)

И второго, чего не хватает в тарифах - возможность привязать 1 тариф к 2м линейкам услуг, чтобы реализовать принцип кругов Эйлера

[tkama]

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

А ну и да, повышение цен на 16%, интересно если я повышу абонентам абонентку на 16% сколько % абонентов я утрачу?)

Тут еще РТК со своей Гидрой лезет, вот прям раздумья берут...

[Кошачии ловец]

а гидра это ростелекомовский проект?

Edited November 19, 2025 by Кошачии ловец

[tkama]

РТК утверждает что да, вроде как купили контору делавшую биллинг.

[De1m0s]

В 19.11.2025 в 05:59, tkama сказал:

РТК утверждает что да, вроде как купили контору делавшую биллинг.

Если у Вас более 3000 абонентов, то Ваш КИИ считается ЗО КИИ, следовательно Вам нужна БД и ОС из Реестра. Гидра в документации заявляет, что БД должна быть Oracle еще и Энтерпрайз версия для достижения наилучшего эффекта (вангую, что все косяки нивелируются ответами ТП о том, что Вы не ту БД используете). Как Гидра будет вести себя на реестровой ОС и реестровой БД - вопрос открытый.

На какой-то из онлайн встреч представители Гидры дали понять, что БД и ОС это наши трудности. Поэтому менять карбон у которого БД+ОС+Биллинг все в одном дистрибутиве, который еще и в реестре не целесообразно в современных законодательных реалиях.

[Timax]

В 23.10.2025 в 23:45, De1m0s сказал:

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

Насколько я понимаю, никакие скрипты управления не будут затронуты? то есть нам не нужно будет перенастраивать взаимодействие с NAS/BRAS? не сломается взаимодействие с банками? будет работать кастомная выгрузка данных в СОРМ?

Ну и если есть, хотелось бы услышать отзывы тех, кому БД обновили.

Нам пару дней назад обновили БД. Эффект положительный. Проблем с обновлением не было. Всё работает. Единственное, что в ручную запустили индексацию, так как некорректно работал поиск.

На днях будем тестировать массовую переавторизацию 4к+ пользователей.

Раньше биллинг умирал при одновременных 2к+ авторизаций по Radius.

[Saab95]

В 19.11.2025 в 04:20, tkama сказал:

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

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

[De1m0s]

В 21.11.2025 в 21:17, Timax сказал:

Нам пару дней назад обновили БД. Эффект положительный. Проблем с обновлением не было. Всё работает. Единственное, что в ручную запустили индексацию, так как некорректно работал поиск.

На днях будем тестировать массовую переавторизацию 4к+ пользователей.

Раньше биллинг умирал при одновременных 2к+ авторизаций по Radius.

А что у Вас в качестве BRAS? самописное/open source? или решение на подобии СКАТ?

[Timax]

18 часов назад, De1m0s сказал:

А что у Вас в качестве BRAS? самописное/open source? или решение на подобии СКАТ?

Accel-ppp в роли IPOE браса и Mikrotik в роли PPPoE браса.

[De1m0s]

5 часов назад, Timax сказал:

Accel-ppp в роли IPOE браса и Mikrotik в роли PPPoE браса.

Спасибо. А подскажите еще, выгрузка в СОРМ у Вас самописная или готовая от Карбона? 

[Dude]

@product manager CB5 Как так-то?

 

Мдааа. В субботу пипец произошёл. Вроде DDOS-атака.
Биллинг упал, редуктор упал. В хелпдеске куча сообщений о критических ошибках создалось. Кое-как удалённый доступ сделали, сотрудник Карбона немного поправил, чтобы всё заработало, отрубил доступ со всех адресов, кроме необходимых. До понедельника оно как-то проработало. Доступ был.

С утра в понедельник. По автоматически созданным заявкам начали отвечать. И, как всегда, ссылками на статьи в документации. Ненужные совсем сейчас.

К 10 утра опять всё упало, доступ к серверу пропал.

[TheUser]

1 час назад, Dude сказал:

отрубил доступ со всех адресов, кроме необходимых

А что, до этого был открыт отовсюду?

[Dude]

4 часа назад, TheUser сказал:

А что, до этого был открыт отовсюду?

Угу. 

[product manager CB5]

@Dude Добрый день. 

С Вами связывался инженер Редуктора, так как по Редуктору сработал мониторинг, переполнились лог из-за атаки. Соответственно, на Редукторе доступ был закрыт инженером.
Через 2.5 часа Вы связывались с дежурным по Биллингу, он попытался подключиться, но консоль была недоступна. Дежурный после этого до Вас не смог дозвониться. 

С нашей стороны также была ошибка - не присвоили сразу критический статус Вашему обращению, поэтому система дежурного не оповестила, когда Вы восстановили доступ и сообщили об этом. 
По этому поводу с дежурным провели дополнительный инструктаж.

 

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

Для обращений по критичным проблемам в нерабочее время специально существует номер, указанный у Вас в Helpdesk.

 

В рабочее время обращение обработали в приоритете и очистили логи веб-сервера, переполнившиеся из-за атаки.

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