единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке

[Logger]

*** ветка выделена отсюда Увеличение времени обработки журналов после установки новой формы ТТН ***

Цитата:

Сообщение от gene

Эти изменения появились в SYP слое (вероятно, в результате какого-то фикса поддержкой SYS, не имеющего, естественно, отношения к российской функциональности) и были автоматически аккуратно подняты в GLP.
Теперь, к сожалению, единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке.

Уже не в первый раз от сотрудников MS звучит такая просьба.
А почему так ?
Считается некомильфо самим регать ?
Это плохой тон ?
Или вес от обращения клиента выше ?

[Jabberwocky]

Дело в зонах ответственности. Формально, поддержкой существующих версий системы занимается специально выделенная команда Sustained Engineering (SE), российский же офис - разработкой и локализацией следующих версий системы. Даже чтобы опубликовать текущее законодательное обновление, мы должны идти к той команде "на поклон". Запросы на исправление, зарегистрированные через службу поддержки, напрямую попадают к SE на исправление и они обязаны их обработать - это самый эффективный на текущий момент способ добиться исправления ошибки.

[gl00mie]

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

[Jabberwocky]

Скорее последнее. Наиболее приоритетные баги - от клиентов и партнеров.

[Удвой Покуров]

Цитата:

Сообщение от Jabberwocky

Скорее последнее. Наиболее приоритетные баги - от клиентов и партнеров.

Секундочку. А клиент может напрямую зарегистрировать баг? Насколько я помню, баг зарегистрировать мог только пратнер, да и то в количестве, не более 5 штук. И только если баг "признавался", его "возвращали" партнеру. Только довольно крупные партнеры могли позволить себе купить сервисный план, где было 300 инцендентов. При этом при личном разговоре с партнером мне было сказано, что ни одного бага они так и не отрепортили, как и многие другие, из максимамально усложненной процедуры принятия багов. Для тех, кто никогда не сталкивался, опишу: надо на поддержмваемой версии системы, желательно на самом последнем паке (иначе получите автоматом ответ, что в последней версии пофиксено), в английском интерфейсе пошагово на английском описать настройки и процесс возникновения проблемы, со скриншотами. Каюсь, даже у меня сил более чем на 6-8 багов за всю жизнь не хватило. Разумеется, ждать фиксов не стали, все сделали сами (кроме себестоимости). Поправилиили нет, не знаю, не интересовался, так как отпала острая необходимость. Себестоимость, которая в 3хе была кривая "бай дизайн", переписана. Но, разумеется, на нее сотни жалоб были. У кого память короткая, могу напомнить про тестовые забеги. Я так понимаю, что ничего не изменилось с тех пор. Особенно - в лучшую сторону, судя по последнему обновлению.

[gl00mie]

Цитата:

Сообщение от Удвой Покуров

А клиент может напрямую зарегистрировать баг? Насколько я помню, баг зарегистрировать мог только пратнер, да и то в количестве, не более 5 штук.

Вроде как расширенную поддержку можно купить непосредственно у MBS (fed писал об этом) - в этом случае, думаю, ошибки может регистрировать и непосредственно клиент.

Цитата:

Сообщение от Удвой Покуров

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

Это, наверно, оттого партнер ваши баги не регистрировал, что вы поддержку не покупали, потому что не видите в ней смысла никакого По той же причине от вас, вероятно, и скриншоты требовали. Я лично зарегистрировал через партнера несколько багов, и часть вполне себе оперативно была исправлена. Да, шаги по воспроизведению зачастую требуют на английском, потому что если, к примеру, баг в ядре, то там врядли найдется много русскоговорящих разработчиков, а так, вменяемого пошагового описания (делай раз, делай два, делай три - получи не то, что ожидалось) и тестового джобика для воспроизведения вполне бывает достаточно. Я лично изо дня в день занимаюсь в т.ч. поддержкой и для себя решил, что если кому-то лень потратить 5 минут на описание его проблемы и способа ее воспроизведения на уровне человека, который не работает с этим функционалом каждый день, то почему мне должно быть не лень вообще в этом копаться? И в этом плане я специалистов поддержки MS очень даже понимаю.

Цитата:

Сообщение от Удвой Покуров

У кого память короткая, могу напомнить про тестовые забеги. Я так понимаю, что ничего не изменилось с тех пор. Особенно - в лучшую сторону, судя по последнему обновлению.

Насколько я понимаю, скорость исправления бага во многом зависит от того,

