Обзор устранения неполадок в средах IBM BPM on Cloud

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

Первый шаг в процессе устранения неполадки - это полное описание проблемы. Без этого описания ни пользователь, ни IBM® не поймет, с чего начинать поиск причины неполадки. Этот шаг включает самостоятельный поиск ответов на базовые вопросы, такие как:

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

Симптомы неполадки

В начале описания неполадки самым очевидным вопросом является Что произошло? Он может показаться прямым вопросом, но его можно разделить на несколько уточняющих вопросов, дающих более полную картину неполадки. Эти вопросы могут быть следующими:
  • Кто (или что) сообщил о неполадке?
  • Какие выведены сообщения и коды ошибки?
  • Как проявляется сбой системы? Например, вход в бесконечный цикл, подвисание, блокировка, падение производительности или неправильные результаты?
  • Как неполадка влияет на бизнес?

Место возникновения неполадки

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

Помните, что если какой-либо уровень вывел сообщение о неполадке, то источником этой неполадки не обязательно будет этот уровень. Определение места происхождения неполадки даст понимание среды, в которой эта неполадка существует. Уделите время полному описанию среды с неполадкой. Следующие вопросы могут помочь в определении места происхождения неполадки:
  • Если существует несколько экземпляров IBM BPM on Cloud, какие экземпляры затронуты?
  • Какие рабочие среды затронуты, например Разработка, Тестирование или Выполнение процессов?
  • Какие приложения затронуты?
  • Какие службы вызывались приложениями, их версии и сведения об аппаратном обеспечении?

Время возникновения неполадки

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

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

Ответ на эти вопросы может предоставить систему координат для изучения неполадки.

Условия происхождения неполадки

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

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

Возможность воспроизведения неполадки

С точки зрения устранения неполадок идеальная неполадка - это неполадка, которую можно воспроизвести. Как правило для исследования таких неполадок существует большое число утилит и процедур. Таким образом, неполадки, которые можно воспроизвести, часто бывает проще отладить и устранить. Однако, таким неполадкам может быть присущ недостаток: при значительном влиянии неполадки на бизнес ее не хочется повторять. Если возможно, создайте неполадку повторно в тестовой среде или среде разработки, которая является обычно более гибкой и управляемой в процессе исследования.
Совет: Упростите сценарий для локализации неполадки в подозрительном компоненте.
При воспроизведении неполадки могут потребоваться ответы на следующие вопросы:
  • Можно ли воспроизвести неполадку в другой рабочей среде IBM BPM on Cloud? Например, если неполадка произошла в среде разработки, произойдет ли она также и в тестовой среде?
  • Происходит ли неполадка этого типа у других пользователей и в других приложениях?