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

[mifi]

Цитата:

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

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

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

[BOAL]

Цитата:

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

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

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

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

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

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

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

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[mifi]

Цитата:

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

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


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



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

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

[sukhanchik]

Цитата:

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

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

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

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

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

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

[mifi]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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