1. как этот баг влияет на бизнес клиента в целом; это show stopper или просто досадное неудобство?
2. каковы приоритеты команды SE "в текущем сезоне": если есть куча зарегистрированных багов, то между ними по-любому как-то расставляют приоритеты (см. также п.1), и не факт, что именно ваш баг окажется первым в списке на исправление.

Опять же, формализм, который мне лично в рабочих отношениях очень импанирует, диктует свои правила, в частности: нет зарегистрированного бага - нет проблемы. И хоть вы оппишитесь на форумах про кривую себестоимость в 3.0 - с т.з. специалистов поддержки все будет шоколадно, пока вы не зарегистрируете ошибку в соотв. системе. Я лично это тоже уже проходил: до определенного момента можно решать вопросы на уровне личных отношений, неформального общения по аське/почте и т.п., но после определенного порога это все перестает восприниматься как руководство к действию. Нет запроса - нет проблемы, и точка.

[Удвой Покуров]

Цитата:

Сообщение от gl00mie

Это, наверно, оттого партнер ваши баги не регистрировал, что вы поддержку не покупали, потому что не видите в ней смысла никакого[/URL] По той же причине от вас, вероятно, и скриншоты требовали. Я лично зарегистрировал через партнера несколько багов, и часть вполне себе оперативно была исправлена.

Видимо, Вы не совсем внимательно читали. Регистрировал я ошибки сам, когда был на партнере. До этого, на клиенте - у меня не было такой возможности, партнер говорил, что от Microsoft - неизвестно сколько ждать исправления, и предлагал исправить за денюжку.
А вообще, проблема известная. Когда мс купил навижн, они собрали партнеров и стали спрашивать, что улучшить. Тогда впервые микрослфту было сказанно о качестве поддержки. Ничего с тех пор не изменилось, только главы мбс. Мы говорили про поддержку Владу, потом Жене, потом Питеру и Саше, потом Владимиру. А microsoft каждый год продолжает спрашивать и искренне изумляется, почему партнеры не пользуются поддержкой, ведь без обратной связи они не могут улучшить качество продуктов. Мне про поддержку надоело говорить еще Евгению. Но все равно, этой осенью снова начнется шоу и снова зададут вопросы партнерам, так что же все-таки улучшить.

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

[gl00mie]

Цитата:

Сообщение от Удвой Покуров

Ошибка - номер реквеста - в каком фиксе вышло исправление, если не затруднит.

Unable to display correct SPID in Users Online if SPID exceeds 8 characters
KB2471102
Исправление вышло в конце ноября 2010, впоследствии вошло в RU7.

[Ivanhoe]

Сейчас 5 запросов только у совсем "простых партнеров". А так 20 штук. Но соглашусь, что регистрировать совсем простые баги слишком затратно, разве что собирать их в течение срока действия подписки и постить в конце, если остались свободные запросы.

[fed]

Поскольку тема окончательно ушла в оффтоп, я тоже, пожалуй, поучаствую:
По поводу расширенной поддержки:
1. Уже после переезда в Турцию, я пытался узнать (для пары знакомых клиентов), оказывается ли подобная поддержка для России и сколько она стоит. Сразу скажу - действовал я неформально, по старым контактам в Микрософт. Возможно - по официальным каналам, я бы получил другую информацию. Так вот - в продажно-маркетинговых подразделениях MBS-Russia про подобную поддержку либо вообще не знали, либо чего-то очень давно слышали, но никакой конкретики не знают. В службе поддержки сказали, что они,конечно, про это слышали, но, вроде бы, она в России не оказывается. Может быть, если сразу много клиентов запросят возможность покупки этой поддержки, ее и начнут оказывать, но в данный момент ее просто нет.
2. Расширенность поддержки не гарантирует ее качества. Я тут как-то ездил к клиенту, у которого порядка 10 дней подряд каждые час-полтора падал AOS. У клиента была расширенная поддержка. Его инцидентом занимался какой-то аутстаффинговый индус (или пакестанец) из Sonata Software. Падение сервера, этот индус пытался лечить перебирая разные магические значения размера буфера в конфигураторе сервера, а также путем отсылки клиенту всяких архивных промежуточных билдов ядра (какие-то релизы между RU3-RU4-RU5). Когда я приехал, я просто тупо накатил RU7 и все прошло. Надо, правда, заметить, что если бы клиент не тупил, а сразу нажаловался на этого индуса своему менеджеру по расширенной поддержке, вполне возможно что его бы заменили на кого-то вменяемого. Правда чтобы у клиента появилось такое желание, надо чтобы он хотя бы раз столкнулся с кем-то вменяемым в поддержке MBS, правда ведь ?
3. Надо заметить, что у микрософта еще есть такая услуга как Microsoft Premium Support. Это совершенно отдельная услуга, которую предоставляет не MBS, а Microsoft Consulting Service. Стоит это порядка сотен тысяч долларов в год, и в принципе включает в себя прямую поддержку ВСЕГО продуктового стека. (Я даже знаю историю как клиент нашел баг в MS Flight Simulator и через Premium Support добился ее оперативного исправления) Правда тут надо заметить, что менеджеры по premium support обычно плохо понимают MBSовскую специфику и не очень-то хорошо умеют работать с поддержкой MBS

