КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Учебный вопрос 2. Отношения процесса управления инцидентами с другими процессами
2.1. Управление Конфигурациями Конфигурационная База Данных (Configuration Management Database — CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). Например, Ø более эффективное распределение инцидентов по группам специалистов. На основе данных CMDB о том, кто является ответственным за компонент инфраструктуры (КЭ), Ø решение оперативных вопросов, например, перенаправление очереди печати или переключение пользователя на другой сервер. Ø информация об источнике ошибки за счет того, что при регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item — CI). 2.2. Управление Проблемами Ø Эффективное Управление Проблемами требует качественной регистрации инцидентов, что значительно облегчит поиск корневых причин. Ø С другой стороны, Управление Проблемами помогает Процессу Управления Инцидентами, предоставляя информацию о проблемах, известных ошибках, обходных решениях и быстрых исправлениях'. 2.3. Управление Изменениями Ø Инциденты могут быть решены путем внесения изменений, например, заменой монитора. Ø Управление Изменениями предоставляет Процессу Управления Инцидентами информацию о запланированных изменениях и их статусах. Ø Кроме того, изменения могут вызвать инциденты, если изменения произведены неправильно или содержат ошибки. Процесс Управления Изменениями получает информацию о них из Процесса Управления Инцидентами. 2.4. Управление Уровнем Услуг Ø Сотрудники, участвующие в Управлении Инцидентами должны хорошо знать SLA, чтобы использовать необходимую информацию при контактах с пользователями.
Ø Регистрационные данные об инцидентах требуются при составлении отчетов для проверки выполнения согласованного Уровня Услуг. 2.5. Управление Доступностью Ø Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах 2.6. Управление Мощностями Ø Процесс Управления Мощностями получает информацию об инцидентах, связанных с функционированием самих ИТ-систем, например, инцидентах, произошедших в связи с недостатком дискового пространства или медленной скоростью реакции и т. д. Ø В свою очередь, информация об этих инцидентах может поступать в Процесс Управления Инцидентами от системною администратора или от самой системы на основе мониторинга своего состояния.
3. Учебный вопрос 3. Схема процесса (основные стадии и задачи) 3.1. Входы процесса Инциденты могут возникнуть в любой части инфраструктуры: Ø Пользователи Ø Сотрудники других отделов Ø Автоматические системы управления, настроенные на регистрацию событии в приложениях и технической инфраструктуре.
3.2. Прием и регистрация инцидента (Acceptance and Recording) — принимается сообщение и создается запись об инциденте.
Инциденты могут быть обнаружены следующим образом: ü Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk. ü Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки. ü Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента. ü Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.
Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов. При регистрации инцидента производятся следующие действия: • Назначение номера инцидента: в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах. • Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах. • Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Вазы Данных — CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB). • Объявление сигнала тревоги: если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.
3.3. Классификация и начальная поддержка (Classification and Initial support) — присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т. п. Пользователю может быть предложено возможное решение, даже если оно только временное.
Категория Прежде всего, инцидентам присваивается категория и подкатегория, например, исходя из предполагаемого источника инцидента или соответствующей группы поддержки: • Центральная процессинговая система — подсистема доступа, центральный сервер, приложение. • Сеть — маршрутизаторы, сегменты, концентратор (hub), IP-адреса. • Рабочая станция — монитор, сетевая карта, дисковод, клавиатура. • Использование и функциональность — услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация. • Организация и процедуры — заказ, запрос, поддержка, оповещение (коммуникации). • Запрос на Обслуживание — запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.
Приоритет После этого назначается приоритет, чтобы быть уверенными, что группа поддержки уделит инциденту необходимое внимание. Приоритет — это номер, определяющийся срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не исправить быстро). Приоритет = Срочность х Степень воздействия. Услуги (сервисы) Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг — SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA. Группа поддержки. Ø Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Ø Основой для распределения (маршрутизации) инцидентов часто является информация о категориях.. Ø Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности' (KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений. Сроки решения С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе. Идентификационный номер инцидента Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях. Статус Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть: • новый; • принят; • запланирован; • назначен; • активный; • отложен; • разрешен; • закрыт. Ø Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура.
Дата добавления: 2014-01-11; Просмотров: 547; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |