BiTel

Сегодня обнаружили сервис на договоре в состоянии "Отключен" (как при финансовой блокировке), но денег на договоре при этом было достаточно и статус договора был активен. Установили статус "Активен" ещё раз и сервис перешёл в нормальное состояние, после чего интернет у абонента заработал. Теперь интересно, почему это произошло и как этого избежать в будущем.

Попробую описать предысторию.

26 февраля абонент попросил активировать отложенный платёж (сейчас у нас некоторые платежи зачисляются долго и мы активируем отложенный платёж на необходимую сумму) и ему уменьшили лимит на пять дней.
26 февраля следом абоненту выставили новый тарифный план с 1-го февраля и сразу был выполнен автоматический перерасчёт наработки. При этом баланс абонента ушёл в минус, но остался по-прежнему большим лимита и абонент продолжил работать.
27 февраля уже реально пришёл платёж на сумму ранее взятого отложенного платежа, но отложенный платёж остался активированным (т. е. лимит остался по-прежнему отрицательным).
28 февраля ещё раз проводились изменения в тарифных планах и был выполнен автоматический перерасчёт.
03 марта запустилась задача восстановления лимитов и интернет у абонента сразу отвалился, т. е. сервис перешёл в статус "Отключен", но договор остался активным и с положительным балансом. В дальнейшем абонент несколько раз переподключался, ему выдавались нормальные атрибуты сессии, но через минуту нормальные атрибуты на сессии менялись на REDIRECT. Потом абонент позвонил нам.

Замечания:
1. Установленный с 1-го февраля тарифный план в марте имеет нулевую стоимость (вся наработка по тарифу списывается в первом месяце - в феврале), соответственно за март наработки нет и баланс на договоре отображается за февраль.
2. В базе состояние сервиса, по всей видимости, соответствует ожидаемому и не соответствует реальному (в памяти сервера) для подобных договоров.
3. Подобные договоры появляются иногда в начале месяца, но не массово.

Теперь вопросы:
1. Почему это произошло?
2. Как исключить подобные вещи в будущем?
3. Как найти других абонентов с похожей проблемой, но которые ещё не заметили её (например, они ушли на работу и не пользовались интернетом).

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

А у этого сервиса в мониторе сессий какая ошибка при этом выводится?

При схемах с авторизацией (RADIUS/DHCP) или при активной схеме постоянно происходит проверка авторизации.
Т.е. похоже, что в памяти приложений один из параметров, требуемый для авторизации не обновлялся.
Это может происходить, если происзводится добавление платежа в БД без отправки сообщений (событий), такой же правки лимита, статуса договора.
Ошибка в мониторе сессий или в поле Состояние сервиса договора может подсказать.

У этого абонента не успели посмотреть ошибку в мониторе, т. к. надо было срочно его включать. На будущее помечу, что нужно обращать внимание на ошибку в мониторе.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

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

А есть ли способ сверить состояние сервиса в памяти и в "базе"?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

это не субдоговор ?

Нет.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91