Отладка на рабочей базе

[mifi]

Цитата:

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

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

Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.
Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных?

[BOAL]

Цитата:

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

Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.
Еще раз повторю - внедренец профессионал внедрения, не клиент. Его обязанность объяснить, обучить, организовать.
Что мешает настроить резервное копирование так, чтобы иметь тестовое приложение с актуальными данными (если клиент-таки разрешает к ним доступ) и проводить хотя бы минимальное тестирование? Не проще, чем потом сотни джобов писать для правки багов в реальных данных?

Клиент сам решит - если есть выбор!

Иногда повтор ситуации займет 2-4ч реала или бакап Террабайтной базы ( это тоже не 1 час) + останов системы на Х часов.
Речь о том, что система отладки нужна на любой версии, а вот как ее применять (запрещать) - это осознанная методология внедрения\эксплуатации.
Но инструмент должен быть!
Это как шуроповерт или простая отвертка дома - она нужна не всегда, но бывает момент... и опа, она есть, а не нужно идти к соседу, а потом ее нести обратно.

Вот и тут так же - это все (отладка на рабочей) не нужно и нештатно - но это должно быть в ассортименте.

Просто в проекте есть моменты, когда это уж очень нужно и становится штатным (опытная эксплуатация на 1-3 недели).

Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят

[AlGol]

Цитата:

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

Фед, почему минимальное использование best practices внедрения и поддержки (такое, как использование тестового приложения) вызывает такое отторжение?
Честное слово - я бы таким внедренцам, дебажащим на рабочем приложении, что-нибудь бы поотрывал

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

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

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

[sukhanchik]

Цитата:

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

Но и да, кто сам на клиенте не просидел и в глаза пользователям не смотрел (не абстрактным сотрудникам Заказчика, а конкретной Марье Ивановне), тот это все через себе не пропустит и другую точку зрения просто не поймет, а только проанализирует, смоделирует, прикинет и сделает выводы (надеюсь не "а и так сойдет", как обычно).
Че уж говорить о "теоретиках", которые даже глаз внедренца не видят

Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди

Цитата:

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

Давайте все-таки разделять две вещи - максимально быстро фиксить баги и дебагить на рабочей версии.
Клиенту нужно первое. А второе - это только один из способов.

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

Цитата:

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

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

Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо.
Опять-таки:
- на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя
- на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек

[mifi]

Цитата:

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

Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди


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



Конечно можно все организовать. Но, повторюсь, - не все может вылезти на тестовой базе. Ярким примером могут быть ситуации, которые завязаны на интеграцию АХ с чем-либо.
Опять-таки:
- на тестовой базе нельзя (сложно = дольше) выявить ошибки пользователя
- на тестовой базе нельзя (сложно = дольше) выявить изменение настроек, выполненных ответственными за это сотрудниками, которые отнеслись безответственно к смене настроек

В общем, все так За исключением того, что на тестовой базе нельзя или сложно или существенно дольше выявить ошибки. Не беря в учет интеграцию (где эти ошибки могут быть "с другой стороны", поэтому в Аксе особо и не подебагишь), то почему на тестовой базе это будет существенно дольше (думаю, что в отличие от BOAL Вы в курсе, что совсем необязательно каждый раз делать полный бэкап терабайтной базы, поэтому получить слепок рабочей базы за полчаса-час вполне реально)

[BOAL]

А меня вот парят эти вот пол-часа - час, там где их раньше не было вообще (1-5 мин или 60 мин -это все же х12-60 разницы, при этом эти 5 мин еще и на тесте тратить). Да и выгружать по-живому куски таблиц тоже работа. То есть в ущерб чему-то или спец чел. И кто сказал, что в Тб базе эти нужные куски тоже не маленькие - вдруг там контрольный пример как раз неверная сумма на кучи данных?

В общем, выжить будет можно, станет сложнее на пустом месте, дольше в суппорте, а значит выше цена владения. И сложности (отпугивание) при продажах.

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

Электрорубанком при определенном усердии (таком же, как ты, Миша, предлагаешь) и с выключенном электричеством можно строгать

Цитата:

Все верно - но не следует уж прям так с ходу наезжать на МС. Там же тоже люди

Да не, все ясно, все помнят, как было и пугаются, как стало (станет).
Тут скорее "мне за державу обидно"(С) В смысле систему.

[SolNik]

Речь не идет о разработке на рабочем окружении. Речь идет о поиске и выявлении причин неадекватного поведения продуктива системы.
Особенно это актуально на запуске системы.
Если такой возможности не будет в новой версии - это будет катастрофа.
Кстати в основном потребность трейсинга для выяснения причин невнятных сообщений об ошибках или что еще хуже - трассировок стека - это "сюрпризы" от MS из-за некачественного тестирования нового функционала.
На одном проекте из-за багов в стандарте в новом функционале многопоточного сводника в 2009 под угрозой оказалось продолжение эксплуатации системы.
Весь функционал тестировался перед запуском, но баг вылез только на больших объемах.
Если бы в этот момент (когда под угрозой стояла поставка в магазины на следующий день) мы предложили сделать копию рабочей базы и не спеша там поискать причину ошибки - проект бы точно остановили.

