Главная Обратная связь

Дисциплины:






Управление проблемами



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

Инцидент - это любое событие не являющееся частью нормального функционирования сервиса.

Цель процесса - как можно более быстрое восстановление сервиса.

Метрики процесса:

  • продолжительность инцидентов в соответствии с SLA
  • число зарегистрированных инцидентов

Владелец процесса - Incident Manager.

 

Процесс является реактивным по своей сути.

Деятельность по обеспечению процесса

  • Прием запросов (Accept calls)
  • Регистрация инцидентов (Log incidents)
  • Категоризация инцидентов (Categorize incidents)
  • Приоритизация инцидентов (Prioritize incidents)
  • Изоляция инцидентов (Isolate incidents)
  • Эскалация инцидентов (Escalate incidents (within the process and/or to management))
  • Отслеживание развития инцидента (Track incident progress)
  • Разрешение инцидентов (Resolve incidents)
  • Уведомление клиентов (Notify customers)
  • Закрытие инцидентов (Close incidents)

Деятельность по управлению качеством

  • Определение системы управления инцидентами (Establish incident control system)
  • Разработка управленческих отчетов (Develop management reports)
  • Непрерывное улучшение процесса (Perform continuous process improvement)

Важно понимать смысл понятия "Инцидент", инциденты и запросы на обслуживание - одно и то же или нет?


Во-первых, страницы ITIL, которые объясняют термин Запрос на обслуживание (Service Request), должны быть тщательно интерпретированы. Там утверждается, что Запросы на обслуживание управляются подобно Инцидентам, что - по моему опыту - абсолютно неверно (но может быть, я работал в плохой организации?). Поэтому я дам другое объяснение.
ServiceDesk получает обращения типов: Неудовлетворенность сервисом (Инцидент: "пожалуйста, выполняйте соглашение" или "восстановите сервис"), Изменения сервиса (мне нужно что-нибудь другое) и Запрос на обслуживание (мне нужно иное/больше чем в меню сервиса).
Запрос на обслуживание предопределен и согласован в SLA. Это значит, что если клиент запрашивает структурное изменение согласованных уровней сервиса, подобно изменению типовых часов предоставления сервиса, это НЕ является Запросом на обслуживание. Вместо этого, должен быть изменен SLA и должны быть внедрены структурно новые спецификации сервиса.
Примерами регулярных запросов на обслуживание могут быть:

  • Вопросы о функциональности
  • Запрос о статусе
  • Замена пароля
  • Запрос на пакетное задание и авторизацию пароля
  • Выборка из БД
  • Запрос на обеспечение нового сотрудника соответствующими ИТ сервисами

Запросы на обслуживание не могут обрабатываться, как Инцидент!

Управление проблемами



Проблема - это инцидент или группа инцидентов, имеющих общую неизвестную причину.

Цели процесса:

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

Процесс является проактивным по своей сути.

Владелец процесса - Problem Manager.

 

Деятельность по обеспечению процесса:

  • Анализ тенденций инцидентов (Analyze incident trends)
  • Регистрация проблем (Log problem)
  • Идентификация корневых причин инцидентов (Identify root cause)
  • Отслеживание изменений проблем (Track problem progress)
  • Выявление известных ошибок (Verify known errors)
  • Управление известными ошибками (Control known errors)
  • Решение проблем (Resolve problems)
  • Закрытие проблем (Close problems/known errors)

Деятельность по обеспечению процесса управления качеством:

  • Организация системы управления проблемами/известными ошибками (Establish problem/known error control system)
  • Управление ключевыми контактами (Setup and maintain support contacts)
  • Организация превентивных процедур поддержки (Establish preventive maintenance procedures)
  • Организация способов верификации известных ошибок (Establish known error verification facilities)
  • Организация интерфейса поддержки поставщиком (Establish supplier support interfaces)
  • Разработка отчетов для руководства (Develop management reports)
  • Постоянное усовершенствование процесса (Perform continuous process improvement)

Управление конфигурациями

