Общая концепция обнаружения и устранения проблем (Problem Determination & Troubleshooting)

Для начала определимся с понятиями. В англоязычной технической литературе используются такие понятия как “Problem Determination“, что означает “определение, выявление проблем, неполадок” и “Troubleshooting“,  дословно “стрельба по неприятностям”, то есть “устранение проблем“. Однако сегодня “Troubleshooting” используется в более широком смысле и означает “поиск и устранение причин проблемы, неисправности”. То есть сегодня понятие “Troubleshooting” фактически включает в себя понятие “Problem Determination” и встречается более часто. Если попытаться сказать более точно, то Troubleshooting – это системный подход в выявлении и устранении причин проблемы.

Общая концепция обнаружения и устранения проблем

На самом высоком уровне стратегия troubleshooting выглядит следующим образом:

  1. Сбор информации о проблеме:
    • Какие симптомы у возникшей проблемы?
    • Где возникла проблемы?
    • Когда возникла проблема?
    • При каких условия возникла проблема?
    • Можно ли воссоздать проблему?
  2. Ликвидация возможных причин.
  3. Если выполнение пунктов 1 и 2 не помогло, то необходимо воссоздать проблему, после чего повторить шаг 2.
  4. Если выполнение предыдущих пунктов не помогло, то необходимо воспользоваться диагностическими инструментами в комбинации с предыдущими шагами.

Рассмотрим все этапы более детально.

Сбор информации о проблеме

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

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

Начинаем описывать проблему, при этом основной вопрос звучит так: “В чем заключается проблема?“. Этот общий вопрос можно разбить на несколько конкретных, помогающих более детально описать проблему:

  • Кто или что информирует о проблеме?
  • Какие возникают коды ошибок и сообщения?
  • Каким образом происходит “падение” системы? Например, “зацикливание” (loop), “подвисание” (hang), авария, снижение производительности (performance degradation) или некорректный результат?
Где возникла проблема?

Определение того, где возникла проблема не всегда является легким делом, однако это один из важнейших шагов в решении проблемы. Между компонентами, которые сообщают о проблеме, и неисправными компонентами может находиться множество технологических слоев. Сеть, диски, драйвера – это всего лишь несколько компонентов, которые необходимо рассмотреть в процессе исследования проблемы. Для локализации проблемы ответьте на следующие вопросы:

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

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

Когда возникла проблема?

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

  • Проблема случается в определенное время дня или ночи?
  • Как часто возникает проблема?
  • Какая последовательность событий ведет к тому моменту, когда возникает проблема?
  • Проблема возникает после изменений среды? (Например, установка обновлений, ПО или hardware)
При каких условия возникает проблема?

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

  • Проблема возникает когда выполняется какое-то определенное задание?
  • К возникновению проблемы приводит последовательность определенных действий?
  • Какие нибудь приложения “падают” (получают ошибки) в это же время?
Можно ли воссоздать проблему?

При сборе информации о возникшей проблеме, постарайтесь понять возможно ли воссоздать эту проблему. Если да то как это можно сделать? Ответ на этот вопрос определит дальнейший ход процессов поиска и устранения неисправностей.

Ликвидация возможных причин

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

Воссоздание проблемы

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

  • Можно ли воссоздать проблему в среде разработки или на тестовом полигоне?
  • Сталкиваются ли другие пользователи/приложения с такой же проблемой?
  • Можно ли воссоздать проблему выполнив команду, набор команд или запустив сбойное приложение?

Использование диагностических инструментов

Для глубокого анализа проблемы или состояния рассматриваемой среды используются специальные инструменты диагностики. Для основных источников информации о проблемах (dump, javacore, trace и т.п.) и для основных типов проблем (memory leaks, hangs, deadlocks и т.п.) существуют отдельные соответствующие инструменты. Основная их часть доступна через IBM Support Assistant в качестве дополнительных утилит для определенного продукта.

В этой статье была рассмотрена основная концепция обнаружения и устранения проблем. Детально рассмотрены вопросы, помогающие выявить и устранить причины неисправностей. Сегодня существует множество различных методик troubleshooting (например, линейный подход (linear) и метод деления пополам (half-splitting или Divide-and-Conquer Approach)) которые так или иначе связаны с базовой концепцией. Статья основана на материалах IBM Infocenter.

VN:F [1.9.22_1171]
Rating: 4.8/5 (5 votes cast)
Tagged with: , ,
Posted in WebSphere Application Server, Troubleshooting

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Language: