Федеральное агентство по образованию. После устранения последствий инцидента и восстановления нормального функционирования бизнес-процессов компании

Федеральное агентство по образованию

 

Государственное образовательное учреждение высшего профессионального образования

«МАТИ»- Российский государственный технологический университет имени К. Э. Циолковского

 

Курсовая работа по предмету:

«Надежность, эргономика и качество АСОиУ»

На тему: «Управление инцидентами».

 

 

 

Выполнил студент: Кротов Алексей

Группа: 3АСУ-5ДС-168

 

 

Проверил _________________

 

Оценка __________________

 

Москва – 2012

В терминологии ITIL «Инцидент» определяется как:

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

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

Запрос на новую или дополнительную услугу (связанную с программным или аппаратным обеспечением) часто считается не Инцидентом, а Запросом на Изменение (Request for change, RFC). Тем не менее, практика показывает, что устранение отказов в инфраструктуре и обработка запросов на обслуживание осуществляются одинаковым образом. Поэтому они оба включены в определение и рамки процесса Управления инцидентами.

Схема процесса:

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

 

Статус Инцидента отражает его текущее положение в жизненном цикле, иногда называемое «позицией В диаграмме последовательности выполняемых действий». Каждый сотрудник должен знать все возможные статусы и их значения.

Несколько примеров категорий статусов:

• новый;

• принят;

• определены сроки;

• назначен/передан специалисту;

• в работе (Work In Progress, WIP);

• ожидание;

• разрешен;

• закрыт.

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

 

Приоритет Инцидента первоначально определяется его влиянием на бизнес и срочностью, с которой необходимо обеспечить разрешение или Обходное решение. Целевые показатели для разрешения Инцидентов или обработки запросов обычно включаются в SLA. На практике целевые показатели разрешения Инцидентов часто связаны с категориями.

Службе Service Desk отводится важная роль в процессе Управления инцидентами:

• обо всех Инцидентах сообщается в Службу Service Desk, и ее

сотрудники регистрируют Инциденты; в случаях, когда Инциденты

генерируются автоматически,процесс все равно должен включать

регистрацию через Службу Service Desk;

• основная масса Инцидентов (возможно, до 85% при высоком уровне

навыков персонала) будет разрешена Службой Service Desk;

• Служба Service Desk - «независимое» подразделение, которое наблюдает

за ходом разрешения всех зарегистрированных Инцидентов.

 

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

 

Инциденты, возникшие в результате отказов или ошибок вИТ-инфраструктуре, приводят к реальным или потенциальным отклонениям от запланированной работы ИТ-услуг.

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

Таким образом, мы имеем следующие определения:

• Проблема: неизвестная исходная причина одного и более Инцидентов.

• Известная ошибка: Проблема, которая успешно диагностирована и для которой известно Обходное решение.

• RFC: Запрос на Изменение любого компонента ИТ-инфраструктуры или любого аспекта ИТ-услуг.

 

Основные преимущества внедрения процесса “Управления инцидентами”,

следующие:

• Для бизнеса в целом:

• уменьшение влияния Инцидентов на бизнес из-за их своевременного разрешения и, как следствие, увеличение эффективности;
• упреждающая идентификация выгодных улучшений и изменений системы;
• доступность ориентированной на бизнес управленческой информации, связанной с SLA.

• Для ИТ-организации, в частности:

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

 

С другой стороны, отказ от внедрения процесса "Управления инцидентами может

привести к следующему:

• некому управлять и производить эскалацию Инцидентов следовательно, Инциденты могут стать более трудными для разрешения, чем могли бы быть, и отрицательно влиять на качество ИТ-услуг;

• специалисты службы поддержки постоянно отрываются на выполнение других задач, что снижает эффективность их работы;

• бизнес-персонал отрывается от основных занятий, т.к. коллеги обращаются друг к другу за советами;

• частое расследование Инцидентов с самого начала вместо обращения к решениям;

• нехватка согласованной управленческой информации;

• потерянные и неправильно или плохо управляемые Инциденты.