«Если у вас не работает биллинг, у вас не будет связи»
– убежден Константин Юнов, директор по информационным технологиям ОАО «МегаФон», считая конвергентный биллинг разумной потребностью вертикального холдинга.
– Было бы странно затратить $745 млн на покупку фиксированного оператора и не приобрести универсальный инструмент для работы с клиентами. Когда принимаются бизнес-решения такого масштаба, смешно экономить на биллинге, с новыми активами надо работать.
– Константин Владленович, какие пути ведут оператора к конвергентному биллингу?
– Давно осталось в прошлом представление о конвергентном биллинге как о способе «обсчета» различных схем тарификации (скажем, prepaid или postpaid) и выставления единого счета. Речь идет о единой концептуальной и технологической платформе для мобильных и фиксированных сегментов сети, услуг и абонентов.
Я бы выделил три модели перехода на конвергентный биллинг. Первая – самая распространенная, но не самая верная, – заключается в попытке объединить уже действующие отдельные решения. Этот путь чреват большими отложенными эксплуатационными затратами, недостаточной функциональностью, невысокой гибкостью. В результате появляются две базы клиентов, что осложняет аналитику, целевые маркетинговые акции, сокращает возможности готовить общие предложения для разных групп клиентов и т.д. Не имея общей базы абонентов, не зная их предпочтений, невозможно делать правильные предложения на конкретном рынке. Знание клиента – конкурентное преимущество будущего. Слать бабушке, у которой в телефоне не подключен SMS-профиль, SMS-предложение посидеть в чате – как-то неправильно.
Модель номер два, если коротко, заключается в полной замене старой системы биллинга на конвергентную. Ее опасность – снижение качества обслуживания клиентов в процессе перехода на новую платформу. Иными словами, можно потерять абонентов: если у вас не работает биллинг, у вас не будет связи, базовые станции завязаны на биллинговую систему, это единый комплекс. Для биллинга даже переход на зимнее время – очень сложное техническое мероприятие, в котором занято много специалистов: мы не можем потерять секунды, потому что это большие деньги, например, скидки «привязаны» к суткам, и т.д. и т.п.
Модель номер три успешно испробовал на себе «МегаФон». Еще в 2005 г . с компанией «Петер-Сервис» мы заложили основу системы биллинга из нескольких сегментов (в том числе фиксированного), которую вместе с коллегами из «Синтерры» доработаем до полнофункциональной схемы, полностью закрывающей весь цикл предоставления услуг любым клиентам (включая, естественно, технический учет). Мы получим полный биллинг с различными схемами тарификации для «МегаФона» в любом понимании термина конвергентности к концу 2011 г . Перед «Петер-Сервис» задача уже поставлена.
– Как эта модель реализуется на практике?
– На практике редко бывает такая счастливая история, чтобы биллинговую систему можно было доработать до полной конвергенции. Мы изначально приняли решение, которое спустя годы позволило нам идти по пути универсализации биллинга. К слову, у нас у единственной из компаний «большой тройки» биллинг построен на российском решении и российскими специалистами, и, по моему убеждению, он лучший с точки зрения функционала. Я уверен: мы никогда не получим высокоэффективную экономику без того, чтобы развивать этот интеллектуальный сектор программного обеспечения и этот высокомаржинальный бизнес.
У нас восемь полноценных унифицированных региональных комплектов биллинга, естественно, применяется релизная схема. Наша цель сейчас – перейти к оптимальному количеству комплектов (на сегодняшний день пять), не потеряв региональные компетенции. Здесь очень тонкая грань. По заданию «из центра» с учетом местных инициатив работают Кавказ, Поволжье, Урал, Северо-Запад и другие филиалы, представляют свои наработки, которые потом тестируются, испытываются в столичном центре компетенции.
– Каковы затраты на эту работу?
– Затраты несопоставимы с тем экономическим эффектом, который получит компания в случае универсальности предоставления услуг – решение окупится за минуты!
– Какие факторы, обстоятельства сдерживают переход операторов на конвергентный биллинг?
– Скорее всего, отсутствие компетенций и риски, с которыми сопряжены любые «переделки». Однако позиция «от добра добра не ищут» – откровенно проигрышная. Я люблю известные слова из «Алисы в стране чудес»: «Чтобы оставаться на месте, приходится бежать со всех ног. А чтобы попасть в другое место, надо бежать по крайней мере в два раза быстрее». У нас просто нет вариантов!
Технологии – обслуживающая функция бизнеса. Цель ИТ – дать бизнесу инструмент, причем инструмент универсальный. Конечно, можно сказать бизнесу: мол, вот здесь возьмешь молоток, а там – отвертку, но тогда обе руки будут заняты. А мы должны предоставить бизнесу такой инструмент, чтобы у него хотя бы одна рука была свободна, а значит, было больше шансов победить в конкурентной борьбе.
Прямой биллинг недоступен при покупке в Play Market
Хотел оплатить покупку приложения через оператора связи МТС, но такового способа оплаты нет. Только чрез карту ( а через карту я не оплачиваю в интернете) и через систему Pay Pal. Хотя Google предоставляет возможность покупки через оператора. Что делать?
Голосование за лучший ответ
Вроде биллинг работает только у Билайн и Мегафон. Что делать, ищите другой способ оплаты, или берите приложение из другого места)
UYagudinПрофи (546) 7 лет назад
Хорошо. Спасибо.
Елена ДупикГуру (4620) 7 лет назад
Можно вот так с мтс платить https://pay.mts.ru/webportal/virtual-card
Емеля Искусственный Интеллект (350275) Я пробовал, не помню почему но у меня не пошло. Я просто поставил Aptoide и подключив там сторонние магазины беру программы оттуда бесплатно. Но там конечно не все есть http://m.aptoide.com/installer?lang=ru
Биллинг МТС Google Play имеется! В регионах как Россия! Если всё же его нету то позвоните вашому оператору и попросите подключить биллинг! За это может оператор попросить у вас около 2.00 — 10.00р. бел.
Биллинг медленно работает
Такая запись в логе говорит о том, что система приостанавливает процессор из-за перегрева. Проверьте температуру процессора с помощью утилиты sensors (устанавливается с помощью команды yum install lm_sensors)
Другие проблемы аппаратного обеспечения
Пример записи в логе /var/log/messages корневой системы
* [Hardware Error]: Machine check events logged
Запись говорит об аппаратной проблеме, выявленной при самодиагностике ОС. Например, это исправленная ошибка в памяти с исправлением ошибок (ECC). В большинстве случаев не является причиной замедления работы, однако в случае повторения чаще чем раз в пару месяцев необходима расширенная диагностика памяти.
Проблемы дисковой подсистемы
Если в top/atop длительно присутствуют процессы в состоянии D (непрерываемый сон), то в большинстве случаев это следствие недостатка производительности дисковой подсистемы.
Запускаем в момент проблемы:
iostat -dmx 2
iostat -dmx 2 /dev/sda /dev/sdb
где 2 — интервал повторения в сек, /dev/sdX — интересующие нас диски (без них покажет все)
Нужно обратить внимание на соотношение столбцов rMB/s и/или wMB/s с %util. Если %util больше 90 при скорости менее 10 мегабайт/сек (в любую сторону), то налицо деградация скорости жесткого диска.
Скорость может деградировать по разным причинам:
- отказ диска в массиве: если это аппаратный RAID, то необходимо уточнить в /var/log/dmesg тип контроллера и установить соответствующее ПО для взаимодействия с ним, запросить через него состояние дисков;
- несоответствие типа массива задаче: например, под систему оптимальнее использовать RAID10, нежели RAID6, т.к. у последнего медленная скорость записи;
- диск медленный сам по себе, например энергосберегающие модели со скоростью 5400 RPM, скорость должна быть 7200 RPM.
Биллинг перегружен обработкой трафика (слишком часто отправляется аккаунтинг)
Диагностика
Создание абонента или проведение денежных средств занимает достаточно много времени — более минуты. В процессе диагностики проблемы следует изучить лог обработчика абонентов. Если в нем видно, что много времени уходит на обработку account_traf и количество постоянно большое (около 1000 или больше), можно попробовать изменить частоту отправки Accountg-Update чтобы снизить нагрузку на обработчик данных по трафику.
Посмотреть количество и скорость обработки объёмов трафика:
[root@billing ~]# egrep 'finished:daemons.account_traf' /app/asr_billing/var/log/worker.log | tail -n 3 2018-10-09 09:20:05,989 - worker - worker - INFO - Fork has finished:daemons.account_traf.0, Processed 945 in 89.275s. 2018-10-09 09:21:36,117 - worker - worker - INFO - Fork has finished:daemons.account_traf.0, Processed 969 in 89.218s. 2018-10-09 09:23:06,914 - worker - worker - INFO - Fork has finished:daemons.account_traf.0, Processed 978 in 90.484s.
Посмотреть сколько еще записей не обработаны:
[root@billing ~]# sqlexec /var/db/buff_traf.gdb "select count(*) from traffic where status=0 or status is null" COUNT ============ 4528613
Решение
- Нужно снизить частоту отправки Acocunting-Update (в примере — два часа или более) на биллинг и убедиться что данные по трафику не дублируются, отправляясь одновременно в Netflow и Radius-Accounting.
- Увеличить таймаут Radius-сессий на биллинге, по истечении которого, если не поступал аккаунтинг, сессия считается оборвавшейся. Значение должно более чем в два раза превышать Acct-Interim-Interval.
- Сбросить все сессии на всех NAS (вероятно можно перезагрузить роутеры) чтобы они установились заново
- Либо дождаться пока обработается уже собранная информация по объемам трафика, либо взять БД трафика из скелета без этой информации (однако в таком случае не обработанная информация по объёмам трафика будет утеряна). Как взять базу из скелета описано в статье «Восстановление БД биллинга из резервной копии»
Ниже приведен скрипт, который выполнит первые два пункта
#!/bin/bash #Значение Acct-Interim-Interval attr_value=8600 #Время жизни сессии для биллинга, равное удвоенному Acct-Interim-Interval плюс 15 минут const_value=$((900 + $attr_value * 2)) #Устанавливается таймаут accounting update curl "http://169.254.80.82:8082/rest_api/v2/VpnConst/" -d 'method1=objects.get&arg1="const_id":43>&method2=objects.set&arg2="const_value":"'$const_value'">&method3=save&arg3=<>' #Получает список NAS с ID RADIUS-атрибутов Acct-Interim-Interval если они есть, sed для фильтрации пустых строк вывода sqlexec sqlexec "set heading off; select n.id, coalesce(nrp.id,'none') from nas n left join Nas_Radius_Params nrp on n.id=nrp.nas_id and lower(attribute)='acct-interim-interval' where n.id>=1000 and n.id in (select distinct nas_id from users where auth_type in (0,6) and nas_id>=1000)" | sed '/^$/d' |\ while read nas param; do echo 'nas='$nas 'param='$param #Отключение опции "Использовать radius вместо NetFlow" в настройках NAS curl "http://169.254.80.82:8082/rest_api/v2/Nas/" -d 'method1=objects.get&arg1="id":'$nas'>&method2=objects.set&arg2="radius_ins_netflow":0>&method3=save&arg3=<>' #Если нет атрибута Acct-Interim-Interval, то он создаётся, если есть - устанавливается значение "частота 8600, при любом статусе баланса и блокировки" if [[ $param == 'none' ]]; then curl "http://169.254.80.82:8082/rest_api/v2/NasRadiusParams/" -d 'method1=objects.create&arg1="attribute":"Acct-Interim-Interval","thevalue":"'$attr_value'","balance_status_id":0,"block_status_id":0,"op":": code-quote">"nas_id":"'$nas'","is_hotspot_attrib":0>' else curl "http://169.254.80.82:8082/rest_api/v2/NasRadiusParams/" -d 'method1=objects.get&arg1="id":'$param'>&method2=set&arg2="thevalue":"'$attr_value'","balance_status_id":0,"block_status_id":0>&method3=save&arg3=<>' fi done
Атрибуты добавятся только на те NAS к которым привязаны учетные записи с типом авторизации «по vpn pppoe/pptp» и «любая через RADIUS», чтобы добавить на всех маршрутизаторах, уберите условие «and n.id in (select distinct nas_id from users where auth_type in (0,6) and nas_id>=1000)«
Биллинг перегружен обработкой трафика (слишком много «первых пакетов»)
Если замедление так же связано с обработкой трафика, включите уровень логирования INFO, если в логе nf_collector много записей first_packet=0 и они часто повторяются по одним и тем же адресам, значит проблема в этом.
Абоненты долго обрабатываются
Ситуация
Вы создали нового абонента, Вас перевело в его карточку и над номером договора долго не пропадает сообщение что абонент в обработке:
Это говорит о том, что итерация Воркера длится слишком долго и он не справляется с работой. В первую очередь нужно убедиться, что скорость работы дисков достаточная (в первую очередь диск на котором находится БД), как это диагностировать подробно описано в статье «Проблемы с оборудованием», явным признаком проблемы скорости работы является долгое выполнение запросов, при том что тот или иной воркер не произвел ни какой работы:
2018-12-28 13:50:27,259 - worker - worker - INFO - Fork has finished:daemons.nas_stats.0, Processed 0 in 500.677s.
В приведенном примере воркер обновляющий статистику NAS (количество подключенных абонентов и т.д. на соответствующей вкладке настроек оборудования) не выполнил каких-либо операций, но работал в течение 500 секунд, что говорит о том что запросы к БД медленно выполняются.
Решение
Подключите для БД отдельный диск с высокой скоростью доступа.
Всё очень медленно работает, не проходят платежи, не управляется оборудование, не работают авторизации
Причина
Проверьте, что БД не слишком большого размера — если она превышает 10Гб, это уже достаточно много, система мониторинга создаст автоматическую заявку по этой проблеме ALARM Превышен лимит размера БД
В среднем, 10Гб достаточно чтобы хранить данные нескольких десятков тысяч абонентов без дополнительных оптимизаций или активной работы механизма партиционирования.
Если абонентов у Вам меньше 50 000, при этом база вышла за рамки 10Гб, нужно изучить, на что ушло место, очистить лишние данные и уменьшить размер БД. Ниже описано, как это сделать.
Решение
- Определите, какие таблицы БД занимают больше всего места:
chroot /app/asr_billing/ gstat-fb /var/db/billing.gdb -data | \ grep -E '^[A-Z]|Data pages:' | sed ':a;N;$!ba;s/\n */ /g; s/,//g' | \ awk '"data pages;",$1,$2";",$9,"data page slots;",$12,"average fill">' | \ sort -h | tail -n 3
39178 data pages; ARCH_ACCOUNT_STACK (146); 39178 data page slots; 87% average fill 75789 data pages; RADIUS_SESSIONS (254); 75789 data page slots; 86% average fill 949991 data pages; EVENTS_STACK (193); 949991 data page slots; 94% average fill
EVENTS_STACK
В общих чертах описание возможных проблем переполнения стека команд для оборудования можно найти в статье по системе мониторинга.
Описание подсистемы отправки команд и пути отладки описаны в статье https://docs.carbonsoft.ru/display/CarbonBilling/nas_event_daemon
Проблема чаще всего возникает, если используется авторизация по RADIUS.
Наиболее частые причины:
- Медленный диск, в результате чего при перезагрузке оборудования происходит массовая авторизация абонентов, но события не отправляются достаточно быстро, поэтому абоненты продолжают авторизоваться и стек продолжает пополняться
- Проблемы оборудования: возможно, что-то не так с NAS-сервером, в результате чего постоянно отпадают RADIUS-сессии и абоненты переавторизуются, стек копится, например NAS-сервер слишком медленно отвечает биллингу
- Ошибки в скрипте управления NAS: команды отправляются с ошибкой, а в скрипте событий описана обработка этих ошибок, но не слишком оптимально, это так же может замедлять отправку событий и приводить к «снежному кому» в стеке
Возможно Ваша причина тут не описана — здесь помогут хорошее понимание схемы взаимодействия биллинга с оборудованием, анализ логов и знание особенностей используемого оборудования.
ARCH_ACCOUNT_STACK
В таблице хранятся проводки, влияющие на баланс абонента. «Проводки» в терминах бухгалтерии.
Возможные причины и решения:
- У Вас включена опция сохранять движения всего трафика в настройках оператора связи, чтобы предоставлять подневную (или почасовую) детализацию объёмов трафика абонентам.
Решить можно следующими способами:- Уменьшите частоту отправки данных по трафику. В статье о службах сбора статистики Вы найдёте информацию по настраиваемым параметрам частоты отправки — уменьшите частоту в 5-10 раз.
- Настройте период хранения исторических данных в базе. Так детализация расхода станет доступна за менее длительный период, но база будет работать быстрее
- Возможно, это проводки за списания и тогда через конструктор отчётов постарайтесь понять структуру расхода: у каких абонентов больше всего проводок, по каким операциям и тд. Возможно, где-то в настройках услуг или ведении абонентов допущена ошибка.
RADIUS_SESSIONS
В таблице хранится история RADIUS-авторизаций. Если таблица слишком разрослась, настройте период хранения исторических данных в базе — уменьшите его. Если это не помогло — возможно, проблема так же где-то в авторизациях или оборудованиии и, вероятно, помимо таблицы с историей авторизаций, у Вас так же разрастётся EVENTS_STACK.
Медленно работает веб-интерфейс администратора
В биллинг добавлен инструмент, способный отследить долго выполняющиеся запросы к веб-серверу, а также косвенно судить о их наличии в прошлом. Это утилита диагностики uwsgitop.
Использование утилиты:
chroot /app/asr_billing uwsgitop /tmp/uwsgi_stats.socket
Если в поле STATUS много строчек с busy — значит, администраторский интерфейс действительно загружен.
Если при этом поле AVG показывает более 2-х секунд, то нужно отследить, что именно тормозит — время работы есть в логе web-сервера:
tail -f /var/log/admin_web_server.log | perl -ne 'print "$1\t$_" if (m/generated \d+ bytes in (\d+) msecs/ and $1>500)'
Чаще всего там будут неоптимизированные отчеты
Если нет явных причин медленной работы, то это повод проверить системные требования.
Очень долго загружается веб-интерфейс администратора, много запросов на служебные порты биллинга
Возможно биллинг перегружен сетевыми запросами. Посмотрите сообщения ядра ОС командой dmesg, возможно там есть сообщения о сетевом флуде:
[root@mynetcity_ru ~]# dmesg | grep 'flooding' possible SYN flooding on port 440. Sending cookies. possible SYN flooding on port 440. Sending cookies. possible SYN flooding on port 440. Sending cookies.
Подробная статья по проблеме есть в документации Red Hat: изнеё можно узнать, что это за ошибка и чем она может быть вызвана.
Основная задача разобраться в источнике трафика.
Если в Вашей сети нормально, что таких абонентов может быть много, оптимальным решением будет отключить редирект на оборудовании, чтобы не перегражать биллинг.
В общем случае, это нетипично, и необходимо провести диагностику интеграции биллинга и оборудования. Для этого нужно понимать как работают, схемы интеграции в целом, служба отправки команд на оборудование и если используется RADIUS, то как как устроена авторизация по RADIUS через биллинг и как её диагностировать.
Решение
- В первую очередь, отключите редиректы, которые вызывают проблему (это могут быть и другие порты, например 445 (авторизация HotSpot) или 442 (отрицательный баланс))
- Когда проблема с доступом будет решена, проанализируйте логи одного или нескольких абонентов, чтобы понять что произошло и почему абонентов не оказалось в списке авторизованных или заблокированных.
Проблемы биллинга: Что может пойти не так с самописным софтом
Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Напишем сами, будет лучше (на самом деле нет)
Главный аргумент сторонников самописных решений заключается в возможности полной адаптации к требованиям бизнеса. «Мы лучше знаем, что нужно компании» — типичный ход мыслей.
На коротком временном промежутке такой ход действительно может оправдать себя, однако затем начинаются проблемы.
Очень сложно вносить изменения
При очередной смене широко применяемых технологий (например, переход с PPP на IPoE, внедрение BRAS) или появлении новых услуг, самописный биллинг, как правило, оказывается не готов к таким изменениям. Решение, которое разрабатывалось для работы в формате «здесь и сейчас», крайне сложно изменить. Все это приводит к снижению качества обслуживания абонентов и отставанию от конкурентов.
Технологический клубок
Программные решения собственной разработки часто бывают монолитными — это значит, что помимо собственно биллинга, в них может присутствовать и функциональность CRM, хелдпеск, система активации новых абонентов и даже инструмент для планирования монтажных работ.
Софт устаревает и его так или иначе приходится заменять. Распутать же клубок из переплетенных между собой разных систем сложно. Заменять приходится либо все сразу и во всех основных подразделениях компании, что крайне болезненно, либо выводить из эксплуатации старое решение постепенно. Этот путь сопряжен с огромными затратами времени, сил и средств, да и не всегда возможен в принципе — например, если в заменяемой системе нет модульности или отсутствует API.
Костыли вечны
Часто выбор в пользу самописного софта делают компании, обладающие «нестандартными» бизнес-процессами. Проблема в том, что экзотика в итоге приводит к созданию костылей, которые остаются в системе на годы и затрудняют работу пользователей.
Разработчики же серийных продуктов не могут себе позволить никакой экзотики, поскольку их решениями пользуются многие компании. Это значит, что они более предсказуемы и понятны для пользователей.
Что делать, если переезд назрел
Собственные разработчики — это дорого, а их наличие не гарантирует успеха (что иллюстрируют описанные выше проблемы). Поэтому все больше компаний задумываются о переходе на серийный биллинг.
Этот процесс можно сделать менее болезненным, если следовать нескольким простым рекомендациям:
- Прежде всего, не нужно тянуть с переходом. Чем дальше откладывается это решение, тем больше накопится труднорешаемых проблем.
- При выборе серийного решения нужно смотреть не только на его текущую функциональность, но и узнать у создателей планы по развитию (правильные разработчики никогда не станут утаивать их).
- Лучше мигрировать постепенно — это сложнее и дороже, однако позволит избежать сбоев и негатива, а репутация компании важнее денег.
- Нельзя экономить на тестировании — следует уделить внимание воссозданию «боевых» условий на тестовых стендах. Например, крупных клиентов мы просим переключать нагрузку с реальной сети на тестовую инсталляцию биллинга на короткое время ночью.
- Переехать самим невероятно сложно. Миграция на новый биллинг — трудоемкий проект, на выполнение которого мало у какой компании есть свободные человеческие ресурсы. Сотрудники заняты текущими задачами, поэтому лучше привлечь подрядчиков, которые уже провели много подобных внедрений.
Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!