ИТ Сервис-менеджмент. Введение
Шрифт:
Рис. 5.5. Контроль ошибок (источник: OGC)
Идентификация и регистрация ошибок
После определения причины проблемы и связанной с ней Конфигурационной Единицы, проблеме присваивается статус «Известной ошибки» и начинается деятельность по Контролю ошибок. Во многих случаях уже имеется обходное решение для проблемы, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать
80
Т.е. во время сопоставления новых инцидентов с известными ошибками. – Прим. ред.
Поиск решения
Персонал, участвующий в Управлении Проблемами, определяет, что необходимо сделать для разрешения известной ошибки. Специалисты сравнивают различные решения, принимая во внимание Соглашения об Уровне Услуг (SLA), возможные издержки и выгоды. Они определяют степень влияния и срочность Запросов на Изменения. Все работы по выработке решения должны быть зафиксированы в системе, у персонала должны быть средства для мониторинга проблем и определения их статуса.
Срочное исправление
Во время работы может потребоваться разрешение на выполнение срочного исправления, если известная ошибка ведет к возникновению серьезных инцидентов. Если для выполнения экстренного или быстрого исправления нужно модифицировать инфраструктуру, то вначале следует подать Запрос на Изменение. Если ситуация очень серьезная и задержка решения недопустима, то приводится в действие процедура проведения срочных изменений.
Определение окончательного решения
На предыдущих этапах происходит выбор оптимального решения. Однако может быть принято решение не исправлять известную ошибку, например, по причине экономической нецелесообразности.
Например, компания, у которой есть проблемы с собственными разработками системы ERP, приостанавливает любые исправления кодов существующей системы, так как принято стратегическое решение о переходе на SAP к концу года. В этом и других аналогичных случаях полученные преимущества не перевешивают затраты на исправления. Или же в другом случае степень воздействия ошибки может оказаться приемлемой, инцидент может оказаться легким для исправления или же вероятность его повторения невысока. В некоторых случаях исправление известной ошибки вообще невозможно без приложения усилий, несоразмерных проблеме. Но какое бы решение не было принято, оно должно быть отражено в системе, чтобы его можно было использовать в Процессе Управления Инцидентами.
После окончания этапа выбора существует достаточно информации для подачи Запроса на Изменение. Далее исправление известной ошибки будет произведено в рамках Процесса Управления Изменениями.
Анализ результатов внедрения [81] (PIR)
Изменение, предназначенное для устранения известной ошибки, должно быть рассмотрено при анализе результатов внедрения до закрытия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта, и в базе данных о проблемах ее статус будет изменен на статус «решена». Управление Инцидентами
81
Post Implementation Review – PIR.
Примечание: Во многих организациях процесс реализован таким образом, что проблема закрывается только после того, как будут закрыты связанные с ней инциденты (и закрытие проверено заказчиком), иначе если инциденты не удается закрыть, то проблему будет необходимо открывать снова.
Отслеживание и мониторинг
Данная задача предполагает выполнение мониторинга хода работ по разрешению проблем и известных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следующем:
• Определить, изменилась ли степень влияния или срочность проблемы, и на основании этого производить корректировку приоритета проблемы.
• Вести мониторинг процесса выработки и реализации решения и контролировать правильность исполнения Запроса на Изменение. По этой причине Управление Изменениями регулярно передает информацию о состоянии Запросов на Изменение в Контроль ошибок.
Предоставление информации
В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление Инцидентами. Пользователи также могут информироваться об этом. Хотя данные предоставляет Процесс Управления Проблемами, их распространением занимается Служба Service Desk. Управление Проблемами использует Конфигурационную Базу Данных, а также Соглашения об Уровне Услуг, для уточнения, какую информацию и кому следует предоставлять.
5.4.3. Проактивное Управление Проблемами
Проактивное Управление Проблемами (т. е. предупреждающее появление проблемы) имеет дело с вопросами качества инфраструктуры. Оно сосредоточено на анализе тенденций и выявлении потенциальных угроз инцидентов до того, как они произойдут. Это достигается путем изучения слабых и перегруженных компонентов инфраструктуры. Если таких областей несколько, тогда делается попытка предотвращения появления в них ошибок, которые наблюдались в других местах. Слабые места инфраструктуры должны быть выявлены и изучены.
5.5. Управление Процессом
5.5.1. Отчеты об Управлении и Ключевые показатели эффективности
Успешное Управление Проблемами проявляется в:
• сокращении количества инцидентов в результате разрешения проблем;
• сокращении времени, требуемом для разрешения проблем;
• уменьшении других затрат, связанных с разрешением проблем.
Параметры процесса также могут быть включены в отчеты для внутренних целей Управления, для оценки и контроля эффективности Управления Проблемами.
Отчеты об Управлении Проблемами могут быть достаточно объемными и охватывать следующие аспекты:
• Отчеты о времени исполнения: разделенные на Контроль проблем, Контроль ошибок и проактивное Управление Проблемами, а также разделенные между группой поддержки и поставщиком.
• Качество продукта: детальная информация об инциденте, проблеме и известной ошибке может помочь выявлению продуктов, подверженных частым ошибкам, и установлению, могут ли поставщики в этом плане принять на себя соответствующие контрактные обязательства.