Причины НЕ запускать критическое для бизнеса консольное приложение C # через отладчик?

Question

Я ищу несколько тем для разговора, которые я мог бы использовать, чтобы убедить коллег в том, что запускать производственное приложение в режиме 24/7 НЕЛЬЗЯ, просто открыв Visual Studio и запустив приложение в режиме отладки.

Чем отличается запуск скомпилированного консольного приложения от запуска этого же приложения в режиме отладки?

Были ли случаи, когда вы использовали бы отладчик в режиме реального времени? (в режиме реального времени: значение связано с клиентскими базами данных)

Я ошибаюсь, полагая, что запускать живую конфигурацию через отладчик всегда плохая идея?

Answer 1

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

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

Немного отступив, этот вопрос может дать некоторые рекомендации по влиянию на вашу команду.

Answer 2

Само по себе нет проблем в запуске его при отладке, если производительность достаточно хорошая. Мне кажется странным то, что вы запускаете критически важные для бизнеса круглосуточные приложения в качестве пользователей, возможно, даже на рабочей станции. Если вы хотите обеспечить надежность и доступность, вам следует рассмотреть возможность запуска этого на выделенном оборудовании, которое никто не использует, кроме приложения. Если вы действительно запускаете это на компьютере пользователя, легко могут произойти несчастные случаи, такие как закрытие «неправильной» Visual Studio, или сбой компьютера и т. Д.

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

Производство

• Специальное оборудование
• Ограниченный доступ, как правило, только основные разработчики / технологии
• Контроль версий, определенная теговая версия из SVN / CVS
• Запуск последней стабильной версии, которая была переведена в рабочий статус

Release

• Специальное оборудование
• Полный доступ ко всем разработчикам
• Контроль версий, определенная теговая версия из SVN / CVS
• Запускает следующую версию продукта, еще не переведенную в производственное состояние, но, вероятно, будет. «Золото», если хотите.

Test

• Аппаратные средства виртуальной машины или вши
• Полный доступ
• Нет контроля версий, может быть следующая, следующая версия или просто пользовательская сборка, которую кто-то хотел протестировать в "среде, близкой к Prod"

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

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

Answer 3

Говоря очень обобщенно, когда вы запускаете программу под отладчиком, вы на самом деле запускаете два процесса - цель и отладчик - и довольно тесно связываете их вместе. Таким образом, существуют возможности для неожиданных влияний и ошибок (которых нет в производственном процессе). Конечно, люди, которые пишут отладчики, делают все возможное, чтобы минимизировать эти эффекты, но выполнение этого сценария 24/7, вероятно, выявит любые проблемы, которые существуют.

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

Отладчик также использует ресурсы - в зависимости от компьютера и приложения, это может быть проблемой. Если вам нужны более конкретные примеры того, что может работать неправильно при использовании отладчика 24/7, дайте мне знать.

Answer 4

Спросите их, не хотели бы они издеваться над The ​​Daily WTF. (Поскольку при написании достаточно подробностей, это будет соответствовать требованиям.)

Answer 5

Простой ответ: вы почти наверняка снизите производительность (скорее всего, значительно) и значительно увеличите свои зависимости. За один шаг вы добавили весь стек VS, включая IDE и все остальные, к своим зависимостям. Умные люди держат зависимости сервисов с высокой готовностью как можно дольше.

Если вы хотите работать под отладчиком, вам следует использовать более легкий отладчик, такой как ntsd, это просто безумие.

Answer 6

Вы определенно не хотите, чтобы приложение, которое должно работать до 24/7, запускалось вручную из отладчика независимо от проблем с производительностью. Если вам нужно убедить своих коллег в этом, найдите новую работу.

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

Answer 7

Я не могу говорить за опыт каждого, но для меня Visual Studio часто дает сбой. Это не только разбивает себя, но это разбивает исследователь. Это усугубляется надстройками и плагинами. Я не уверен, тестировалось ли оно когда-либо для круглосуточной работы в течение дней и дней и дней так же, как в ОС.

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

Кроме того, вы платите за визуальные лицензии на студии для производственных машин?

Answer 8

Я бы спросил их, в чем преимущество запуска через Visual Studio?

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

Answer 9

Помимо кода отладки, возможно, с различными путями кода (#ifdef, Debug.Assert(), etc), код будет выполняться одинаково.

Немного страшно: установите точки останова, установите следующую строку кода, которую вы хотите выполнить, всплывающее окно с интерактивными исключениями и нестабильный запуск в Visual Studio. Существуют также опции отладчика, которые позволяют вам всегда останавливаться, исключение происходит. Даже проверка классов может привести к побочным эффектам, если вы не написали код должным образом ... Конечно, это не то, что я хотел бы сделать как обычный процесс 24x7.

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

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

Answer 10

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