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

Дисциплины:






Компонент ITSM "Сопровождение услуг". Процесс ы сопровождения услуг. Взаимосвязь процессов



 

1.Управление инцидентами. Цель процесса. Составляющие процесса. Проблемы, с которыми можно столкнуться при внедрении и реализации процесса.

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

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

Процесс: •Прием и регистрация инцидента (Acceptance and Recording) — принимается сообщение и созда­ется запись об инциденте. •Классификация и начальная поддержка (Classification and Initial support) — присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т. п. Пользователю может быть предложено возможное решение, даже если оно только временное. • Приписка (или сопоставление Matching) - проверяется, не является ли инцидент уже извест­ным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути. •Расследование и диагностика (Investigation and Diagnosis) при отсутствии известного реше­ния производится исследование инцидента с целью как можно быстрее восстановить нормальную работу. • Решение и восстановление (Resolution and Recovery) - если решение найдено, то работа может быть восстановлена. Закрытие (Closure) - с пользователем связываются, чтобы он подтвердил согласие с предложен­ным решением, после чего инцидент может быть закрыт. • Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) — весь цикл обработ­ки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация. Проблемы. • Пользователи и ИТ-сиециалисты работают в обход процедур Управления Инцидентами — если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специа­листами, не следуя установленным процедурам, ИТ-организация не получит информацию о ре­ально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию. • Перегруженность инцидентами и откладывание «на потом» — при неожиданном росте количест­ва инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окон­чания ввода информации об инциденте от одного пользователя возникает необходимость обслу­живать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно и процедуры по распределению инцидентов по группам поддержки не будут выполняться должным образом. В результате решения получаются некачественными и рабочая нагрузка увели­чивается еще больше. • Эскалация. Слишком большое число эскалации может оказать отрицательное воздействие на рабо­ту специалистов, которые из-за этого отрываются от своей запланированной работы. • Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) — если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управле­ние Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.



 

2.Управление проблемами. Цель процесса. Составляющие процесса. Проблемы, с которыми можно столкнуться при внедрении и реализации процесса.

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

Известная ошибка – проблема, корневая причина которой уже установлена.

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

Процесс: Вход: детальное описание инцидента, обходные решения, найденные процессом управления инцидентами, детали конфигурации и тд.

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

Выход: известные ошибки, запросы на изменение, закрытые после устранения причины проблемы регистрационные записи, информация для руководства.

Проблемы

• Плохая связь между Процессами Управления Инцидентами и Управления Проблемами: В результате будет существовать меньше доступной информации об инфраструктуре и данных о предыстории проблем.

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

 

3.Управление изменениями. Цель процесса. Составляющие процесса. Проблемы, с которыми можно столкнуться при внедрении и реализации процесса.

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

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

Входы: запросы на изменения, информация из CMDB, информация из других процессов (мощностей, бюджете), планирование изменений.

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

Проблемы: возможны попытки проведения изменений в обход согласованных процедур.

4.Управление конфигурациями. Цель процесса. Составляющие процесса. Проблемы, с которыми можно столкнуться при внедрении и реализации процесса.

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

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

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

Конфигурационная база данных учетных элементов содержит: содержание Релиза, включая составные УЭ и их номера версий; составные УЭ и их номера версий в тестовой среде и среде эксплуатации; УЭ, затронутые (авторизованным) Изменением, проводимым в соответствии с графиком; все Запросы на Изменение (RFC), связанные с конкретным УЭ; УЭ, закупленные у конкретного поставщика в определенный период; история УЭ; оборудование и программное обеспечение, находящиеся в каком-либо офисе, например, для помощи при проведении аудита; УЭ, которые планируется модернизировать, заменить или вывести из эксплуатации; записи об Изменениях и Проблемах, связанных с УЭ; все УЭ, затронутые какой-либо Проблемой.

Проблемы

• Неправильно определен охват (границы) Конфигурационной Базы Данных или Уровень Детализации Конфигурационных Единиц.

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

• Влияние срочных изменений — всегда будут возникать ситуации, когда нужно срочно произве­сти изменение. Часто это происходит во внерабочее время. Если изменяемые Конфигурационные Единицы находятся под контролем Конфигурационной Базы Данных, то рекомендуется немед­ленно произвести запись результатов изменения в CMDB, но может возникнуть ситуация, когда отсутствует сотрудник, ответственный за эту задачу. В этом случае регистрацию изменений и об­новление CMDB необходимо будет сделать при первой возможности.

 

5.Управление релизами. Цель процесса. Составляющие процесса. Проблемы, с которыми можно столкнуться при внедрении и реализации процесса.

Цели процесса Управления релизами: планирование и надзор за успешным развертыванием программного обеспечения и связанного с ним аппаратного обеспечения; обеспечение того, что изменения в программном и аппаратном обеспечении отслеживаемы, безопасны и инсталлируются только правильные, авторизованные и протестированные версии; согласование точного содержимого Релиза и его плана развертывания во взаимодействии с Управлением изменениями; обеспечение безопасного хранения мастер-копий всего ПО в Библиотеке эталонного программного обеспечения (DSL) и обновления Конфигурационной базы данных учетных элементов (CMDB);

Действия процесса Управления релизами: политика и планирование Релизов; проектирование, сборка и конфигурирование Релизов; приемка Релизов;

планирование развертывания; всестороннее тестирование по установленным критериям приемки; подтверждение завершения Релиза для последующего внедрения; коммуникации, подготовка и обучение; аудит аппаратного и программного обеспечения до и после внедрения Изменений; инсталляция нового и модернизированного аппаратного обеспечения; хранение контролируемого ПО в централизованных и распределенных системах;

Проблемы:

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

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

В распределенной системе могут возникнуть трудности, если новые версии ПО или АО не будут инсталлированы и активированы вовремя в удаленных офисах.

Некоторые сотрудники (включая ИТ-руководство) могут считать процедуры Управления релизами неудобными и слишком дорогими. Тем не менее, они всегда обязательны к исполнению для того, чтобы продуктивно и эффективно справляться с Изменениями в ПО;

Недостаточная доступность ресурсов для тестирования приведет к уменьшению эффективности этих процедур или высокое количество вариантов конфигураций в среде эксплуатации может наложить ограничения на проведение полного тестирования;

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

Тестирование в одной части может пройти удовлетворительно, но в другой - дать сбой, например, из-за разных инфраструктур или значений параметров;

 

6.Служба Service Desk. Назначение. Связь с другими процессами ITSM

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

 

 





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