Управление Инцидентами

ОБЩИЕ ПОЛОЖЕНИЯ

Данный документ определяет политику управления инцидентами в организации и является внутренним руководящим документом ИТ департамента. Документ должен соответствовать требованиям:

•Действующему законодательству и иными правовыми актам;

•Нормативной документацией Контролирующих органов;

•Уставу организации;

•Уставу ИТ департамента;

•Внутренним регламентирующими документами организации;

•Рекомендациям практик и стандартов, принятых в отрасли;

•Рекомендациям практик и стандартов, принятых в и сфере ИТ;

ЦЕЛИ ДОКУМЕНТА

Внесения ясность в организацию Управления ИТ Инцидентами в организации. Цели документа:

•Формирование принципов организации процесса;

•Повышение эффективности взаимодействия ИТ и бизнеса;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) – роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) – роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

•Инцидент – любое не запланированное снижение уровня предоставления сервиса.

•Значительный инцидент (major incident) – инцидент, имеющий высокий уровень воздействия (impact) на функционирование сервиса.

•Уровень воздействия (impact) – границы воздействия инцидента на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.

•Уровень срочности (urgency) – степень, определяющая срочность разрешения инцидента. Является составляющей, определяющей приоритет инцидента.

•Приоритет (priority) – определяет важность инцидента и порядок его разрешения.

•Обходное решение (work around) – действия, позволяющие временно или постоянно устранить инцидент или его причины.

•Эскалация – механизм, позволяющий своевременно устранить инцидент с помощью привлечения дополнительных ресурсов (горизонтальная) или более компетентного уровня знаний или полномочий (вертикального). Цель данного механизма устранить инцидент в рамках принятого соглашения об обслуживании.

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

Документ является высокоуровневым руководящим документом ИТ департамента и предназначен для ознакомления и соблюдения со стороны руководства структурных подразделений и сотрудников организации.

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ЦЕЛИ ПРОЦЕССА

Основные цели политики управления инцидентами:

•Своевременное реагирование на инциденты и скорейшее восстановление работы сервиса

•Формирование процесса управления инцидентами, определение процедур, стандартов и метрик.

•Обеспечение прозрачности функционирования ИТ департамента для бизнеса

•Снижение негативного влияния инцидентов на бизнес, путем своевременного и грамотного их устранения

•Рациональное использование ИТ ресурсов

•Повышения удовлетворенности бизнеса и сотрудников работой ИТ департамента

ЗАДАЧИ ПРОЦЕССА

Задачи ИТ департамента по управлению инцидентами можно определить, как следующие:

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

•Классификация инцидентов

•Классификация воздействия, срочности и приоритета

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

•Определение ролей и уровень вовлеченности сотрудников

•Организации деятельности по обнаружению и регистрации инцидента

•Организации деятельности по классификации и первоначальной поддержки

•Организации деятельности по расследованию и диагностики инцидента

•Организации деятельности по разрешению инцидента

•Организации деятельности по эскалации инцидента

•Организации деятельности по закрытию инцидента

•Организации деятельности по коммуникации в процессе управления инцидентами

•Организации деятельности по мониторингу и отчетности по работе процесса

•Организации деятельности по взаимодействию с другими процессами управления ИТ сервисами

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

ПРОЦЕСС УПРАВЛЕНИЯ ИНЦИДЕНТАМИ

Процесс управления инцидентами, представлен на диаграмме.

Диаграмма 1: блок схема управления инцидентами

Процесс управления инцидентами может быть разделен на следующие под-процессы:

•Обнаружение и регистрация инцидента

•Классификация и первоначальная поддержка

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

•Разрешение инцидента

•Эскалация инцидента

•Закрытие инцидента

Для построения эффективного процесса управления инцидентами необходимо наличие следующих входных данных:

•Наличие каталога сервисов, предоставляемых ИТ департаментом

•Определены каналы инициализации инцидента

•Наличие базовых и/или специфических соглашений по предоставлению услуг

•Определены группы поддержки

•Определены каналы обратной связи по информированию о статусе инцидента

•Определены ключевые атрибуты инцидента

•Определены метрики процесса

•Наличие компонентной базы ИТ инфраструктуры

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

•Процедуры управления инцидентами

•Инструменты для диагностики инцидентов

•Инструменты по разрешению инцидентов

•Инструменты для регистрации, мониторинга и управления инцидентами

При функционировании процесса управления инцидентами формируются следующие выходных данные:

