назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [ 20 ] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


20

5. VfMV.eAEHNE ГвРОБЛШДМИ

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

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

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

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

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

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

5.4. Виды деятельности 5.4.1. Контроль проблем

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

Информация от других процессов

-►

Идеьгтификация и регистрация

<-►

<-►

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

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

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

Проблемы

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



5. ynPABA£HNEiiii>OfeAEMAMM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



5. УПРАВЛЕНИЕ ПРОЕЛЕМА,*АИ

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

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

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

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

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

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

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

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

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

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

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

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

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [ 20 ] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]