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

Question

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

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

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

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

РЕДАКТИРОВАТЬ:
Ответ на этот вопрос, как представляется, суммируется одним словом: logging .Единственная проблема, связанная с ведением журнала, заключается в том, что для этого требуется предусмотрительность.Что если возникнет ситуация в существующей системе с плохим ведением журнала, или клиент обеспокоен конфиденциальными данными и не хочет, прежде всего, расширенных систем ведения журнала в системе?

Некоторые связанные вопросы:
Проверка учетных записей и продуктов в производственной системе
Выполнение теста на производственном коде / сервере

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

• Ведение журнала,
• Ведение журнала,
• Ведение журнала,

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

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

Answer 5

Несколько советов:

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

Answer 6

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

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

Answer 7

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

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