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

5.3.3 Управление Конфигурациями

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

5.3.4. Управление Доступностью

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

5.3.5. Управление Мощностями

Управление Мощностями позволяет оптимизировать использование ИТ-ресурсов. Данный процесс предоставляет Управлению Проблемами важную информацию, которую можно использовать для определения проблем. Управление Проблемами оказывает поддержку Управлению Мощностями, устанавливая причины соответствующих проблем и устраняет их.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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