Диагностика ИТ инцидентов и проблем

Сотрудников службы поддержки и остальной ИТ персонал нужно обучать техникам диагностики инцидентов и проблем, а также сопровождать их применение. Для результативного выполнения задач диагностики необходимы технические знания и навыки работы в ITSM-процессах.

[sendpulse-form id=”278″]

Диагностика ИТ инцидентов и проблем

В каждой ИТ организации есть процессы для управления инцидентами и проблемами. Часто они основаны на идеях из ITIL, чьи описания лучших практик управлениями ИТ услугами сейчас наиболее часто применяются в мире. В соответствии с ITIL, инцидент — это “незапланированное прерывание ИТ услуги или ухудшение ее качества…”, а проблема — это “любая причина, вызывающая один или более инцидентов…”. Цель управления инцидентами — восстановить плановое состояние услуги, а управление проблемами помогает уменьшить последствия от будущих инцидентов.

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

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

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

Рассмотрим полезные практики, которые помогут провести диагностику самостоятельно или лучше управлять теми кто ее делает.

Подходы для диагностики Инцидентов и Проблем

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

Подход Ричарда Фейнмана

Известный физик Ричард Фейнман предложил процесс решения физических проблем, который выглядит следующим образом:

  1. Описать задачу
  2. Очень сильно подумать
  3. Написать ответ

Этот метод прекрасен в своей простоте, но, возможно, он не будет работать у тех, кто не достаточно умён. Так что, я уверен, что это подход можно использовать, если Вы ОЧЕНЬ умный или работаете с простой задачей и имеете доступ ко всем знаниям и информации, которые только могут потребоваться. Стоит использовать этот подход в совокупности с другими, о которых будет рассказано ниже, но подумать прежде, чем делать выводы — всегда хорошая практика.

Анализ истории наблюдений

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

анализ истории наблюдений

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

Решение проблем по методу Кепнера-Трего

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

метод Кепнера-Трего

Диаграмма Ишикавы или скелет рыбы

Диаграмма Ишикавы — это путь постепенного уничтожения потенциальных причин проблем. Причины группируются по категориям и позволяют понять и визуализировать их взаимосвязи. Можно создать такие диаграммы для упрощения выявления всех потенциальных причин, вызывающих проблемы, в течении диагностики. А ещё они могут создаваться, как часть документации на продукт, что даёт возможность сразу их использовать в решении любых возникающих вопросов.

Диаграмма Ишикавы

Поддержка через Базу Знаний

Это в первую очередь методология для сбора и управления информацией, которая обеспечивает потребности ИТ персонала и сотрудников Service Desk. Если запрашиваемая информация становится доступной тому, кто в ней нуждается в требуемое им время, то это может привести к быстрому осознанию происходившего и быстрому решению инцидентов и проблем. А люди обладающие доступом к правильным знаниям с гораздо большей вероятностью смогут воспользоваться методом решения проблем методом Ричарда Фейнмана.

“Муравейник” (Swarming)

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

Подробнее о “муравейнике” можно почитать у Джона Холла

Как всегда + по случаю (Standard+Case)

Это ещё один подход, в котором заменены многие привычные аспекты управления инцидентами. Он был разработан Робом Ингландом (Rob England) и описан в этой статье. Основная идея подхода в том, что типовые активности должны управляться за счёт четко определенных процессов, а более редкие и сложные (комплексные) — требуют ситуационного управления, с применением техник, разработанных в таких областях, как здравоохранение, социальная сфера, законодательство и охрана порядка. Эта техника обладает высокой результативностью при управлении инцидентами и одновременно даёт возможность гибкого подхода к решению сложных (комплексных) инцидентов.

Заключение

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