5.3.6. Управление Уровнем Услуг

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

5.4. Виды деятельности

5.4.1. Контроль проблем

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

Рис. 5.4. Контроль проблем (источник: OGC)

Идентификация и регистрация проблемы

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

Деятельность по "идентификации проблем" часто выполняют Координаторы проблем. Однако бы­вает так, что персонал, изначально не вовлеченный в эту работу, например, специалисты по Управле­нию Мощностями, тоже может выявлять проблемы. Такие "находки" также следует регистрировать как проблемы.

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

? Анализ инцидентов показывает, что некоторый инцидент повторяется, возникает большое количе­ство инцидентов или возникает негативная тенденция.

? Анализ инфраструктуры позволил определить ее слабые места, где могут произойти новые инци­денты (возможно, это проводилось средствами Процессов Управления Доступностью и Управле­ния Мощностями).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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