Выскажу свои соображения по поводу полезности эскалации багов в MBS в целом:
В случае обнаружения и идентификации бага в AX у меня есть, грубо говоря, два пути - исправить баг самому или ждать его исправления поддержкой.
Если я нашел баг и нашел пути его воспроизведения (а это всегда нужно чтобы зарегистрировать баг в поддержке), то с вероятностью 95%, я знаю как исправить этот баг. И скорее всего, исправление этого бага потребует от нескольких часов до нескольких дней работы.
Если же я попытаюсь зарегистрировать баг в MBS, то мне придется:
1. Подготовить тестовые данные для стандартного приложения.
2. Потратить время чтобы объяснить этот баг специалисту поддержки. (Возможно несколько конфколлов придется провести или кучу времени на переписку потратить или зааплодить нашу демо-базу в MBS)
3. Если этот баг признают, то никаких временных рамок по его исправлению мне не сообщат.Соответственно - я буду иметь кучу финансовых потерь от неработспособности функциональности.
4. Если этот баг будет исправлен в очередном rollup, то мне придется потратить очень немало времени и сил (и - возможно- времени и сил моих пользователей) на то чтобы на этот роллап заапгрейдиться.

Поэтому в 99% случаев, любой баг правится самостоятельно, а потом, возможно, регистрируется в MBS. Однако, регистрация уже исправленного тобой бага в MBS, это гарантированно работа с негативным экономическим эффектом, поскольку:
1. Ты тратишь свое время (гарантированные затраты), с очень негаратированным результатом (неизвестно признают ли твой инцидент ошибкой; если признают, то неизвестно будут ли исправлять; если будут исправлять - то неизвестно в каком rollup).
2. В случае если ошибка будет таки исправлена, то с большой вероятностью, это приведет к дополнительным затратам. Скажем, если ты незарепортил баг, то скорее всего твое исправление будет поднято на новый rollup (если ты на него будешь апргрейдиться) полуавтоматически, Если же ты его зарепортил, то тебе придется заниматься исследованием того как микрософтовский подход к исправлению бага отличается от твоего собственного, курочить и свой и микрософтовской код, писать конвертеры данных для апгрейда.

Соответственно, регистрация ошибок выгодна ТОЛЬКО для партнеров (которые вели и ведут много проектов) и ТОЛЬКО если речь идет о какой-то часто встречающейся ошибке, в часто внедряемом модуле. Только в этом случае, есть слабые шансы что затраты на регистрацию ошибки, когда-то отобьются. (И то не факт).

Так что, мы все конечно должны поблагодарить gl00mie за регистрацию багов, но вот его работодатель должен был бы выписать ему штраф за бессмысленные потери рабочего времени.

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

[mazzy]

Цитата:

Сообщение от fed

Поскольку тема окончательно ушла в оффтоп

разделил ветки. теперь это онтоп.

да, полностью согласен с fed.

Цитата:

Сообщение от fed

Соответственно, регистрация ошибок выгодна ТОЛЬКО для партнеров (которые вели и ведут много проектов) и ТОЛЬКО если речь идет о какой-то часто встречающейся ошибке, в часто внедряемом модуле.

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

регистрация в МС будет нормально происходить только если регистрация багов будет выполняться очень легко.

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

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

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

на моей памяти только две службы поддержки, с которыми общаться не хотелось -поддержка делового софта у 1Са и поддержка в МБС.
Добавил: не, вру. вспомнил и третью. служба поддержки клиент-банка в Сбербанке - это запредельный пипец.

Добавил: хочу сказать большое спасибо МБСу, что разрешили задавать вопросы на русском. Раньше было только на английском. Уже хорошо.

[EVGL]

Цитата:

Сообщение от fed

Поэтому в 99% случаев, любой баг правится самостоятельно, а потом, возможно, регистрируется в MBS.

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

