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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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