•Запросы на обслуживание

•Запросы на изменения

•Регистрация проблем

•Записи по инцидентам

•База знаний по инцидентам

•Отчеты

•Сообщения

В процессе управления инцидентами определены следующие уровни поддержки:

•Уровень L0 – «нулевой» уровень поддержки, предоставляемый со стороны контакт центра отдела «Поддержки Пользователей» или самостоятельное разрешение инцидента сотрудником на основе имеющейся информации.

•Уровень L1 – «начальный» уровень поддержки, предоставляемый со стороны сотрудников отдела «Поддержки Пользователей».

•Уровень L2 – уровень поддержки «специалистов», предоставляемый со стороны сотрудников различных функциональных подразделений ИТ департамента. Является основным компонентов разрешения инцидентов и уровнем эскалации для отдела «Поддержки Пользователей»

•Уровень L3 – уровень «экспертной» поддержки, предоставляемый со стороны сотрудников различных функциональных подразделений ИТ департамента. Формируется из сотрудников ИТ департамента, обладающих экспертными знаниями в определенной области ИТ. Является основным компонентов разрешения инцидентов и уровнем эскалации для уровня поддержки L2.

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

Дополнительно в процессе управления инцидентами необходимо обладать информацией или настройками:

•Календарь

•Рабочее время

Под-процесс обнаружения и регистрации инцидента

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

Кроме этого, на начальном этапе необходимо определить тип обращения: инцидент, запрос на обслуживание или изменения, или информация.

В качестве основных каналов инициализации инцидента можно определить следующие типы:

•Регистрация инцидента по звонку пользователя

•Регистрация инцидента при непосредственном контакте с сотрудником

•Регистрация инцидента с использованием электронной почты

•Регистрация инцидента по средствам электронного портала средств управления ИТ сервисами

•Регистрация инцидента с использованием средств мониторинга ИТ инфраструктуры

Входная информация включает, но не ограничена следующими данными:

•Канал инициализации инцидента

•Контактная информация по пользователю

•Краткое название инцидента

•Детальная информация по инциденту

Выходная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

В качестве триггера используется:

•Неудовлетворенность пользователя качеством предоставляемого сервиса

Под-процесс классификации и определение приоритета инцидента

Следующий важный под-процесс жизненного цикла управления инцидентами. Правильная классификация и определение приоритета инцидента является значительным фактором при разрешении инцидента по срокам. Он позволяет перенаправить инцидент на правильную группу поддержки.

Определение приоритета является важным атрибутом для определения инцидента в очередь разрешения, а также обеспечения соответствия условиям об уровне соглашения.

В качестве классификации инцидента можно определить следующие типы и источники:

•Общие классы инцидентов (сеть, офисное оборудование, сервера и т п)

•Каталог ИТ сервисов и критичности сервисов

•Уровень соглашения по обслуживанию

Кроме этого необходимо определить дополнительные типы:

•Поддержка пользователей (End user support)

•Прочие и не классифицированные

Для определения приоритета необходимо определить воздействие и срочность инцидента. В качестве воздействия (impact) инцидента можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

Как альтернатива, может использоваться атрибут уровень тяжести (Severity) с теми же типами.

В качестве срочности выполнения (urgency) инцидента можно определить, как минимум следующие типы:

•Минимальное (Low)

•Среднее (Medium)

•Высокое (High)

Определение приоритета

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Связанные компоненты ИТ инфраструктуры

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Определённая группа поддержки

В качестве триггера используется:

•Наличие уникальной записи по инциденту

Под-процесс начального расследования инцидента

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

•Опрос по списку симптомов для определения источника инцидента или классификации (check list)

•Поиск в имеющихся «Часто Задаваемых Вопросах FAQ»

•Поиск в имеющейся базе данных знаний инцидентов (Knowledge Base)

•Предоставление решения или обходного действия пользователю для самостоятельного разрешения

•Применение решения оператором

•Назначение на группу поддержки, если решение не найдено или невозможно выполнить оператором

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Определённая группа поддержки

•Информация по разрешению инцидента

В качестве триггера используется:

•Наличие уникальной записи по инциденту

Под-процесс расследования и поиска решения по инциденту

Под-процесс полноценного расследования и поиска решения по инциденту является следующим этапом жизненного цикла управления инцидентами. На данном этапе инцидент переходит на технические уровни поддержки (L2-L3) организации или же передается внешней стороне (L4). Данный этап содержит такие действия, как:

