Понятие проблемы. Область ответственности процесса управления проблемами

Понятие проблемы. Область ответственности процесса управления проблемами.

1.1. Определения

Рис 1. Отношения между проблемами и известными ошибками (источник! OGC)

 

1.2. Цель УП – установление КОРНЕВОЙ ПРИЧИНЫ возникновения проблемы и как следствие – предотвращение инцидентов

Виды деятельности в рамках УП

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

Отношения процесса управления проблемами с другими процессами.

  2.1. Взаимодействие УП с процессом Управления инцидентами (УИнц) – УП… 2.2. Взаимодействие УП с процессом Управления изменениями:

Схема реактивного управления контролем проблем

Цель контроля проблем:

v преобразовать ПРОБЛЕМУ в ИЗВЕСТНУЮ ОШИБКУ путем диагностирования неизвестной причины ее возникновения.

v обеспечить Службу Service Desk информацией и рекомендациями об Обходных решениях для этой Проблемы, когда они станут доступны: Если Проблема определена для какого-либо Инцидента или группы Инцидентов, все доступные Обходные решения и временные решения записываются в запись о Проблеме в рамках контроля Проблем.

 

Действия, совершаемые в ходе контроля Проблем:

■ идентификация и запись Проблемы;

■ классификация Проблемы;

■ расследование и диагностика Проблемы.

 

 

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

В принципе, любой инцидент, возникший по неизвестной причине, может быть связан с проблемой (служить причиной ИДЕНТИФИКАЦИИ проблемы). На практике… v на этапе первичной поддержки и классификации Инцидента не удалось привязать… v имеют место повторяющиеся Инциденты;

Классификация проблемы

3.2.1. После определения Проблемы, необходимо установить объем усилий, требуемых для нахождения и восстановления вышедшего(их) из строя УЭ. Поэтому важно иметь представление о влиянии Проблемы на существующие уровни обслуживания. Этот процесс известен как «классификация».

3.2.2. Проблемы можно классифицировать по областям (категориям) – например:

v аппаратное обеспечение,

v программное обеспечение.

3.2.3. Классификация проблемы выпол­няется одновременно с анализом степени ее воздействия, т. е. уровня серьезности проблемы и ее влияния на услуги (срочность и степень влияния).

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

· Срочность - это степень задержки, которую можно допустить при разрешении Проблемы или ошибки; ее необходимо отличать от приоритета.

 

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

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

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

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

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

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

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

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

 

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

v наличие обходного решения или быстрого решения поможет снизить срочность про­блемы, в то время как

v новые инцидентымогут привести к усилению степени воздействия проблемы.

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

v Часто делаются попытки вос­произвести инцидент в условиях тестирования. Для решения проблемы могут потребоваться допол­нительные знания, например,… v Проблемы возникают не только из-за программных или технических средств. Они… v После того как установлена причина проблемы, определены Конфигурационные Единицы или груп­пы единиц, ее вызвавшие,…

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

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

Схема реактивного управления Контролем ОШИБОК.

Цель – контроля ошибок: Цель - изменить ИТ-компоненты для устранения Известных ошибок, влияющих на ИТ-инфраструктуру и, как следствие, предотвратить повторение Инцидентов. Контроль ошибок напрямую связан и действует совместно с процессами Управления изменениями путем подачи RFC и оценки внесенных изменений СС помощью PIR.

 

Схема контроля ошибок

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

v Статус Известной ошибки назначается, когда установлена корневая причина Проблемы и найдено Обходное решение. v Есть два источника данных об Известных ошибках, которые направляются в… v Ошибки, найденные во время работы, определяются и записываются в порядке расследования и диагностики - действий по…

ОЦЕНКА ОШИБОК

v Ошибки в продуктах внешних поставщиков. v Если в договоре или условиях лицензионного соглашения указаны показатели…

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

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

Анализ результатов внедрения (PIR)

Если изменение дало ожидаемый результат, проблема может быть закрыта.

Во многих организациях проблема закрывается только тогда, когда закрыты все связанные с ней инциденты (закрытие проверено заказчиком).

Отслеживание и монитоинг

Это – выполнение мониторинга хода работ по разрешению проблем и ликвидации Известных ошибок на все стадиях Контроля Проблем и Контроля ошибок. Цели:

v Фиксировать изменение степени влияния и срочности проблемы и корректировать на этом основании приоритет проблемы.

v Контроля ПРАВИЛЬНОСТИ исполнении RFC.

Проактивное управление проблемами.

Ø Анализе тенденций (например, случаи появления определенных типов проблем после проведения изменений). Необходимость, например рефакторинга,… Ø Изучении слабых и перегруженных компонентов инфраструктуры Ø Изучении повторяющихся проблем или Проблем с определенным УЭ.

Определения

· контролируется ИТ-организацией; · наличие и версия которого зарегистрированы. Конфигурационная база данных – совокупность СI и их связей.

Все расхождения свидетельствуют о том, что изменения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.

Критические факторы успеха, показатели эффективности и проблемы процесса

В отчет по процессу Управления Конфигурациями возможно включение следующей информации: ■ расхождения между регистрационными записями и реальной ситуацией,… ■ количество случаев, когда используется неавторизованная Конфигурация;

Шаг 1. Определение основных услуг, предоставляемых бизнесу.

· для каждой из них формулируется ответ на вопрос: «Что будет, если система прекратит работать на некоторое время?» Интервал времени можно задать… · Результат заносится в графу 3 таблицы 2 в виде названия процесса или услуги… · Далее заполняется графа 4 таблицы 2, куда вносится стоимость остановки предоставления соответствующей услуги на…

Шаг 2. Определение процессов, подлежащих оптимизации средствами CMS (системы управления конфигурациями).

· Кроме того, по каждому процессу необходимо зафиксировать куратора – человека, обладающего достаточными полномочиями, авторитетом и временем для… · Если мы затрудняемся указать куратора по процессу или не можем четко…

Отношения процесса управления Изменениями с другими процессами.

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

Понятие Релиза. Область ответственности процесса управления Релизами

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

Отношения процесса управления Изменениями с другими процессами

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