В плане потери времени я бы не был так пессимистичен. Я обычно тестовые данные не готовлю, а вкратце описываю сюжет и оптправляю. У специалиста могут появиться вопросы, но я рекомендую ему попробовать воспроизвести все самому и в 90% случаев он превосходно справляется. Потом на протяжении примерно полугода специалист создает видимость работы, то бишь держит меня в курсе: "мы работаем... запрос уже ушел в ХХХ, работаем... ХХХ анализирует..." Ничего особенного в этом нет. Наша поддержка для клиентов работает точно так же за исключением в разы большей скорости и эффективности.

[fed]

Цитата:

Сообщение от EVGL

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

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

После этого краш-дампы стало возможным анализировать самому - без поддержки...

Цитата:

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

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

fed добавил ссылку здесь
http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx

[EVGL]

Цитата:

Сообщение от fed

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

Да нет, я просто им пишу: "Извини, Наталия Фернандес / Золтан / Амитабха, но у меня нет времени на разжевывание. Обрати внимание на это и это." И ничего, справляются.

[Logger]

Цитата:

Сообщение от fed

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash
Finding the X++ call stack that caused a crash
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

Эти ссылки надо в рамочку и на видное место. В какой нить раздел на форуме. Как минимум тэг "полезное" обеспечен.
Я когда их увидел в блоге - еще удивился - не ожидал такого. А оказывается это опять fed постарался.
Большое спасибо.

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

С одной стороны грустно что все так. А с другой стороны хорошо что они у нас есть

[gl00mie]

Цитата:

Сообщение от fed

с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

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

Цитата:

Сообщение от gl00mie

Надо только учесть, что у Tariq'а в статье есть пара опечаток, которые становятся очевидны при просмотре приведенного им выхлопа отладчика:

1. Цитата:

   Look for the Ax32Serv!interpret::evalFunc frames take the location from the line below and then run in AX2009 64 bit: dw 000000002311b150+30
   на самом деле +20
2. Цитата:

   Next you can run in AX2009 64 bit: db 000000002311b150+38
   на самом деле +28

Для аналогичного анализа дампа памяти или "живого" клиента AX 2009 подходят приведенные им рецепты для AX4 32-bit (ну и плюс в этом случае надо использовать WinDBG x86 - даже на винде x64). Да, и лучше это все делать на ядре RU7, потому что для него отладочные символы в открытом доступе есть, а для RU6, насколько я могу судить, - нет.
Также хочу напомнить, что с ключом ком. строки /console AOS можно запустить не как сервис, а как обычное консольное приложение - в т.ч. прямо из-под отладчика.

[Logger]

Цитата:

Сообщение от fed

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

После этого краш-дампы стало возможным анализировать самому - без поддержки...

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

fed добавил ссылку здесь
http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx

Пишут что автомат отключили
https://blogs.msdn.microsoft.com/axs...-discontinued/
и вместо него есть еще одна инструкция
https://blogs.msdn.microsoft.com/cob..._dmp_analysis/

[Logger]

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

А что бы вы могли предложить чтобы исправить ситуацию ? В техподдержке провайдера ведь нет так. И во многих других IT компаниях.

Какая должна быть модель работы поддержки ?

P.S. Кстати, а как с этим у сапёров и ораклоидов (про 1С уже выяснили) ?
То же самое ?
Если да, то может это родовая болезнь ёпрст систем ?

[fed]

Цитата:

Сообщение от Logger

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

А что бы вы могли предложить чтобы исправить ситуацию ? В техподдержке провайдера ведь нет так. И во многих других IT компаниях.

Я бы предложил вести учет зарегистрированных багов не только в разрезе партнера/клиента, но и в разрезе специалиста зарегистрировавшего баг.
Если специалист за последние два года (допустим) зарегистрировал более 10 багов и из них свыше 80% было подтверждено, то этот специалист может САМ эскалировать баги к escalation engineer, минуя необходимость общаться с фронтлайнером.

Да - и спасибо за символы все-таки Тарику. Я тут мало причастен. (Разве что доставал Тарика просьбами проанализировать дамп).

[mazzy]

Цитата:

Сообщение от fed

Если специалист за последние два года (допустим) зарегистрировал более 10 багов и из них свыше 80% было подтверждено, то этот специалист может САМ эскалировать баги к escalation engineer, минуя необходимость общаться с фронтлайнером.

Другими словами, ты даже не надеешься, что ситуацию можно изменить в принципе?
Ты всего лишь надеешься, что эту стенку можно сделать конечной толщины. так?