Управление проблемами

Управление проблемами (Problem Management) - процесс, отвечающий за управление жизненным циклом всех проблем. Ключевыми целями Управления проблемами являются предотвращение инцидентов и

Д.А. Скрипник IT1L. ГГ Service Management по стандартам V3.1

минимизация влияния тех инцидентов, которые не могут быть предотвращены.

Проблема (Problem) - причина одного или нескольких инцидентов[1].

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

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

Также как и процессы Управления инцидентами и Управления изменениями, Управление проблемами предоставляет ценность для бизнеса тем, что повышает доступность и качество услуг. Если проблема, порождающая инцидент, решена, бизнес выиграет от уменьшения времени простоя услуг и уменьшения негативного влияния на бизнес-системы. Управление проблемами также уменьшает издержки бизнеса на разрешение инцидентов, так как непосредственно уменьшает их количество.

Управление проблемами состоит из двух подпроцессов:

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

Реактивный процесс управления проблемами изображен на рис. 13.1

Изменение

Рис. 13.1. Реактивное управление проблемами

Рассмотрим основные этапы Реактивного управления проблемами.

Первый этап - обнаружение проблемы. Существует множество путей обнаружения проблем, в частности:

  • • обнаружение или "подозрение" причины возникновения одного или более инцидентов от сервис-деска. Сервис-деск может разрешить инцидент, но не выявить его первопричину что увеличивает вероятность возникновения аналогичных инцидентов в дальнейшем. В этом случае формируется запись о проблеме для поиска основной причины инцидента;
  • • анализ инцидента технической группой поддержки, в результате которого будет выявлено существование проблемы или вероятность ее существования;
  • • автоматическое обнаружение сбоев приложений или компонентов инфраструктуры, которое выявит необходимость создания записи о проблеме;
  • • уведомление о существовании проблемы от поставщика или подрядчика;
  • • анализ инцидентов как часть проактивного управления инцидентами [17].

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

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

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

Для определения приоритета проблемы необходимо также оценить ее ’^тяжесть" или то, насколько она серьезна для инфраструктуры:

  • • систему можно восстановить или она должна быть заменена?
  • • сколько это будет стоить?
  • • сколько людей и какой квалификации необходимо для решения проблемы?
  • • сколько времени займет решение проблемы?
  • • насколько велик охват проблемы? ( например, сколько конфигурационных единиц она затрагивает)

На следующем этапе проводятся исследование и диагностика проблемы. Целью исследования является поиск первопричины проблемы. Для оценки точки сбоя и определения уровня негативного влияния может использоваться CMS. База известных ошибок может быть использована для поиска случаев возникновения проблемы в прошлом, и, возможно, ее решения.

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

  • • хронологический анализ. Когда возникает сложная проблема, могут появиться противоречивые отчеты и сообщения относительно того, что действительно случилось. Для восстановления картины документально фиксируют хронологию всех событий, связанных с проблемой. Это помогает также выяснить зависимости и устранить из цепочки события, которые не относятся к рассматриваемой проблеме.
  • • Анализ потерь (Pain Value Analysis) - методика, используемая для идентификации влияния на бизнес одной или нескольких проблем. Формула расчета потерь основана на количестве затронутых пользователей, продолжительности простоя, влияния на каждого пользователя, и стоимости для бизнеса (если известно).
  • • Анализ Кепнера и Трего - системный подход к разрешению проблем. Проблема анализируется в терминах Что, Где, Когда и Сколько. Определяются возможные причины. Наиболее вероятная причина подвергается проверке. Таким образом определяется истинная причина.
  • • "Мозговой штурм" - методика, которая помогает команде генерировать идеи. При этом идеи не должны критиковаться и анализироваться во время проведения самого Мозгового штурма, это происходит после.
  • • Диаграмма Ишикавы - методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма[1]. Основная проблема изображается в виде ствола диаграммы, главные факторы - как ветки, вторичные факторы - как соплодие и т.д. Создание диаграммы стимулирует обсуждение проблемы и более глубокое понимание ее сложности.
  • • анализ Парето - методика отделения значимых причин возникновения проблемы от незначимых. Должны быть предприняты следующие действия:
    • 1. сформировать таблицу, содержащую причины проблемы и их частоту в процентном соотношении от общего количества случаев возникновения проблемы;
    • 2. упорядочить строки таблицы в порядке увеличения важности причин;
    • 3. добавить столбец совокупного процента.

Более понятным анализ Парето будет на примере из публикации ITIL. В табл. 13.1 приведены 10 причин отказа сетевых взаимодействий, то есть "падения сети".

Таблица 13.1.

'Падение сети"

Процент от Совокупный

Д.А. Скрипник

ITIL. IT Service Management по стандартам V3.1

Причины

общего количества (%)

Расчет

Совокупный процент(%)

Сетевой контроллер

35

0+35

35

Порча файлов

26

35+26

61

Конфликт адресации

19

61+19

80

ОС Сервера

6

80+6

86

Ошибки скриптов

5

86+5

91

Непротестированное изменение

3

91+3

94

Ошибки оператора

2

94+2

96

Сбой резервного копирования

2

96+2

98

Попытки вторжения

1

98+1

99

Сбой дисков

1

99+1

100

Далее необходимо сделать следующие шаги:

  • 4. создать столбиковую диаграмму причин, расположенных в соответствии с их Процентом от общего количества ( 2 столбец);
  • 5. наложить линию суммарного процента (4 столбец).
  • 6. нарисовать линию от 80 % совокупного процента к оси у, параллельно оси х. В точке пересечения с линией суммарного процента ’^уронить" ее на ось х. Точка оси х, на которую "упадет" линия отделит значимые причины от незначимых.

Диаграмма рассматриваемого примера изображена на рис. 13.2.

Анализ Парето

Рис. 13.2. Анализ Парето

Следующий этап - поиск обходного решения. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение!!]. Например, перезапуск отказавшей конфигурационной единицы или ручное добавление поврежденного файла из резервной копии. Обходные решения являются временными решениями для поддержания работоспособности системы на время поиска решения проблемы. Обходные решения документируются в Базе известных ошибок. База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами. База известных

Д.А. Скрипник ITIL. ГГ Service Management по стандартам V3.1

ошибок это часть Системы управления знаний по услугам (SKMS) [1].

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

  • • что сделано правильно в отношении проблемы;
  • • что сделано неправильно в отношении проблемы;
  • • что может быть сделано лучше в будущем;
  • • как предотвратить повторение проблемы;
  • • были ли задействованы третьи стороны.

На практике редко встречаются приложения, системы и релизы программного обеспечения, не имеющие ошибок. В идеальном случае все они обнаруживаются на этапе тестирования. Тем не менее, ошибки могут не проявится или быть незамеченными и , таким образом, "просочиться" на этап эксплуатации.

Для оценки эффективности процесса Управления проблемами можно использовать следующие метрики:

  • • общее количество проблем, зафиксированных в определенный период;
  • • процент проблем, решенных в рамках, установленных SLA;
  • • количество проблем, решение которых вышло за рамки согласованных целевых показателей времени для решения проблем;
  • • количество нерешенных проблем;
  • • среднее время решения проблемы;
  • • количество значительных проблем;
  • • количество успешно завершенных пересмотров значительных проблем;
  • • количество известных ошибок, добавленных в Базу известных ошибок.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ   След >