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

Ответ 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% всех исправлений заканчиваются внедрением новых ошибок.
• Не давайте давления на ошибку быстрого исправления в производстве, чтобы вы могли отказаться от стандартных процедур контроля качества (например, обзоры кода).
• После исправления убедитесь, что вы написали автоматические тесты в случае, если ошибка вернется через некоторое время.