Выбрать главу

Для выяснения корневых причин возникновения как существующих, так и потенциальных ошибок в предоставлении услуг, в рамках Процесса Управления Проблемами производится изучение инфра­структуры и имеющихся регистрационных данных, включая базу данных инцидентов. Такие иссле­дования необходимы из-за сложного и распределенного характера инфраструктуры, когда связи ме­жду инцидентами не всегда бывают очевидными. Например, причиной проблемы могут стать сразу несколько ошибок, и в то же время несколько проблем могут быть связаны с одной и той же ошиб­кой. Вначале надо определить причину возникновения проблемы. После того, как корневая причина определена, проблема переходит в разряд известных ошибок и для устранения этой причины можно направить Запрос на Изменение[74]. Но даже после этого известные ошибки будут отслеживаться и контролироваться в рамках Процесса Управления Проблемами. Поэтому следует вести регистрацию всех идентифицированных известных ошибок, их симптомов и имеющихся решений.

5.1.1. Определение – "проблема" и "известная ошибка"

На рис 5.1 показаны взаимосвязи между проблемой, известной ошибкой и Запросом на Изменение и даны определения этих терминов.

Рис. 5.1. Отношения между проблемами и известными ошибками (источник OGC)

5.1.2. Взаимоотношения с Процессом Управления Инцидентами

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

На рис. 5.2 показаны отношения между инцидентами, проблемами, известными ошибками и изме­нениями.

Рис. 5.2. Отношения между Процессами Управления Инцидентами, Управления Проблемами и Управления Изменениями

5.2. Цель процесса

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

Управление Проблемами гарантирует, что:

? существующие и регулярно возникающие ошибки[76] идентифицированы, документированы и отслеживаются;

? симптомы ошибок, постоянные или временные решения документируются;

? подаются Запросы на Изменения с целью модификации инфраструктуры;

? предотвращается возникновение новых инцидентов;

? создаются отчеты о качестве инфраструктуры ИТ и самого процесса.

Управление Проблемами позволяет быстро улучшить качество услуг путем значительного сокраще­ния количества инцидентов и уменьшения рабочей нагрузки на ИТ-организацию. Некоторые из преимуществ данного процесса состоят в следующем:

? Улучшение качества ИТ-услуг и Управления – результат документирования ошибок и/или их устранения.

? Повышение производительности труда пользователей – за счет улучшения качества услуг.

? Повышение производительности труда персонала – наличие документированных решений проб­лем позволяет даже менее опытным участникам Процесса Управления Инцидентами разрешать инциденты быстрее и эффективнее.

? Улучшение репутации ИТ-услуг – в результате улучшения стабильности услуг заказчики с боль­шим желанием сотрудничают с ИТ-организацией в новых сферах бизнеса.

? Совершенствование знаний в области Управления, эффективное обучение – Процесс Управле­ния Проблемами позволяет хранить исторические данные[77], которые используются при определе­нии тенденций и помогают принять меры по предотвращению новых инцидентов. Исторические данные также можно использовать при проведении исследований и диагностирования, а также, при создании Запросов на Изменения.

? Улучшение регистрации инцидентов – Управление Проблемами вводит стандарты на регистра­цию и классификацию инцидентов с целью эффективного определения проблем и их симптомов. Это также помогает улучшить составление отчетов об инцидентах.

? Более высокая доля инцидентов, разрешенных на первой линии поддержки – поскольку Про­цесс Управления Проблемами разрабатывает решения для ликвидации инцидентов и проблем, а обходные решения можно найти в базе знаний, то первая линия поддержки с большим успехом сама разрешает инциденты.

5.3. Процесс

Входами для Процесса Управления Проблемами являются:

? детальные описания инцидентов;

? обходные решения, найденные Процессом Управления Инцидентами;

? детали конфигурации из Конфигурационной Базы Данных (CMDB);

? подробная информация от производителя используемых в инфраструктуре продуктах, включая известные ошибки в этих продуктах и технические детали;

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

Основными видами деятельности в рамках Процесса Управления Проблемами являются:

? контроль проблем: определение и исследование проблем;

? контроль ошибок: отслеживание известных ошибок и подача Запросов на Изменения (RFC);

? проактивное Управление Проблемами: предотвращение инцидентов путем совершенствования инфраструктуры;

? предоставление информации: отчеты по серьезным проблемам и достигнутым результатам.

Выходами процесса являются:

? известные ошибки;

? Запросы на Изменения (RFC);

? новые регистрационные данные о проблемах (обновленные с учетом информации о способах ре­шения и/или обходных решениях);

? закрытые после устранения причины проблемы регистрационные записи;

? информация для руководства.

Рис. 5.3. Управление Проблемами среди других процессов

5.3.1. Управление Инцидентами

Управление Инцидентами является важным партнером Процесса Управления Проблемами. Эффек­тивная регистрация инцидентов важна для успешного Управления Проблемами, так как эта инфор­мация используется при идентификации проблемы.

Управление Проблемами поддерживает Процесс Управление Инцидентами. Процесс Управления Проблемами изучает проблемы и, пока не будет найдено решение, Управлению Инцидентами пред­лагаются обходные решения для работы над инцидентом. После установления причины и определе­ния Известной ошибки, может быть предложено быстрое решение ("заплатка")[78], которое поможет предотвратить возникновение инцидентов на некоторое время или уменьшит их негативные послед­ствия. Управление Проблемами может подать Запрос на Изменение, который приведет к оконча­тельному решению.

Примечание. Обходные решения могут создаваться и в Процессе Управления Инцидентами, и в Про­цессе Управления Проблемами.

5.3.2. Управление Изменениями

Управление Изменениями отвечает за контролируемое проведение изменений, включая Запросы на Изменения для устранения проблем, предложенные Процессом Управления Проблемами. Управле­ние Изменениями несет ответственность за определение степени воздействия изменения и ресурсов, необходимых для его реализации, а также за планирование, согласование и оценку запрашиваемых изменений. Кроме того, Управление Изменениями информирует Процесс Управления Проблемами о ходе работ и о завершении корректирующих изменений. Оценка этим изменениям дается совмест­но с Процессом Управления Проблемами. Итогом работы является Анализ результатов внедрения[79], после которого в рамках подпроцесса Контроля ошибок может быть закрыта известная ошибка, а также относящиеся к ней (открытые) инциденты.

вернуться

74

Request for Change – RFC.

вернуться

75

Quick Fixes – быстрые исправления, быстрые решения или "заплатки", т.е решения, позволяющие быстро устранить инцидент, но не устраняющие ошибку.

вернуться

76

Long-term Errors.

вернуться

77

Historical Data.

вернуться

78

Quick Fix.

вернуться

79

Post Implementation Review – PIR.