Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL Страница 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. Отчеты об Управлении и Ключевые показатели эффективности

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

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

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

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

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