[jp1111]

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

Если пришёл Stop - сессия закрыта.

Если пришёл Update, а сессии нет - надо отвечать NAK.

 

ВСЁ. Точка.

 

Ничего подобного !!! Полностью не согласен, аргументов куча. Первый: А что если Вы агент рестартанули и пропустили старт который пришел за время пока агент лежал, а сессия при этом идет? И не надо возражать что так не бывает - бывает, причем часто. Второй: Вы грохнули базу с активными сессиями, логически их в биллинге нет, на BNG же их тысячи. Дропнуть всех принудительно и заставить переаутентифицироваться? Реакцию представляете (и юзера и оператора, если мы предложим им такой вариант развития событий)? Надо прозрачно для юзера, без дропа его сессии, поднять логически ее по данным апдейта. Сейчас коллег приведу - обсудим.

[Abram]

Ничего подобного !!! Полностью не согласен, аргументов куча. Первый: А что если Вы агент рестартанули и пропустили старт который пришел за время пока агент лежал, а сессия при этом идет?

Тогда сессия не должна подняться; NAS, который не получил ответа на Acct-Start, должен обрубить сессию.

Второй: Вы грохнули базу с активными сессиями, логически их в биллинге нет, на BNG же их тысячи.

Если уж хватило ума лезть руками в базу и что-то там грохать - то тут уже, простите, админ сам себе ***к.

Дропнуть всех принудительно и заставить переаутентифицироваться? Реакцию представляете (и юзера и оператора, если мы предложим им такой вариант развития событий)?

Вполне себе представляю и видел. Да, дропнуть всех. Опять-таки, тут админ сам себе ***к, если пришлось делать такое.

 

Знаете, почему ваш биллинг нахер никому не нужен? Потому что он делает то, что вы хочете, а не то, что хотят от него операторы.

[jp1111]

[

Если надо что-то еще, то ХД обычно просит. Но тут просто молчат.

Готов предоставить доступ по web в сам биллинг, ssh на сервер, telnet на NAS, но пока ничего этого не попросили.

 

Это то что надо, в понедельник передам предложение по адресу.

[jp1111]

Ничего подобного !!! Полностью не согласен, аргументов куча. Первый: А что если Вы агент рестартанули и пропустили старт который пришел за время пока агент лежал, а сессия при этом идет?

Тогда сессия не должна подняться; NAS, который не получил ответа на Acct-Start, должен обрубить сессию.

Второй: Вы грохнули базу с активными сессиями, логически их в биллинге нет, на BNG же их тысячи.

Если уж хватило ума лезть руками в базу и что-то там грохать - то тут уже, простите, админ сам себе ***к.

Дропнуть всех принудительно и заставить переаутентифицироваться? Реакцию представляете (и юзера и оператора, если мы предложим им такой вариант развития событий)?

Вполне себе представляю и видел. Да, дропнуть всех. Опять-таки, тут админ сам себе ***к, если пришлось делать такое.

 

Знаете, почему ваш биллинг нахер никому не нужен? Потому что он делает то, что вы хочете, а не то, что хотят от него операторы.

 

В общем ваша логика понятна, будучи разработчиком биллинга Вы вместо того, что бы в коде предусмотреть ряд нештатных ситуаций, Вы очевидно Вашим заказчикам объяснили бы, что их админы ***ки :) нет это, конечно, бывает и реально попадаются, но все же коллега, давайте найдем в себе смелость признаться что ***ков, все же, не так много, во вторых у Вас на то и интеллект, что бы защититься от этого ***ка и еще кучи ***ков которые работают в таких конторах как Cisco systems huawei Ericsson в чьих прошивках тоже бывают ошибки и чьи продукты видимо тоже нахер никому не нужны :) упаси Господь не сравниваю эти компании, но все же .... категорично Вы как-то право слово :)

 

Продукт любого разработчика делает то, что в него заложил разработчик, и наш не исключение. Логику Вашего алгоритма "все ***ки, на них и спишем отказ в обслуживании" не разделяю.