•Назначение «Assign to ME» инцидента на конкретного исполнителя (Incident Resolver)

•Поиск и устранение инцидента

•Обращение за дополнительной информацией

•Эскалация инцидента как горизонтальная, так и вертикальная с привлечением внешней стороны (L4)

•Документирование

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Определённая группа поддержки

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Информация по разрешению инцидента

В качестве триггера используется:

•Наличие уникальной записи по инциденту

•Счетчик времени по устранению инцидента в соответствии с соглашением об уровне предоставления услуг

Под-процесс разрешения и закрытия инцидента

Под-процесс разрешения и закрытия инцидента является финальным этапом жизненного цикла управления инцидентами. При этом различается:

•разрешение инцидента – устранение инцидента сотрудником группы поддержки,

•закрытие инцидента – формальное подтверждение разрешения инцидента со стороны инициатора (пользователя или владельца сервиса).

•Реактивация инцидента – повторное активирование инцидента

Данный этап содержит такие действия, как:

•Разрешение инцидента

•Обновление информации по инциденту

•Документирование

•Закрытие инцидента

•Формирование запроса на изменения по необходимости

•Формирование проблемы по необходимости

•Создание или обновление базы знаний

•Реактивация инцидента

Входная информация включает, но не ограничена следующими данными:

•Уникальная запись по инциденту

•Классификация

•Приоритет инцидента

•Категория разрешения инцидента

•Статус инцидента

•Связанные компоненты ИТ инфраструктуры

•База знаний и т п

Выходная информация включает, но не ограничена следующими данными:

•Обновленная информация по инциденту

•Определённая группа поддержки

•Информация по разрешению инцидента (категория, время разрешения и т п)

В качестве триггера используется:

•Наличие уникальной записи по инциденту

•Счетчик времени по устранению инцидента в соответствии с соглашением об уровне предоставления услуг

Процесс управления инцидентами для уровня поддержки «Уровень L0»

Процесс управления инцидентами для уровня поддержки «Уровень L0» представлен на диаграмме.

Диаграмма 2: управления инцидентами в деталях для уровня L0

Данный уровне поддержки характеризуется следующими характеристиками:

•Непосредственный контакт с пользователем

•Определение типа обращения

•Регистрация инцидента

•Низким уровнем ИТ знаний

•Ориентирован на сбор информации по инциденту, определению симптомов, проверка первичных возможных решений и т п

•Разрешение инцидентов по средствам опросников, базы знаний и т п,

•Консультация сотрудников по процессу управления инцидентами, последовательности действий и т п

•Предоставление сотрудникам информации по разрешению инцидентов

•Мониторинг состояния инцидента, полноты информации, соответствия соглашению и т п

•Правильная классификация инцидента

•Назначение на правильную группу поддержки

Процесс управления инцидентами для уровня поддержки «Уровень L1/L2»

Процесс управления инцидентами для уровня поддержки «Уровень L1/L2» представлен на диаграмме:

Диаграмма 3: управление инцидентами в деталях для уровня L1—2

Данный уровне поддержки характеризуется следующими характеристиками:

•Непосредственный контакт с пользователем

•Определение типа обращения

•Регистрация инцидента

•Определённый уровень ИТ знаний

•Ориентирован на разрешение инцидента

Процесс управления инцидентами для уровня поддержки «Уровень L3/L4»

Процесс управления инцидентами для уровня поддержки «Уровень L3/L4» представлен на диаграмме:

Диаграмма 4: управление инцидентами в деталях для уровня L3—4

Данный уровне поддержки характеризуется следующими характеристиками:

•Реагирование на инциденты, уже зарегистрированные в системе

•Реагирование на инциденты, сгенерированные со стороны систем мониторинга сервиса

•Реагирование на инциденты, с признаком эскалация

•Ориентирован на разрешение инцидента

•Эскалация инцидента на высший (L4) уровень поддержки

•Разработка и обновление базы знаний и т п

МЕТРИКИ ПРОЦЕССА

Для обеспечения высокого уровня функционирования процесса управления инцидентами необходимо обеспечить мониторинг состояния следующих метрик и активности процесса:

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

•Разрешение инцидента при первом контакте

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли и ответственности:

Владелец сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по улучшению сопровождения

•Получение информации по инцидентам, относящимся к функционированию его сервиса

Менеджер сервиса

Цели:

