Start a new topic

Отзывы о 4.0

 Коллеги, здравствуйте! Кто уже на 4.0 сидит - как впечатления?


Просто нам надо бы обновиться, однако был печальный опыт переползания на 3.4.5 в числе первых - долго потом глюки отлавливали :)


А что там нового и интересного?

Для нас - несколько фиксов и изменение логики работы хардов

 

Малоинформативно, но  рекомендую на тестовой базе развернуть. Раз 5 при обновлениях наталкивался на отличия в API, приходилось фиксить на ходу. Если API не используете, то думаю, не так страшен черт. 

АПИ ещё как используем, и с тестовой базой - это естественно. Я не об изменениях в api спрашиваю, а о возможных багах, на которые наткнуться есть неиллюзорная вероятность ;(

 

В интересах всего сообщества нужно рискнуть)))

Я уже с 3.4.5 рисковал, теперь чья-нибуть другая очередь %)

 

В общих чертах об основном нововведении четвёртой версии — модуле Provisioning управления сетевым оборудованием написано в нашем блоге: http://blog.hydra-billing.ru/stories/332


Также в этой версии, например, реализована возможность использования автоплатежей: http://blog.hydra-billing.ru/stories/535


На текущий момент четвёртая версия используется в режиме промышленной эксплуатации 7 нашими клиентами, причём некоторыми из них уже около полугода. Разумеется сначала мы эту версию устанавливаем на тестовую базу и только после того, как все основные бизнес-процессы, скрипты и т.п. будут проверены, планируем обновление основного экземпляра Гидры.


Что касается агента HARD, то его старую версию мы по-прежнему поддерживаем для того чтобы переход на 4 версию Гидры был постепенным: сначала обновляется ядро и приложения, потом настраивается и тестируется авторизация и события на 4 версии агента HARD и модуле Provisioning, и только потом планируется обновление боевых экземпляров HARD и переключение на новые события.

Расскажу свой личный опыт перехода на 4 версию, как есть.

Обновились исключительно по той причине, что нам был необходим кластерный Radius, в первую очередь для надежности, так как у нас все авторизации идут через Radius и в случае выхода его из строя, все абоненты окажутся без услуг. Для поддержки данного режима необходим Hard 4, который не работает с 3 веткой, ему необходима 4.

Обновление проводилось на этапе сильно затянувшегося внедрения (система не использовалась) и заняло все это 5 месяцев. Как это проводить на боевой системе мне трудно представить, так как ошибки следовали одна за одной, одно обновление, второе, третье… одно правило одни ошибки, но добавляло другие… 4.0.0.87 -> 4.0.0.89 -> 4.0.0.103 -> 4.0.0.105

Попутно сломалась стыковка с UserSide, костылями и своими запросами все это временно починили. Если кому необходимо, обращайтесь расскажу как подправить скрипт us_hydra для работы с 4 веткой.


В целом критических багов в системе мало но мелких и средних огромное количество.

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

Привыкайте видеть для таких заявок вот такую шапку :)


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

Вы: У меня педаль отвались!

Продавец: А вторая на месте?

Вы: Да...

Продавец: Ну так вот и крутите пока одно ногой!

Вы: Так не удобно же! Как это одной ногой то?!

Продавец: Мы занимаемся тем чтобы у Вас колеса не отвалились а не тем чтобы Вам было удобно!


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


ТП: У нас в версии 4.0 реализована новая система событий, которая работает совсем по другому. Однако новые события пока умеют работать только с оборудованием, поэтому события по субъектам реализованы через старую систему событий.

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

Я: В какие сроки может появиться события по субъектам учета в новой системы событий хотяб ориентировочно 1-5-10 лет?

ТП: Андрей, к сожалению официальной информации пока нет, но не думаю что это затянется на долгие годы.


Так что если Вы хотите стать на долгие годы бета-тестером, и спонсором разработки – милости просим в наши ряды :) Если же Вы можете обходиться без авто-платежей, Hard 4 и других новшеств – переходить точно нет смысла, Вы ничего не выиграете.


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


6 people like this

Понятно, большое спасибо :) Будем думать

Полезная информация

 После прочтения комментария Андрея Полкачева о переходе на 4-ую версию АСР «Гидра», испытала чувство приятного удивления, ведь относиться с юмором к сложным жизненным ситуациям может далеко не каждый!

Действительно, в первое время после выпуска новой версии в ней чаще обнаруживаются баги. Это естественный процесс для сложного продукта. Ведь мы не просто меняем циферку версии и добавляем несколько фич, мы еще и реструктурируем старый код, работаем над безопасностью и производительностью. Конечно, мы не стремимся переложить тестирование на плечи заказчика. Ввиду сильно различающихся клиентских конфигураций, сложно проверить все автоматизированными тестами. Но мы стараемся это делать, поверьте :) Мы очень благодарны вам - нашим клиентам за понимание и терпение.