[Nallika]

Ничего подобного !!! Полностью не согласен, аргументов куча. Первый: А что если Вы агент рестартанули и пропустили старт который пришел за время пока агент лежал, а сессия при этом идет?

Тогда сессия не должна подняться; NAS, который не получил ответа на Acct-Start, должен обрубить сессию.

Второй: Вы грохнули базу с активными сессиями, логически их в биллинге нет, на BNG же их тысячи.

Если уж хватило ума лезть руками в базу и что-то там грохать - то тут уже, простите, админ сам себе ***к.

Дропнуть всех принудительно и заставить переаутентифицироваться? Реакцию представляете (и юзера и оператора, если мы предложим им такой вариант развития событий)?

Вполне себе представляю и видел. Да, дропнуть всех. Опять-таки, тут админ сам себе ***к, если пришлось делать такое.

 

 

А предположим, возникла ситуация, когда есть проблема по сети, и теряются апдейт пакеты. Радиус не получает несколько апдейтов по сессии и убивает ее, как зависшую. И в итоге получаем ситуацию, когда на BNG есть сессия, а на радиусе нет. Абонент кричит, ругается,пишет письма в россвязьнадзор. Бесспорно, это проблема сетевиков, а не биллинга. Но, как тут описывает представитель компании разработчика, у них есть решение, которое поможет решать проблему более оперативно(пока ТП дозвонится до инженеров, те проведут диагностику, выявят проблему и пр,пройдет несколько часов). То почему бы не воспользоваться вот этим решением в обход стандартам?

Ситуация, описанная в предыдущих постах, когда апдейт приходит после стопа,для меня не объяснима. Но если разработчик (думаю, что это достаточно бюджетное решение) берется исправить вот такие вот ошибки оборудования(а в этой ситуации это бесспорно они), то для таких компаний как например моя ( когда на последние средства было куплено оборудование Cisco в кредит и ни о какой поддержке и речи быть не может) это будет являться временным решением, а иначе мы просто потеряем всю абонентскую базу.

[Andrei]

