Ян Ван Бон - ИТ Сервис-менеджмент. Введение Страница 17

5.4.2. Контроль ошибок

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

Рис. 5.5. Контроль ошибок (источник: OGC)

Идентификация и регистрация ошибок

После определения причины проблемы и связанной с ней Конфигурационной Единицы, проблеме присваивается статус «Известной ошибки» и начинается деятельность по Контролю ошибок. Во многих случаях уже имеется обходное решение для проблемы, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в Процесс Управления Инцидентами, если там еще имеются открытые инциденты. Это обходное решение также можно использовать во время сопоставления инцидентов[80].

Поиск решения

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

Срочное исправление

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

Определение окончательного решения

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

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

После окончания этапа выбора существует достаточно информации для подачи Запроса на Изменение. Далее исправление известной ошибки будет произведено в рамках Процесса Управления Изменениями.

Анализ результатов внедрения[81] (PIR)

Изменение, предназначенное для устранения известной ошибки, должно быть рассмотрено при анализе результатов внедрения до закрытия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта, и в базе данных о проблемах ее статус будет изменен на статус «решена». Управление Инцидентами будет проинформировано об этом и инциденты, связанные с этой проблемой, тоже могут быть закрыты.

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

Отслеживание и мониторинг

Данная задача предполагает выполнение мониторинга хода работ по разрешению проблем и известных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следующем:

• Определить, изменилась ли степень влияния или срочность проблемы, и на основании этого производить корректировку приоритета проблемы.

• Вести мониторинг процесса выработки и реализации решения и контролировать правильность исполнения Запроса на Изменение. По этой причине Управление Изменениями регулярно передает информацию о состоянии Запросов на Изменение в Контроль ошибок.

Предоставление информации

В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление Инцидентами. Пользователи также могут информироваться об этом. Хотя данные предоставляет Процесс Управления Проблемами, их распространением занимается Служба Service Desk. Управление Проблемами использует Конфигурационную Базу Данных, а также Соглашения об Уровне Услуг, для уточнения, какую информацию и кому следует предоставлять.

5.4.3. Проактивное Управление Проблемами

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

5.5. Управление Процессом

5.5.1. Отчеты об Управлении и Ключевые показатели эффективности

Успешное Управление Проблемами проявляется в:

• сокращении количества инцидентов в результате разрешения проблем;

• сокращении времени, требуемом для разрешения проблем;

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

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

Отчеты об Управлении Проблемами могут быть достаточно объемными и охватывать следующие аспекты:

• Отчеты о времени исполнения: разделенные на Контроль проблем, Контроль ошибок и проактивное Управление Проблемами, а также разделенные между группой поддержки и поставщиком.

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

• Эффективность[82] Процесса Управления Проблемами: точное количество инцидентов до и после решения проблемы, зарегистрированные проблемы, количество поданных Запросов на Изменения и решенных известных ошибок.

• Баланс между реактивным и проактивным Управлением Проблемами: увеличение объема проактивного Управления Проблемами по сравнению с простым реагированием на инциденты свидетельствует о большей зрелости процесса.

• Качество разработанных продуктов: продукты, переданные от разработчиков, должны иметь высокое качество, иначе они могут создать новые проблемы. Для мониторинга качества важны отчеты о новых продуктах и имеющихся в них известных ошибках.

• Статус и план работ по открытым проблемам: итоговый отчет о том, что было сделано и что будет сделано для разрешения наиболее серьезных проблем, включая запланированные Запросы на Изменения, необходимое время и ресурсы.

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

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