•Восстановление и сопровождение сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с владельцем процесса по вопросам улучшения сопровождения сервиса

•Взаимодействие с владельцем сервиса по вопросам улучшения сопровождения сервиса

•Получение информации по инцидентам, относящимся к функционированию его сервиса

•Предоставление информации по инцидентам, относящимся к функционированию его сервиса

Оператор отдела «Поддержки Пользователей»

Отдел «Поддержки Пользователей»

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Обновление информации по инциденту

•Назначение или эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

Специалист поддержки (Incident Resolver)

Цели:

•Восстановление сервиса в рамках принятого соглашения

Ответственность:

•Взаимодействие с пользователями

•Классификация обращения пользователя

•Регистрация пользовательской информации

•Регистрация и классификация инцидентов и ключевых атрибутов

•Привязка компонентной базы, базы знаний, связанных инцидентов и т п

•Использование имеющихся инструментов или обходных методов для разрешения инцидента

•Назначение инцидента «на себя» из группы поддержки

•Обновление информации по инциденту

•Эскалация инцидента на соответствующую группу поддержки

•Предложение по улучшению процесса управления инцидентами

•Предложения по улучшению функционирования сервиса

•Инициирование запроса на изменения

•Регистрация проблемы по необходимости

•Написание и обновление базы знаний

Менеджер процесса управления инцидентами (Incident Manager)

Цели:

•Эффективное и результативное функционирование процесса управления инцидентами

•Обеспечение соответствия процесса требованиям ИТ архитектуры

•Повышение полноты и точности информации, вовлеченной в процесс

•Снижение количества инцидентов и времени их разрешения

Ответственность:

•Улучшение и оптимизация процесса

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

•Инициативы по продвижение процесса и вовлечения сотрудников организации

•Оперативное вмешательство в процесс для обеспечения соответствия требованиям

•Разработка и применение метрик и показателей процесса

•Анализ процесса и под-процессов

•Мониторинг и предоставление отчетности по работе процесса

•Предоставление отчетности по сервисам и связанными с ними инцидентам

•Оценка и предоставление отчетности по эффективности сотрудников, задействованных в процессе

•Взаимодействие с другими отделами и подразделениями по вопросам, связанным с процессом

Роли и ответственности сотрудников указаны в соответствующих должностных инструкциях.

Порядок взаимодействия процесса Управления Инцидентами

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

•Владелец процесса отвечает за организацию процесса, внесения изменений и дополнений.

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

ВЛИЯНИЕ ПРИ ОТСУТСТВИИ ПРОЦЕССА

Отсутствие процесса управления инцидентами может приводить к следующим негативным воздействиям:

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

•Хаотичный порядок реагирования сотрудников на инциденты;

•Отсутствие достоверной информации по функционированию ИТ;

•Не эффективное использование ИТ ресурсов;

РИСКИ ПРИ ВНЕДРЕНИИ И СОПРОВОЖДЕНИИ

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

•Отсутствие поддержки со стороны руководства организации;

•Отсутствие необходимого уровня культуры в организации;

•Отсутствие необходимых ресурсов;

•Нехватка знаний и навыков у сотрудников;

•Нехватка знаний и навыков у сотрудников ИТ департамента;

•Недостатки системы автоматизации процесса управления;

•Недостатки сопутствующей ИТ инфраструктуры;

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА

Ключевые факторы успеха при внедрении и сопровождении процесса управления инцидентами можно определить, как:

•Пристальное внимание к процессу;

•Реалистичные цели;

•Соответствие процессов бизнеса и управления инцидентами;

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

•Измеряемые показатели;

•Наличие актуальной и полной компонентной базы;

•Наличие актуальной и постоянно обновляемой базы знаний;

•Высокий уровень квалификации сотрудников ИТ департамента;

•Приемлемый уровень осведомленности сотрудников;

•Наличие инструментов диагностики и устранения инцидентов;

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности являются:

•Снижение количества ИТ инцидентов в организации;

•Повышение уровня доступности ИТ сервиса;

•Отсутствие претензий со стороны сотрудников организации;

•Отсутствие претензий со стороны контролирующих органов;

•Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•«Процедура управления инцидентами»;

•«Стандарты и метрики процесса управления инцидентами»;

•«Процедура регистрации пользователей»;

Контроль документа: [•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа: [•Версия документа: •Дата внесения изменений: •Автор: •Содержание изменений: ]

Данный текст является ознакомительным фрагментом.