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

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

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

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

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

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

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

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

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

• Логирование,
• Логирование,
• Логирование,

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

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

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

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

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

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

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

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