Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Сфера [ править ]

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

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

Ценность для бизнеса [ править ]

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

Действия, методы и приемы процесса [ править ]

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

  • Реактивное управление проблемами, которое обычно выполняется как часть работы службы.
  • Упреждающее управление проблемами, которое инициируется в процессе работы службы , но обычно осуществляется как часть постоянного улучшения обслуживания (CSI) .

Обнаружение проблемы [ править ]

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

Регистрация проблем [ править ]

Все соответствующие детали проблемы должны быть записаны, чтобы существовала полная историческая запись. Это должно быть отмечено датой и временем, чтобы обеспечить надлежащий контроль и эскалацию. Необходимо сделать перекрестную ссылку на инцидент (ы), инициировавший «Запись о проблеме»:

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

Приоритизация проблем [ править ]

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

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

Исследование и диагностика проблемы [ править ]

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

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

Value Analysis Pain содержит более полное представление о влиянии инцидента или проблемах в бизнесе. Вместо анализа количества инцидентов / проблем определенного типа в конкретном временном интервале метод фокусируется на глубоком анализе того, какой уровень боли был причинен бизнесу этими инцидентами / проблемами. Формула для расчета уровня боли должна учитывать:

  • количество пострадавших
  • продолжительность простоя, вызванного
  • стоимость для бизнеса

Метод Кепнера и Трегое используется для исследования более глубоких проблем. Они определили следующие этапы:

  • определение проблемы
  • описание проблемы с точки зрения личности, местоположения, времени (продолжительности) и размера (воздействия)
  • установление возможных причин
  • проверка наиболее вероятной причины
  • проверка истинной причины

Анализ Парето или диаграмма Парето - это метод отделения важных потенциальных причин от тривиальных проблем. Необходимо предпринять следующие шаги:

  1. Сформируйте таблицу, в которой перечислены причины и их частота в процентах.
  2. Расположите строки в порядке убывания важности причин (сначала самая важная причина).
  3. Добавьте в таблицу столбец с накопительным процентом
  4. Создайте гистограмму с причинами в порядке их процента от общего числа.
  5. Нарисуйте линию на 80% по оси Y, затем опустите линию в точке пересечения с осью X. На диаграмме вы можете увидеть основные причины сбоев в сети. Они должны быть нацелены в первую очередь.

Запись об известной ошибке [ править ]

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

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

Обзор основных проблем [ править ]

Хорошая практика - проверять все основные проблемы. Но это требует затрат. Обзор должен исследовать:

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

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

См. Также [ править ]

  • ISO / IEC 15504
  • Гарантия качества
  • Диагностика проблем RPR
  • Серая проблема
  • Парето анализ

Ссылки [ править ]

  • Новый Rational Manager - описывает решение проблем и принятие решений KT (PSDM)
  • Оффорд, Пол (2011). RPR: метод диагностики проблем для ИТ-специалистов . Эссекс, Англия: Advance Seven Limited. ISBN 978-1-4478-4443-3.