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

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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Logging,
Logging,
Logging,

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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