[sukhanchik]

Цитата:

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

В общем, все так За исключением того, что на тестовой базе нельзя или сложно или существенно дольше выявить ошибки. Не беря в учет интеграцию (где эти ошибки могут быть "с другой стороны", поэтому в Аксе особо и не подебагишь), то почему на тестовой базе это будет существенно дольше (думаю, что в отличие от BOAL Вы в курсе, что совсем необязательно каждый раз делать полный бэкап терабайтной базы, поэтому получить слепок рабочей базы за полчаса-час вполне реально)

Про тестовую базу BOAL так сказал по одной простой причине. Если использовать тестовую базу, как буфер перед переносом модификаций на рабочую, то нельзя вести копию рабочей БД "чисто для суппорта".
Я не очень помню - отменяли ли правило "разрешенных трех приложений" в лицензионной политике - но если не отменяли - то нет возможности так плодить базы.
А если есть возможность, то получается нужно иметь помимо рабочей БД еще:
- разработческую
- тестовую
- демонстрационную (для обучения новых пользователей)
- суппортную (которая постоянно обновляется)

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

По поводу интеграции. Ошибки могут быть где угодно. И в АХ в том числе. А вот для выявления этих ошибок как ни крути нужен дебаггер. Особенно - если ошибка не на стороне АХ.

А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).

[sukhanchik]

Цитата:

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

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

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

Просто скорее всего все это кончится тем, что отладку будут включать на рабочей БД, клиенты будут мучаться с производительностью, а в МС гадать - а чем же производительность АХ их не устраивает.

[belugin]

пересмотрите видео - отладка там есть

[mifi]

Цитата:

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

пересмотрите видео - отладка там есть

А это же вроде с самого начала было понятно, об ее отсутствии заявил Фед, а не Питер С Густаво Я-то просто удивился, что это такая сверхнужная фича

[mifi]

Цитата:

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

А более долгое выявление ошибок связано с тем, что пользователь только только вводит новые данные, которых еще нет в "суппортной" базе. И просит консультации "что у него не так". И тут очень сильно пригождается дебаггер, который позволяет быстро(!) выявить проблему отдельно взятого пользователя, чтобы сказать - ты сам виноват - не указал то-то и то-то. После чего дать задание программистам чтобы они эту ситуацию "обрамили" в адекватное сообщение (если это возможно).

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

[greench]

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

И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд...

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

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

[EVGL]

Цитата:

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

А это же вроде с самого начала было понятно, об ее отсутствии заявил Фед, а не Питер С Густаво Я-то просто удивился, что это такая сверхнужная фича

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

[mifi]

Цитата:

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

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

И организация процесса разработки на клиенте немного другая. Очень часто ТЗ никто не пишет, документации как таковой в природе не существует или осталась устаревшая от внедренца и тд...

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

При грамотном подходе можно и SQL Server затюнить и 1С заставить летать и много чего еще. Мы все выбираем соотношение цена/качество - и не стремимся купить бентли для поездки на дачу. Так почему же МС заставляет отказываться от АХ?

[greench]

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

[sukhanchik]

Цитата:

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

Пусть это нужно 1 раз в год на 10мин, но это экономит эти 3.65 дня дауна системы.

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

Все отсюда пошло:

Цитата:

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

А еще реальностью стал (по моим источникам) геморрой с перезагрузкой откомпилированных сборок. То есть - либо рестарт боевого AOS, либо работа через Application Domain. Причем скорость второго режима, мягко говоря, бледно смотриться даже на фоне скорости старого интерпретатора.
Ооо - почитал твиттер Брендона:
1. Отладка на сервере возможна только через VS Debugger
2. Чтобы отлаживаться, придется включать App Domain с тормозами.
3. Если у тебя на сервере работает несколько разработчиков - опять таки только App Domain с hot-swapping.

Т.е. при выборе системы все расписывают как она будет летать. МС готовит кучу тестов естественно без режима отладки.
В жизни получается (клиент делает такой вывод или ему помогают сделать такой вывод) что режим отладки (Application Domain) должен быть постоянно включен на рабочей БД, что влияет на скорость работы.
У клиента наступает разочарование и полное желание отказаться от такой системы (если хватает денег ).
Клиент меняет систему и имеет систему если не лучше то по крайней мере дешевле.
Клиент всем своим знакомым рассказывает - какой отстой - АХ - и ни в коем случае не работайте с МС - там нет компетентных людей.

[belugin]

Отлаживаться можно без APPDomain насколько я знаю.

Горячую замену нужно проводить через APPDomain.