Какова процедура отладки ошибки только для производства?

Question

Позвольте мне сказать заранее, что я настолько не осведомлен по этой теме, что даже не знаю, есть ли у этого вопроса объективные ответы или нет. Если это окажется «нет», я удалю или проголосую, чтобы закрыть сообщение.

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

Итак, какова процедура отслеживания проблемы, которая возникает только на производственных машинах? Существует ли для этого стандартная методология или, возможно, категория/семейство инструментов?

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

EDIT:
Ответ на этот вопрос до сих пор, кажется, резюмировать одним словом: лесозаготовок. Единственный вопрос, связанный с протоколированием, заключается в том, что он требует предусмотрительности. Что делать, если ситуация возникает в существующей системе с плохим протоколированием, или клиент обеспокоен конфиденциальными данными и не хочет, чтобы в первую очередь требовались обширные системы ведения журналов?

Некоторые смежные вопросы:
Test accounts and products in a production system
Running test on Production Code/Server

Answer 1

В дополнение к ведению журнала, что бесценно, вот некоторые другие методы, которые я и мои сотрудники использовали на протяжении многих лет ... возвращаясь к 16-битным окнам на клиентских машинах, к которым у нас не было доступа. (Я сам себе встречался?) Конечно, не все может/будет работать.

• Анализ всех видов поведения, которые вы видите.
• Воспроизведите, если это вообще возможно, воспроизведите его.
• Проверка стола, пройдите код, который вы подозреваете.
• Резиновая утка с членами команды И людьми, которые мало знакомы с кодом. Чем больше вы должны что-то объяснять кому-то, тем больше у вас шансов что-то выявить.
• Не расстраивайтесь. Пройдите 5-10 минутный перерыв. Прогуляйтесь по зданию/улице/независимо. Не думайте о проблеме за это время.
• Слушайте свои инстинкты.

Answer 2

Это один из самых сложных сценариев отладки. Ответ будет зависеть от деталей производственной системы. Это система, в которой вы полностью контролируете ее? Или он установлен на компьютере клиента, и вам нужно пройти через многочисленные телефонные звонки, чтобы получить доступ к файлу журнала или изменить параметр конфигурации?

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

Answer 3

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

Но будьте осторожны с тем, что ведение журнала может выявлять конфиденциальные личные данные, которые должны быть закодированы и/или пропущены, когда это возможно.

Answer 4

Как правило, «отладка» [то есть присоединение к процессу и проверка выполнения] нецелесообразна - по многим причинам не последним из которых является чувствительность к данным [например, разработчики редко квалифицируются \ очищаются для проверки данных, которыми мы управляем]

Таким образом, это обычно сводится к выводу о выполнении из вторичных источников и артефактов. Тогда это сводится к ...

• Logging,
• Logging,
• Logging,

Большая часть программного обеспечения, написанного в эти дни попадает в одну из Java или .Net лагеря, поэтому рычаги log4j и log4net соответственно.

Также имеет упрощенное руководство по настройке и валидации в Ops-centric. Помните, что люди, ответственные за оборудование и среду, редко понимают требования к конфигурации приложений, которые они размещают.

Answer 5

Наряду с протоколированием другие методы включают в себя сохранение данных запроса, которые вы затем можете подать в свою «идентичную» систему позже. Это может быть так же просто, как сохранить каждый HTTP-запрос, который вы получаете в файл для последующего анализа. В настоящий момент вы, вероятно, регистрируете большую часть этой информации (в частности, URL для GET), вам просто нужно добавить заголовки и запросить тела в микс.

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

Answer 6

Я бы начал с небольшой, простой проверки различий между производством и тестом. Удалите очевидные вещи, такие как разрешения, брандмауэры, разные версии и т. Д., Посредством фактического тестирования. Однажды я отрезал углы и скажу о, это не может быть, это так.

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

Answer 7

Некоторые советы:

• быть готовым, что ошибка может быть вызвана несколькими причинами, так что старайтесь не сужать свой ум в поисках только одной причины.
• Используйте необработанный обработчик ошибок, который будет отслеживать ошибки и суммировать подобные дефекты (greylog, ELMAH).
• Рассматривайте посмертную отладку с файлами мини-дампа.
• Установите фиксированные временные рамки для быстрого и грязного подхода, затем используйте системный подход.
• Попробуйте пересмотреть код пересмотренного модуля с одним из ваших коллег. Свежий вид может быть полезен.
• Разделите и победите, используя вашу систему контроля версий (GIT, SVN).
• Будьте осторожны с исправлениями, потому что около 4% всех исправлений заканчиваются внедрением новых ошибок.
• Не допускайте давления на ошибку при быстром устранении ошибок в производстве, чтобы вы могли опустить стандартные процедуры контроля качества (например, обзоры кода).
• После исправления убедитесь, что вы написали автоматизированные тесты в случае, если ошибка вернется через некоторое время.