Цель процесса - оказание помощи в управлении экономическим значением (economic value) ИТ - сервисов (комбинация требований клиентов, качества и затрат) за счет поддержания логической модели инфраструктуры ИТ и ИТ - сервисов, а также предоставление информации о них другим бизнес-процессам. Это реализуется путем идентификации. мониторинга, контроллинга и обеспечения информации о Конфигурационных Единицах (КЕ) и их версиях.

Владелец процесса - Change Manager.

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

 

Деятельность по обеспечению процесса:

  • Планирование: определение стратегии, правил и целей для реализации процесса, определение инструментария и ресурсов, определение интерфейсов с другими процессами, проектами, поставщиками и т.д.
  • Идентификация: Разработка модели данных для записи в базу конфигураций всех компонент инфраструктуры ИТ, отношений.между ними, а также информации о владельцах этих компонент, их статусе и соответствующей документации. Принципы идентификации вытекают из задач Управления сервисами. Например, если предъявляются требования к безопасности, то необходимо учитывать MAC- адрес. При выборе именования КЕ как правило рекомендуется, чтобы имя было логичным и неизменяемым. В качестве неудачного приводится пример имени персонального компьютера, которое включает в себя имя комнаты, где он находится: pcroom313. Для PC это может быть верно потому, что при переносе его в другую комнату, возникнет рассогласование с логикой построения. Либо имя менять, либо мириться с тем, что компьютер pcroom313 находится в комнате, например, 314. В то же время, для таких КЕ, как маршрутизатор, имя, отражающее местоположение разумно и рекомендуется Cisco: "We also recommend identifying DHCP ranges and adding them to the DNS, including the location of the users. This may be a portion of the IP address or a physical location. An example might be "dhcp-bldg-c21-10" to "dhcp-bldg-c21-253", which identifies IP addresses in building C, second floor, wiring closet 1." При возникновении инцидента имя маршрутизатора даст информацию необходимую для скорейшего восстановления сервиса.
  • Общие рекомендации по соглашениям именования:
    • наименования оборудования должны легко читаться и быть понимаемыми пользователями, бирки на нем должны быть надежно закреплены. Наименования должны быть согласованы с провайдерами, осуществляющими оутсорсинг и/или поставщиками третьих фирм.
    • документы, находящиеся под контролем процесса (SLA, процедуры, рабочие инструкции и пр.) должны содержать указание на КЕ (номер версии, дату и т.п.)
    • копии программного обеспечtния должны храниться в DSL - Definitive Software Library.

Очевидно, что при развитой инфраструктуре количество компонентов может быть очень велико и не все эти компоненты нужны для предоставления и поддержки сервисов. Поэтому необходимо определить "Сферу охвата (Scope)" и "Глубину детализации (Level of Detail)" для всего множества КЕ. Сфера охвата (Scope) определяет, какая часть инфраструктуры будет находиться под контролем процесса. Например, мы можем охватывать только сервера и маршрутизаторы. Правильный выбор Сферы охвата очень важен на начальном этапе внедрения процесса Управление конфигурациями. Глубина детализации (Level of Detail) - важный аспект, определяющий в дальнейшем отношения между КЕ.
Отношения, как правило рассматриваются следующие: физические ("родители - дети", "соединенная") и логические ("копия" и "использует", когда одна единица использует другую).

  • Контроль: Это означает, что процесс контролирует все изменения КЕ, кем бы они не производились (например процессами Change Management или Incident Management).
  • Мониторинг статуса: В процессе жизни статус КЕ может меняться от "заказано" до "исключено из конфигурации". Задача процесса отслеживать реальный статус КЕ, содержащихся в базе.
  • Верификация: Насколько информация в базе конфигураций соответствует реальности?
  • Отчеты: Отчеты руководству и другим процессам для осуществления их эффективного выполнения.

Возможные трудности при внедрении:

  • распределение ответственностей внутри организации;
  • выбор КЕ;
  • попытки обойти процедуры, установленные процессом;
  • трудности верификации.

Управление изменениями

Цель процесса – обеспечить проведение только одобренных изменений.

Владелец процесса – Change Manager.

 

Реализовать процесс с нуля невозможно, поэтому нужно рассматривать постепенную реализацию этого процесса.





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...