01.08.2011, 14:20 | #1 |
Участник
|
единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке
*** ветка выделена отсюда Увеличение времени обработки журналов после установки новой формы ТТН ***
Цитата:
Сообщение от gene
Эти изменения появились в SYP слое (вероятно, в результате какого-то фикса поддержкой SYS, не имеющего, естественно, отношения к российской функциональности) и были автоматически аккуратно подняты в GLP.
Теперь, к сожалению, единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке. А почему так ? Считается некомильфо самим регать ? Это плохой тон ? Или вес от обращения клиента выше ? |
|
01.08.2011, 15:08 | #2 |
Microsoft Dynamics
|
Дело в зонах ответственности. Формально, поддержкой существующих версий системы занимается специально выделенная команда Sustained Engineering (SE), российский же офис - разработкой и локализацией следующих версий системы. Даже чтобы опубликовать текущее законодательное обновление, мы должны идти к той команде "на поклон". Запросы на исправление, зарегистрированные через службу поддержки, напрямую попадают к SE на исправление и они обязаны их обработать - это самый эффективный на текущий момент способ добиться исправления ошибки.
__________________
You should use Bing before asking dumb questions. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
01.08.2011, 15:33 | #3 |
Участник
|
А что будет, если вы сами обнаружите явную ошибку в приложении или ядре, про которую еще никакой клиент "не знает"? Вы ее не будете регистрировать, или команда SE не будет ее исправлять, или у нее автоматом будет более низкий приоритет?..
|
|
01.08.2011, 15:40 | #4 |
Microsoft Dynamics
|
Скорее последнее. Наиболее приоритетные баги - от клиентов и партнеров.
__________________
You should use Bing before asking dumb questions. |
|
02.08.2011, 21:25 | #5 |
Участник
|
Секундочку. А клиент может напрямую зарегистрировать баг? Насколько я помню, баг зарегистрировать мог только пратнер, да и то в количестве, не более 5 штук. И только если баг "признавался", его "возвращали" партнеру. Только довольно крупные партнеры могли позволить себе купить сервисный план, где было 300 инцендентов. При этом при личном разговоре с партнером мне было сказано, что ни одного бага они так и не отрепортили, как и многие другие, из максимамально усложненной процедуры принятия багов. Для тех, кто никогда не сталкивался, опишу: надо на поддержмваемой версии системы, желательно на самом последнем паке (иначе получите автоматом ответ, что в последней версии пофиксено), в английском интерфейсе пошагово на английском описать настройки и процесс возникновения проблемы, со скриншотами. Каюсь, даже у меня сил более чем на 6-8 багов за всю жизнь не хватило. Разумеется, ждать фиксов не стали, все сделали сами (кроме себестоимости). Поправилиили нет, не знаю, не интересовался, так как отпала острая необходимость. Себестоимость, которая в 3хе была кривая "бай дизайн", переписана. Но, разумеется, на нее сотни жалоб были. У кого память короткая, могу напомнить про тестовые забеги. Я так понимаю, что ничего не изменилось с тех пор. Особенно - в лучшую сторону, судя по последнему обновлению.
|
|
02.08.2011, 22:40 | #6 |
Участник
|
Сейчас 5 запросов только у совсем "простых партнеров". А так 20 штук. Но соглашусь, что регистрировать совсем простые баги слишком затратно, разве что собирать их в течение срока действия подписки и постить в конце, если остались свободные запросы.
__________________
Ivanhoe as is.. |
|
02.08.2011, 23:31 | #7 |
Участник
|
Цитата:
Цитата:
Сообщение от Удвой Покуров
при личном разговоре с партнером мне было сказано, что ни одного бага они так и не отрепортили, как и многие другие, из максимамально усложненной процедуры принятия багов. Для тех, кто никогда не сталкивался, опишу: надо на поддержмваемой версии системы, желательно на самом последнем паке (иначе получите автоматом ответ, что в последней версии пофиксено), в английском интерфейсе пошагово на английском описать настройки и процесс возникновения проблемы, со скриншотами.
Цитата:
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
03.08.2011, 10:08 | #8 |
Moderator
|
Поскольку тема окончательно ушла в оффтоп, я тоже, пожалуй, поучаствую:
По поводу расширенной поддержки: 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% ее функциональности. Еще более ненормальным кажется тот факт, что баг, признанный автором бага в группе российской локализации, не может быть исправлен без прохождения всей цепочки фронт-лайн саппортеров. Последний раз редактировалось fed; 03.08.2011 в 10:30. |
|
|
За это сообщение автора поблагодарили: mazzy (2), Alexius (3), AlGol (2), Logger (10). |
03.08.2011, 10:32 | #9 |
Участник
|
разделил ветки. теперь это онтоп.
да, полностью согласен с fed. Цитата:
партнеры все равно делают некую базу собственных наработок. лечение багов относится туда же. регистрация в МС будет нормально происходить только если регистрация багов будет выполняться очень легко. примерно как в службах поддержки у провайдеров. еще никто не отклонял мои заявки в службах поддержки провадеров только потому что вопрос плохо составлен. Если вопрос действительно дурацкий, то мне дают отписку. Но на большинство вопросов отвечают по делу в какой бы форме я ни сформулировал вопрос. При общении с провайдреами я сам заинтересован составить вопрос наиболее полно и достоверно - ведь я же хочу получить ответ. примерно так работают все ИТ-службы, которые я видел у клиентов и которые работают с системой заявок от пользователей. примерно так и мы стараемся работать с вопросами пользователей - принимаем любые вопросы. И уже сами сортируем, объединяем дубли, группируем. если нужно, то переспрашиваем. на моей памяти только две службы поддержки, с которыми общаться не хотелось -поддержка делового софта у 1Са и поддержка в МБС. Добавил: не, вру. вспомнил и третью. служба поддержки клиент-банка в Сбербанке - это запредельный пипец. Добавил: хочу сказать большое спасибо МБСу, что разрешили задавать вопросы на русском. Раньше было только на английском. Уже хорошо. Последний раз редактировалось mazzy; 03.08.2011 в 11:04. Причина: добавил спасибо. добавил про Сбербанк |
|
|
За это сообщение автора поблагодарили: Logger (3). |
03.08.2011, 10:36 | #10 |
Banned
|
Цитата:
В плане потери времени я бы не был так пессимистичен. Я обычно тестовые данные не готовлю, а вкратце описываю сюжет и оптправляю. У специалиста могут появиться вопросы, но я рекомендую ему попробовать воспроизвести все самому и в 90% случаев он превосходно справляется. Потом на протяжении примерно полугода специалист создает видимость работы, то бишь держит меня в курсе: "мы работаем... запрос уже ушел в ХХХ, работаем... ХХХ анализирует..." Ничего особенного в этом нет. Наша поддержка для клиентов работает точно так же за исключением в разы большей скорости и эффективности. |
|
03.08.2011, 10:52 | #11 |
Moderator
|
Цитата:
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% случаев он превосходно справляется.
fed добавил ссылку здесь http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx Последний раз редактировалось mazzy; 16.03.2013 в 14:14. Причина: добавил ссылки на axforum; добавил ссылку от fed |
|
|
За это сообщение автора поблагодарили: mazzy (2), Maximin (3), Vadik (1), raz (7), Logger (30), AndyD (10), Ivanhoe (5), alex55 (1), pedrozzz (1). |
03.08.2011, 11:00 | #12 |
Banned
|
|
|
03.08.2011, 23:37 | #13 |
Участник
|
Цитата:
Сообщение от gl00mie
Это, наверно, оттого партнер ваши баги не регистрировал, что вы поддержку не покупали, потому что не видите в ней смысла никакого[/URL] По той же причине от вас, вероятно, и скриншоты требовали. Я лично зарегистрировал через партнера несколько багов, и часть вполне себе оперативно была исправлена.
А вообще, проблема известная. Когда мс купил навижн, они собрали партнеров и стали спрашивать, что улучшить. Тогда впервые микрослфту было сказанно о качестве поддержки. Ничего с тех пор не изменилось, только главы мбс. Мы говорили про поддержку Владу, потом Жене, потом Питеру и Саше, потом Владимиру. А microsoft каждый год продолжает спрашивать и искренне изумляется, почему партнеры не пользуются поддержкой, ведь без обратной связи они не могут улучшить качество продуктов. Мне про поддержку надоело говорить еще Евгению. Но все равно, этой осенью снова начнется шоу и снова зададут вопросы партнерам, так что же все-таки улучшить. Кстати, а не моглибы Вы привести примеры того, какие ошибки Вам исправили в мс? Очень интересно. А то отрицательные примеры есть, а положительные - только на словах и эмоциях. Ошибка - номер реквеста - в каком фиксе вышло исправление, если не затруднит. Вы не вводите общественность в заблуждение, я надеюсь? |
|
04.08.2011, 01:13 | #14 |
Участник
|
Почитал обсуждение - все плохо. Получается ни клиент, ни партнер не заинтересованы регистрировать баг и добиваться их исправления от MS.
А что бы вы могли предложить чтобы исправить ситуацию ? В техподдержке провайдера ведь нет так. И во многих других IT компаниях. Какая должна быть модель работы поддержки ? P.S. Кстати, а как с этим у сапёров и ораклоидов (про 1С уже выяснили) ? То же самое ? Если да, то может это родовая болезнь ёпрст систем ? |
|
04.08.2011, 01:23 | #15 |
Участник
|
Цитата:
Сообщение от 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 постарался. Большое спасибо. По сути, несколько людей в России на голом энтузазизме делают большую работу заменяя по отдаче целые отделы по документированию и пиару. С одной стороны грустно что все так. А с другой стороны хорошо что они у нас есть |
|
04.08.2011, 01:33 | #16 |
Участник
|
Цитата:
KB2471102 Исправление вышло в конце ноября 2010, впоследствии вошло в RU7. |
|
04.08.2011, 08:39 | #17 |
Moderator
|
Цитата:
Если специалист за последние два года (допустим) зарегистрировал более 10 багов и из них свыше 80% было подтверждено, то этот специалист может САМ эскалировать баги к escalation engineer, минуя необходимость общаться с фронтлайнером. Да - и спасибо за символы все-таки Тарику. Я тут мало причастен. (Разве что доставал Тарика просьбами проанализировать дамп). |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
04.08.2011, 08:51 | #18 |
Участник
|
Цитата:
Ты всего лишь надеешься, что эту стенку можно сделать конечной толщины. так? |
|
04.08.2011, 09:42 | #19 |
Moderator
|
Нельзя стенку убирать. Посмотри, например, средний уровень вопросов на community.dynamics.com. Похоже что в некоторых культурах принятно СНАЧАЛА спрашивать окружающих и только потом включать свою голову. Представляешь чем кончиться попытка открыть свободный доступ к поддержке всем желающим ?
|
|
|
За это сообщение автора поблагодарили: Vadik (1). |
04.08.2011, 10:45 | #20 |
Участник
|
Цитата:
Именно поэтому, если "стенку" убрать совсем, то вместо регистрации багов получится тех.поддержка. Это же так просто - спросил и тебе ответили. Не надо самому напрягаться... |
|
Теги |
aos, crash, dump analisys, support, tariq bell, uniconta, аос, поддержка, полезное |
|
|