[

Если надо что-то еще, то ХД обычно просит. Но тут просто молчат.

Готов предоставить доступ по web в сам биллинг, ssh на сервер, telnet на NAS, но пока ничего этого не попросили.

 

Это то что надо, в понедельник передам предложение по адресу.

Вчера перезапустил все: ядро и всех агентов. Все равно выдаются одинаковые ip клиентам, причем это видно и в мониторе активных сессий в биллинге, и на NAS-е. В ХД отдал очередные скриншоты, логи радиус-агента в режиме дебаг, дал данные на вход на сервера. Поддержка-то вроде и по субботам работает? А то абоненты рвут и мечут: погода плохая, так еще и в инет не сходить нормально. :(

[jp1111]

Это то что надо, в понедельник передам предложение по адресу.

 

Вчера перезапустил все: ядро и всех агентов. Все равно выдаются одинаковые ip клиентам, причем это видно и в мониторе активных сессий в биллинге, и на NAS-е. В ХД отдал очередные скриншоты, логи радиус-агента в режиме дебаг, дал данные на вход на сервера. Поддержка-то вроде и по субботам работает? А то абоненты рвут и мечут: погода плохая, так еще и в инет не сходить нормально. :(

Поддержка работает круглосуточно, но я честно признаюсь, что не каждый сотрудник поддержки может проанализировав Вашу ситуацию залезть в svn (права банально не у всех есть на доступ к коду) и посмотреть по коду в какой ситуации коллизия может возникнуть. Даже имея доступ к коду не каждый разработчик может разобраться в ситуации т.к. разработчики отвечают за собственныей сегмент кода и не стоить ждать от ответственного за API эффективности в радиусе. Но это все лирика, которая объясняет почему в этой проблеме не разбирается только саппорт, а разбирается саппорт + разработчик. Завтра я попросил выйти на работу разработчика по агенту и он свяжется с Вами, надеюсь Вы поспособствуете диагностике при необходимости.

 

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

[XeonVs]

Скажите пожалуйста с кем конкретно общались? Повод разобраться в консерватори...

Борис Осянин

Ага, разобраться еще раз стоит. Сделать дополнительные выводы о своей работе, если после летнего комстаровского сборища их(выводов) было не достаточно.

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

[vitalyb]

Касательно радиуса, на мой взгляд, со стороны сервера могут присутствовать любые костыли и workaround'ы для всевозможных ситуаций если соблюдаются несколько условий. Во-первых, особо нестандартные режимы, раз включены по умолчанию, должны иметь возможность отключаться - параметром в конфиге, ключем запуска, как угодно. Во-вторых неплохо было бы их хотя бы перечислить в документации, дабы админ имел возможность подобрать рабочий вариант в особо тяжелой ситуации. И явно не повредит, если выяснится, что в "strict" режиме или пакеты теряются, или не в том порядке приходят, или еще чего.

 

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

[XeonVs]

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

Категорически согласен. Документированность системы оставляет желать лучшего.

+ Как минимум должен быть еще более подробный публичный ченжлог на каждое обновление сборок. Иначе установка\обновление сборки превращается в русскую рулетку даже имея тестовые базы.

[jp1111]

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

Категорически согласен. Документированность системы оставляет желать лучшего.

+ Как минимум должен быть еще более подробный публичный ченжлог на каждое обновление сборок. Иначе установка\обновление сборки превращается в русскую рулетку даже имея тестовые базы.

Судя по контексту, рискну предположить что существующий changelog от сборки к сборке плох. Чем? Если дадите конкретику - улучшим. Знание того, как - ключевой момент. Текущий лежит в разделе загрузка личного кабинета клиента.

[XeonVs]

Судя по контексту, рискну предположить что существующий changelog от сборки к сборке плох. Чем? Если дадите конкретику - улучшим. Знание того, как - ключевой момент. Текущий лежит в разделе загрузка личного кабинета клиента.

Тем что он не информативен и не актуален.

Да что, то иногда меняется, но когда сборка пересобирается 7 раз за неделю.... В итоге и получается, что обновиться надо, а что получится не знает никто.

 

Раз держите разработку в svn то уже есть достаточно хороший ченжлог.

Изменено 15 октября, 2011 пользователем XeonVs

[jp1111]

Скажите пожалуйста с кем конкретно общались? Повод разобраться в консерватори...

Борис Осянин

Ага, разобраться еще раз стоит. Сделать дополнительные выводы о своей работе, если после летнего комстаровского сборища их(выводов) было не достаточно.

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

Вот смотрите: начинаю разбираться, получаю объяснение "1 раз помнится, на днях,  мне передали звонок человека  - потенциального клиента. На все его вопросы я ответил.

После чего мы распрощались. Далее если он и звонил то разговаривал уже не со мной точно.

Могу предположить что он не посчитал мои ответы качественными." - возникают вопросы:

 

Борис Вам не ответил или ответил не качественно ?

После этой консультации Вы обращались к нему по почте? Дошла ли она? К нему или еще кому то? В общем мне нужно прежде всего разобраться, поняв для себя где дефект и в чем он заключается что бы его исправить. Да, надо сделать скидку Борис работает у нас недавно, но отзыв его начальника позитивный, человек набирается опыта и станет эффективным. Исп. срок он тем самым прошел. Людей новых, действительно, прибавилось и не в последнюю очередь потому что выводы после конференции в "Волжских далях" в Саратове были сделаны.

Изменено 15 октября, 2011 пользователем jp1111

[vitalyb]

Не думаю, что ченжлог из svn будет полезен (толку от "бекпорт r12345" или "ditto"?). А так да, обязательное описание в случаях когда номер сборки не изменился, а дата изменилась явно не помешает. Даже если это всего одна строка - улучшена стабильность или совместимость при работе с/исправлена редкая ошибка с тем-то при определенных обстоятельствах/слинковали статически с другими версиями библиотек/просто всё пересобрали, дата красивая. Будет хоть понятно, стоит ли обновляться и чего следует ожидать.

[XeonVs]

Не думаю, что ченжлог из svn будет полезен (толку от "бекпорт r12345" или "ditto"?). А так да, обязательное описание в случаях когда номер сборки не изменился, а дата изменилась явно не помешает. Даже если это всего одна строка - улучшена стабильность или совместимость при работе с/исправлена редкая ошибка с тем-то при определенных обстоятельствах/слинковали статически с другими версиями библиотек/просто всё пересобрали, дата красивая. Будет хоть понятно, стоит ли обновляться и чего следует ожидать.

Немного не согласен, даже бекпорт в старую сборку должен быть отражен.

Нормальный ченжлог(+ возможность скачать старые билды) например, позволил бы разобраться, где что сломалось, между 8й и 9й сборкой.

Изменено 15 октября, 2011 пользователем XeonVs

[XeonVs]

Борис Вам не ответил или ответил не качественно ?

Не внимательный, для нового сотрудника вполне простительно, не разобрался в вашей кухне.

Баг который проверялся за 1 минуту на вашем\нашем стенде, вылился в переписку на пару часов.

 

И на мой взгляд ответ: "На данный момент веб-программисты в отпуске, будут через недели полторы." вообще не профессионален.

Изменено 15 октября, 2011 пользователем XeonVs

[vitalyb]

Немного не согласен, даже бекпорт в старую сборку должен быть отражен.

дык, я ж и написал, что в виде "бекпорт r12345" из svn он бесполезен, в отличии от человеческого описания. Комментарии к коммитам должны быть в первую очередь удобны для команды разработчиков, и вряд ли это совпадает с удобством для клиентов.

[Andrei]

Текущий лежит в разделе загрузка личного кабинета клиента.

Если чуть вернуться к моей ситуации, то сегодняс утра взял в ХД 009-ю сборку от 14.10.11. Рискнул с утра в субботу поставить. День проработало стабильно. И одинаковых ip вроде не выдавалось. Сейчас посмотрим как переживет вечерний всплеск активности пользователей.

[Andrei]

Текущий лежит в разделе загрузка личного кабинета клиента.

Если чуть вернуться к моей ситуации, то сегодняс утра взял в ХД 009-ю сборку от 14.10.11. Рискнул с утра в субботу поставить. День проработало стабильно. И одинаковых ip вроде не выдавалось. Сейчас посмотрим как переживет вечерний всплеск активности пользователей.

Не. Сглазил. IP выдаются одинаковые. В ХД написал.

[wed]

Судя по контексту, рискну предположить что существующий changelog от сборки к сборке плох. Чем? Если дадите конкретику - улучшим. Знание того, как - ключевой момент. Текущий лежит в разделе загрузка личного кабинета клиента.

 

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

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

[jp1111]

Не думаю, что ченжлог из svn будет полезен (толку от "бекпорт r12345" или "ditto"?). А так да, обязательное описание в случаях когда номер сборки не изменился, а дата изменилась явно не помешает. Даже если это всего одна строка - улучшена стабильность или совместимость при работе с/исправлена редкая ошибка с тем-то при определенных обстоятельствах/слинковали статически с другими версиями библиотек/просто всё пересобрали, дата красивая. Будет хоть понятно, стоит ли обновляться и чего следует ожидать.

Немного не согласен, даже бекпорт в старую сборку должен быть отражен.

Нормальный ченжлог(+ возможность скачать старые билды) например, позволил бы разобраться, где что сломалось, между 8й и 9й сборкой.

Поправьте меня если я не прав. Рассуждаю так: какой прок от списка и содержания коммитов от сборки к сборке если все равно пользователь не владеет кодом. Это крайность. Другая крайность - когда по записи в changelog действительно нельзя судить о конкретике изменения алгоритма. Вывод - мы увеличиваем детальность changelog, но человеческим языком (не в терминах коммитов) по которому можно судить о том как именно изменилось поведение системы и при каких условиях.

 

Говоря в целом мы уже наполовину открыли код некоторых частей системы, для внешних разработчиков. В 2.0 вынесли в открытую часть большинство "внутренних" бизнес критичных алгоритмов, включая тарификацию. Т.е. двигаемся в сотрону открытости кода. Коммиты же имеют ценность если виден код. Я для примера могу в личку кинуть пример логов svn коммитов от 9->10 - сотни строк малопонятного кода. Не представляю какая от них польза в changelog.

[jp1111]

Борис Вам не ответил или ответил не качественно ?

Не внимательный, для нового сотрудника вполне простительно, не разобрался в вашей кухне.

Баг который проверялся за 1 минуту на вашем\нашем стенде, вылился в переписку на пару часов.

 

И на мой взгляд ответ: "На данный момент веб-программисты в отпуске, будут через недели полторы." вообще не профессионален.

Да я с Вами в этом вопросе согласен. Проведем очередной тренинг по этике ответов в HD. За сотрудника приношу извинения.

[XeonVs]

Не думаю, что ченжлог из svn будет полезен (толку от "бекпорт r12345" или "ditto"?). А так да, обязательное описание в случаях когда номер сборки не изменился, а дата изменилась явно не помешает. Даже если это всего одна строка - улучшена стабильность или совместимость при работе с/исправлена редкая ошибка с тем-то при определенных обстоятельствах/слинковали статически с другими версиями библиотек/просто всё пересобрали, дата красивая. Будет хоть понятно, стоит ли обновляться и чего следует ожидать.

Немного не согласен, даже бекпорт в старую сборку должен быть отражен.

Нормальный ченжлог(+ возможность скачать старые билды) например, позволил бы разобраться, где что сломалось, между 8й и 9й сборкой.

Поправьте меня если я не прав. Рассуждаю так: какой прок от списка и содержания коммитов от сборки к сборке если все равно пользователь не владеет кодом. Это крайность. Другая крайность - когда по записи в changelog действительно нельзя судить о конкретике изменения алгоритма. Вывод - мы увеличиваем детальность changelog, но человеческим языком (не в терминах коммитов) по которому можно судить о том как именно изменилось поведение системы и при каких условиях.

 

Говоря в целом мы уже наполовину открыли код некоторых частей системы, для внешних разработчиков. В 2.0 вынесли в открытую часть большинство "внутренних" бизнес критичных алгоритмов, включая тарификацию. Т.е. двигаемся в сотрону открытости кода. Коммиты же имеют ценность если виден код. Я для примера могу в личку кинуть пример логов svn коммитов от 9->10 - сотни строк малопонятного кода. Не представляю какая от них польза в changelog.

чрезмерно детализировать лог однозначно не стоит. В минимуме достаточно одной записи на каждую публичную генерацию сборок.

Может быть вам посмотреть в сторону публичного read-only баг-трекера, для того что-бы иметь возможность не наступать на грабли коллективно и ссылаться в ченжлоге на баги? Кажется этот вопрос поднимали в "волжских далях".

 

За сотрудника, принимается. Да и если в тикете стоит дата со словами: "исправим такого-то и такого-то"; то хотелось бы, чтобы срок выдержан был? либо по истечении хоть какая-то реакция, а не игра в молчанку.

[wed]

Да и если в тикете стоит дата со словами: "исправим такого-то и такого-то"; то хотелось бы, чтобы срок выдержан был? либо по истечении хоть какая-то реакция, а не игра в молчанку.

 

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

[Negator]

вот поэтому у нас свой биллинг со своим граблями.

по крайней мере разработчики - вот они рядом, а не где то там.