К слову, проблема с добавлением IP-адреса абоненту была устранена более 2-х месяцев назад, как и ряд других разных дефектов и мелких недоработок.

Сейчас мы устанавливаем четвертую версию всем новым клиентам и смело рекомендуем ее для обновления .

Будьте внимательны! Для успешного перехода на 4-ю версию необходимо начинать работы с тестовой базы и не надеяться на «авось».

Хочу отметить, что последние несколько переходов с третьей на четвертую версию у наших клиентов прошли быстро и безболезненно и сейчас они в полной мере пользуются всеми приобретенными новшествами. Мы растем и развиваемся вместе с вами и хотим и дальше, плодотворно сотрудничая, улучшать и совершенствовать нашу АСР «Гидра»!

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


Да, "первое время после выпуска" возможны мелкие ошибки и дефекты, но в таких крупных проектах как АСР их большая часть должна исправляться в alpha/beta/rc версиях при проведении тестирования,  но никак не полтора года спустя официального громкого релиза. Да и ошибка в списании денег за дополнительные услуги (трубокнопку и т.п.), не думаю что является таким уже мелким багом.


Также наверное не одному мне будет интересно услышать, когда все-таки в решении заработают «фичи» заявленные еще полтора года тому назад, а именно:

Обещанная плавная миграция на новую систему событий, а не прикрученная сбоку бантиком новая система только для оборудования. Хотя, она может настолько «плавная» что я не доживу до ее окончания… 

Автоплатежи, о которых так все было красиво расписано в блоге… но ТП вас быстро опускает на землю: На данный момент функция автоплатежей реализована только для Uniteller и не работает из за багов багов багов… 

Простая логика добавление доп. услуг (турбокнопка и т.п.) чуть ли не в один клик. На сегодняшний день деньги вы за эти услуги брать не сможете они просто не списываются. Гидра не умеет считать доп. услуги (реальный IP адрес, турбокнопка и т.п.), деньги не списываются. Для решения, главной задаче которого является подсчет деньги это ошибка номер один, но это не мешает этому багу висеть в ТП уже второй месяц… то есть гидра мешает мне заработать на своих абонентах деньги…


2 people like this

Знакомо.

Тоже самое, что и с модулем выгрузки в 1С. Не передается ПРФ (ООО, ЗАО....) в выгрузку для 1С.

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

Ага, пользуются....

 так, заявка - к разработчикам может висеть больше года...

Документацию не обновляли очень давно.



кстати, за ТП платим регулярно.


2 people like this

Добрый день, Андрей.


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


Система событий, которая «прикручена сбоку», касается только оборудования по одной простой причине: команды для управления оборудрованием и команды по субъектам носят принципиально разный характер, к ним предъявляются совершенно различные требования. Генерация команд для управления оборудованием это по многим причинам технически сложная задача. Подсистема управления оборудованиям должна генерировать по меньшей мере сотни тысяч команд в определенный момент времени, при этом очень важно, чтобы ее работа была прозрачна, иначе неизбежны ошибки синхронизации реального состояния оборудования и состояния по представлениям Гидры. То, что они раньше обрабатывались одной системой, было ошибкой. При этом это было не единственной ее проблемой, например, производительность генерации событий зачастую была неудовлетворительной, это не позволило бы использывать Гидру на инсталляциях, где абонентская база больше на один или два порядка, чем у упомянутых АйдоТелеком и Etherway. Генерация событий по абонентам существенно более простая задача, даже текущая система с ней справляется удовлетворительно, поэтому ее мы еще не заменили. Но вы должны понимать, что когда это произойдет, это все равно будет отдельный модуль, он будет по-другому настраиваться, работать по другим правилам. Излишние обобщения ведут к тяжелым последствиям — этот урок для себя мы уже усвоили.


По автоплатежам я не очень в курсе процесса внедрения, но насколько я знаю ситуация там осложнилась затянувшимся тестированием на первом заказчике, а потом «неожиданным» ответом Юнителлера по паре вопросов технического плана, касающихся создания подписки на автоплатеж. Но вам нужно понять одну очень важную вещь про автоматические платежи. Самое плохое, что может случится с автоплатежом — ошибочное списание средств с карты абонента. При разработке этому было уделено очень много внимания. В итоге, при тестах автоплатежа может возникнуть впечатление, что что-то не работает, но чаще всего это связано с тем, что условия нормальной работы системы отличаются от условий, в которых проводится тестирование. Например, нельзя просто провести абоненту отрицательный платеж и ожидать, что ему сразу же придет смска со списанием с карты. Этого не произойдет. Думаю, вы понимаете, что это могло бы привести к нежелательным последствиям.

Login or Signup to post a comment