ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

van Bon Jan

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

? Существует угроза срыва Уровня Услуг, согласованного с заказчиком (по показателям производи­тельности, мощности ИТ-средств, затрат и т. д.)

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

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

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

и понять, насколько они важны для предоставляемых услуг.

Такая оценка может базироваться на "болевом показателе" инцидентов, в котором учитываются:

? издержки, которые несет бизнес из-за инцидентов;

? количество инцидентов;

? количество пользователей и бизнес-процессов, затронутых инцидентами;

? время и затраты на разрешение инцидентов.

Классификация и назначение

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

Классификация проблемы включает в себя следующее:

? Категория: определение области, например, программное или аппаратное обеспечение;

? Степень воздействия на бизнес-процесс;

? Срочность: допустимая задержка в решении проблемы;

? Приоритет: показатель, объединяющий срочность, степень воздействия, риск и необходимые ре­сурсы;

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

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

Расследование и диагностика

Расследование и диагностика являются итеративными фазами процесса, они неоднократно повторя­ются, каждый раз приближаясь все ближе к намеченному результату. Часто делаются попытки вос­произвести инцидент в условиях тестирования. Для решения проблемы могут потребоваться допол­нительные знания, например, для анализа и диагностики проблемы можно привлечь специалистов из группы поддержки.

Проблемы возникают не только из-за программных или технических средств. Они могут быть вы­званы ошибками в документации, ошибками персонала или процедурными ошибками, такими как выпуск неправильной версии программного обеспечения. Поэтому желательно включать описания процедур в Конфигурационную Базу Данных и проводить контроль их версий. В то же время мно­гие ошибки связаны с компонентами ИТ-инфраструктуры.

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

Источники ошибок в других средах

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

продукты вместе с базами данных, содержащими информацию об имеющихся в продуктах известных ошибках.

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

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

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

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

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

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

80

Т.е. во время сопоставления новых инцидентов с известными ошибками. – Прим. ред.

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

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

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

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

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