рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

ЛЕКЦИЯ № 4 по дисциплине «Управление эксплуатацией» ТЕМА «Введение в ITSM/ ITIL»

ЛЕКЦИЯ № 4 по дисциплине «Управление эксплуатацией» ТЕМА «Введение в ITSM/ ITIL» - раздел Менеджмент, Московский Государственный Университет Приборостроения И Информатики...

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ

 

Кафедра ЭФ-2 «Экономические информационные системы»

 

 

УТВЕРЖДАЮ

И.о. заведующего кафедрой ЭФ-2

_________ (Лагунова А.Д.)

«___»_________2011 г.

 

 

Для студентов 4 курса

факультета ЭФ направления 080801

к.т.н., доцент Ежов С.М.

(ученая степень, ученое звание, фамилия и инициалы автора)

 

ЛЕКЦИЯ № 4

 

по дисциплине «Управление эксплуатацией»

 

ТЕМА «Введение в ITSM/ ITIL»

 

Обсуждена на заседании кафедры

(предметно-методической секции)

«__»___________2012 г.

Протокол № __

 

МГУПИ – 2012 г.


Тема лекции: «Введение в ITSM/ ITIL»

Учебные и воспитательные цели:

Дать представление о библиотеке «лучших практик» ITIL и её альтернативы, разъяснить модель ITSM как основу ITIL.

Разъяснить процессный подход в стандарте ITIL.

Разъяснить процессы поддержки ИТ-сервисов

Разъяснить процессы предоставления ИТ-сервисов

Разъяснить соглашение об уровне сервиса

 

 

Время: 4 часа (180 минут).

 

Литература (основная и дополнительная):

1. ИТ сервис-менеджмент. Введение. itSMF. – М.: IT Expert, 2003

2. ITIL v2. Поддержка услуг. Перевод Компании «Ай-Теко», 2010.

3. А.И. Долженко. Управление информационными системами. Курс лекций. Ростов-на-Дону 2007

 

Учебно-материальное обеспечение: обычная аудитория

 

ПЛАН ЛЕКЦИИ:

Введение — до 5 мин.

Основная часть (учебные вопросы) — до 170 мин.

Учебный вопрос 1. Введение. Библиотека «лучших практик» ITIL и её альтернативы. Модель ITSM как основа ITIL. – 35 мин

Учебный вопрос 2. Процессный подход в стандарте ITIL – 35 мин

Учебный вопрос 3. Процессы поддержки ИТ-сервисов -45 мин

Учебный вопрос 4. Процессы предоставления ИТ-сервисов -45 мин

Учебный вопрос 5. Соглашение об уровне сервиса – 10 мин

 

 

Заключение — до 5 мин.


ТЕКСТ ЛЕКЦИИ.

 

Введение — до 5 мин.

Основная часть — до 170 мин.

Учебный вопрос 1. Введение. Библиотека «лучших практик» ITIL и её альтернативы. Модель ITSM как основа ITIL.

Библиотека ITIL(произносится как «айти́л», англ. IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. Появилась около 20 лет назад по заказу британского правительства. В настоящее время она издается британским правительственным агентством Office of Government Commerce и не является собственностью ни одной коммерческой компании (формально библиотека принадлежит королевскому дому Англии, в частности — нынешней королеве).

Альтернативы

Задача CobiT заключается в ликвидации разрыва между руководством компании с их видением бизнес-целей и IT-департаментом, осуществляющим поддержку… COBIT в первую очередь адресован аудиторам, и потому скорее делает акцент на… Microsoft Operations Framework (MOF) - пересказ ITIL в применении к продуктам от Microsoft

Процессы и организационные подразделения

Большинство компаний имеют иерархическую структуру. Они состоят из подразделений, объединя­ющих группы сотрудников. Существуют разные принципы формирования подразделений, например, но типу заказчика, продукту, региону или области знания.

Как правило, в предоставлении ИТ-услуг (сервисов) участвуют одновременно несколько отделов и затрагиваются несколько областей знаний (см. рис).

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

 

В части взаимодействия бизнес-подразделений и ИТ-департамента в процессной модели ITIL® можно выделить три уровня:

Ø операционный (взаимодействие с пользователями),

Ø тактический (взаимодействие с заказчиками) и

Ø стратегический (согласование целей бизнеса и ИТ).

 

Рис. дает представление не только о горизонтальных и вертикальных связях, но и о горизонте планирования процессов.

У согласования на стратегическом уровне горизонт планирования состав­ляет несколько лет. Управление Уровнем Услуг связано с Соглашениями на тактическом уровне, где горизонт планирования равен приблизительно одному году. Управление Изменениями, Управление Инцидентами и Служба Service Desk занимается оперативными вопросами с горизонтом планирова­ния в несколько месяцев, недель, дней или даже часов.

 

3. Учебный вопрос 3. Процессы поддержки ИТ-сервисов

3.1. Блок процессов поддержки ИТ-сервисов включает следующие процессы:

- управление инцидентами;

- управление проблемами;

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

- управление изменениями;

- управление релизами.

Процесс управления инцидентами предназначен для обеспечения быстро­го восстановление ИТ-сервиса.

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

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

Показателями качества реализа­ции процесса являются:

- временная продолжительность инцидентов;

- число зарегистрированных инцидентов.

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

- прием запросов пользователей;

- регистрация инцидентов;

- категоризация инцидентов;

- приоритизация инцидентов;

- отслеживание развития инцидента;

- разрешение инцидентов;

- уведомление клиентов;

- закрытие инцидентов.

Необходимым элементом обеспечения эффективного функционирования процесса является создание службы поддержки пользователей (Help Desk), еди­ной точки обращения по поводу различных ситуаций в ИТ-инфраструктуре, обработки и разрешении пользовательских запросов.

Следует отметить, что роль службы поддержки пользователей в последнее время возрастает, что от­ражается в её модифицированном названии - Service Desk.

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

На рис. 1 приведена диаграмма активности для процесса Управление инцидентами. Пользователь ИТ-сервиса обнаруживает нарушение режима пре­доставления сервиса и обращается в Service Desk ИТ-службы.

Сотрудник под­разделения Service Desk фиксирует в регистрационном журнале инцидент, классифицирует его, определяет приоритет и при возможности осуществляет начальную поддержку. Например, при невозможности для пользователя кор­ректно завершить транзакцию предлагается перезагрузить операционную сис­тему и повторно провести транзакцию.

Если начальной поддержки пользовате­лю достаточно и не требуется специализированная поддержка, то осуществля­ется закрытие инцидента.

Если необходимо специализированное обслуживание, то информация по инциденту передается в подразделение сопровождения ИТ- сервисов.

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

В этом случаеоперативный персонал реализует ранее документированную процедуру восста­новления ИТ-сервиса.

 

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

 

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

После закрытия инцидента для пользователя предоставляется возможность доступа к ИТ-сервису с требуе­мыми показателями качества. Момент закрытия инцидента фиксируется в жур­нале службы Service Desk.

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

Пробле́ма — в широком смысле сложный теоретический или практический вопрос, требующий изучения, разрешения. Неопределённостью проблема отличается от задачи.

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

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

- анализ тенденций инцидентов;

- регистрация проблем;

- идентификация корневых причин инцидентов;

- выявление известных ошибок;

- управление известными ошибками;

- решение проблем;

- закрытие проблем.

Проблема закрыта, когда выявлена известная ошибка и согласован порядок ее устранения.

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

На рис. 2 приведена диаграмма активности для процесса Управление проблемами.

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

Это реализуется путем идентификации, мониторин­га, контроллинга и обеспечения информации о конфигурационных единицах (CI - Configuration Item) и их версиях.

Конфигурационные единицы описывают системные компоненты с их конфигурационными атрибутами.

Рисунок 2 - Диаграмма активности процесса управления проблемами

 

Процесс Управление конфигурациями отвечает за поддержание инфор­мации о взаимоотношениях между CI и за стандартизацию CI, мониторинг ин­формации о статусе CI (от «заказана» до «списана»), их местоположении и всех изменениях CI.

Информация о CI хранится в базе данных конфигурационных единиц (Configuration Man­agement Data Base - CMDB).

База данных управления конфигурациями пред­ставляет собой репозиторий метаданных, описывающий элементы конфигура­ции, их взаимосвязи и атрибуты.

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

- материальными сущностями (серверная стойка, компьютер, мар­шрутизатор, модем, сегмент линии связи);

- системными или прикладными программными продуктами и ком­понентами;

- реализациями баз данных;

- файлами;

- потоками данных;

- нормативными или техническими документами;

- логическими или виртуальными сущностями (виртуальный сервер, серверный кластер, пул дисковой памяти, группа устройств);

- сотрудниками.

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

Атрибуты CI, как правило, отражают их специфические свойства и могут включать:

- идентификаторы;

- марки и названия моделей;

- серийные номера;

- сетевые адреса;

- технические характеристики;

- операционные характеристики.

Взаимосвязи CI представляют отношения, которые существуют или мо­гут возникнуть между двумя и более CI.

Как правило, язык спецификации мо­дели CMDB - XML.

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

- планирование - определение стратегии, правил и целей для реали­зации процесса, определение инструментария и ресурсов, опреде­ление интерфейсов с другими процессами, проектами, поставщика­ми;

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

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

- сфера охвата;

- глубина детализации;

Сфера охвата (Scope) определяет, какая часть инфраструктуры будет на­ходиться под контролем процесса. Например, можно охватывать только сервера и маршрутизаторы. Правильный выбор Сферы охвата очень важен на началь­ном этапе внедрения процесса Управление конфигурациями.

Глубина детализации (Level of Detail) - важный аспект, определяющий в дальнейшем отношения между CI и атрибутику CI.

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

· регистрацию всех существенные изменений в среде ИС предприятия,

· разрешает изменения,

· разрабатывает гра­фик работ по изменениям и

· организует взаимодействие ресурсов,

· оценивает воздействие изменения на среду ИС и связанные с ним риски.

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

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

Для этого каждое изменение конфигурации ИС орга­низации в обязательном порядке оформляется запросом на изменение.

Запрос на изменение проходит стандартную процедуру одобрения.

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

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

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

Рисунок 4 - Диаграмма активности процесса управления изменениями

 

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

- обрабатывает запросы на изменения;

- оценивает последствия изменений;

- утверждает изменения;

- разрабатывает график проведения изменений, включая восстанов­ление при сбое;

- устанавливает процедуру обработки запроса на изменение;

- устанавливает категории и приоритеты изменений;

- управляет проектами изменений.

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

В ос­тальных случаях изменение может быть принято.

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

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

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

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

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

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

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

Процесс управления релизами состоит из трёх этапов:

- разработка;

- тестирование;

- распространение и внедрение.

Этап разработки не является обязательным для всех предприятий (может быть передан на аутсорсинг).

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

Если процесс Управления релизами подготавливает реализацию приня­тых изменений, то необходимо определить, какой процесс ответственен за их непосредственное внедрение.

Внедрение срочных или не значительных изменений, процесс Управления релизами осуществляет сам.

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

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

- планирование релиза;

- проектирование, разработка, тестирование и конфигурирование ре­лиза;

- подписание релиза в развертывание;

- подготовка релиза и обучение пользователей;

- аудит оборудования до начала внедрения изменений

- размещение эталонных копий ПО в DSL;

Для оценки качества деятельности процесса важно тщательно выбирать метрики.

По масштабу релизы подразделяются на три вида:

- большой релиз ПО и/или обновление оборудования - обычно со­держит значительный объем новой функциональности;

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

- чрезвычайный релиз ПО и/или обновление оборудования — обычно содержит исправления некоторого числа известных ошибок.

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

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

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

- пакетный релиз включает в себя несколько различных полных или частичных релизов, которые распространяются и внедряются со­вместно для снижения общего числа релизов, что облегчает работу пользователей. Сами релизы могут разрабатываться и тестироваться отдельно и быть объединенными в пакет лишь на заключительных этапах.

Особой сферой ответственности процесса управления релизами является библиотека эталонного ПО (Definitive Software Library - DSL).

Все позиции DSL отражаются как записи CMDB. Эта библиотека — физическое хранилище протестированных и подготовленных к распространению копий разработанного и покупного ПО, лицензий на последнее, а также пользовательской и эксплуа­тационной документации.

4. Учебный вопрос 4. Процессы предоставления ИТ-сервисов

Блок процессов предоставления ИТ-сервисов в соответствии с ITIL включает следующие процессы:

- процесс управления уровнем сервиса;

- процесс управления мощностью;

- процесс управления доступностью;

- процесс управления непрерывностью;

- процесс управления финансами;

- процесс управления безопасностью.

Процесс управления уровнем сервиса (Service Level Management - SLM) определяет, согласовывает и контролирует параметры ИТ-сервиса (КАКИЕ?)

Ключевая роль менеджера процесса - осуществление баланса между требованиями бизнеса и возможно­стями ИТ.

На основе каталога ИТ-сервисов данный процесс разрабатывает, согласо­вывает и документирует соглашение об уровне сервиса (SLA - Service Level Agreement) между менеджментом ИС-службы и бизнес-пользователями.

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

- оценивает требования пользователей к ИТ-сервисам, распределяет их по существующим сервисам и определяет потребности в специа­лизированных сервисах;

- согласует и документирует SLA;

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

- определяет приоритетность сервисов;

- осуществляет управление версиями SLA;

- готовит планы повышения качества сервиса, направленные на по­вышение качества существующих сервисов, или включения в SLA новых сервисов;

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

Бизнес-пользователь формулирует требования к ИТ-услуге (устано­вить поддержку электронной почты в режиме 24 х 7).

Менеджер процесса управления уровнем сервиса совместно с менеджером процесса управления мощностями уточняет данные о дополнительной потребности в сотрудниках службы сопровождения, а также необходимые денежные ресурсы.

 

Рисунок 5 - Диаграмма активности процесса управления уровнем сервиса

 

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

Процесс управления мощностями (Capacity Management - CAP) предна­значен для оптимизации использования ресурсов ИТ-инфраструктуры в соот­ветствии с требованиями бизнеса к уровню обслуживания и тенденциями раз­вития инфраструктуры.

Основная задача этого процесса — обеспечение устойчивой работы ИТ- сервиса с требуемым уровнем производительности при максимально возмож­ных объемах обрабатываемых данных, оговоренных в SLA, как в текущий мо­мент, так и будущем.

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

· оптимизацию расходов,

· времени приобретения и размещения ИТ-ресурсов с целью обеспече­ния выполнения условий SLA.

Фунции:

· управление ре­сурсами, производительностью,

· моделирование, планирование мощностей,

· управление нагрузкой и

· определение необходимого объема техни­ческих средств для работы приложений.

· инвентаризация ИТ-ресурсы;

· картографирование загрузки ИТ-сервисов;

· анализ проблем;

· выдача рекомендации в отношении аутсорсинга (в области пропуск­ной способности);

· анализ производительности в условиях реальной загрузки;

Процесс управление мощностями позволяет анализировать и прогнози­ровать развитие ИТ-инфраструктуры предприятия за счет следующего:

- формирования в централизованном хранилище данных о произво­дительности ИТ-ресурсов для анализа тенденций, изменений по­требностей и планирования инвестиций в ИТ-инфраструктуру;

- моделирования и планирования сценариев оптимизации ИТ- инфраструктуры для определения требований к производительно­сти ИТ-ресурсов при изменениях и развитии бизнеса;

- автоматизации динамического перераспределения ИТ-мощностей;

- оценки возможностей виртуализации ИТ-ресурсов.

Процесс управления доступностью (НАДЕЖНОСТЬЮ) (Availability Management - AVM) контролирует способность службы ИТ обеспечить экономически эффективный и устойчивый уровень доступности ИТ-сервисов, удовлетворяющий требовани­ям бизнеса.

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

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

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

В тех случаях, когда требования бизнеса превышают возмож­ности службы ИС, управление доступностью обеспечивает предоставление бизнесу возможных альтернатив и связанных с ними затрат.

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

- инвентаризация ресурсов ИТ;

- определение узких мест ИТ-сервисов с точки зрения доступности;

- анализ доступности ИТ-сервисов, в том числе при отказе оборудо­вания, ПО, каналов связи и т.д.;

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

Возможный вариант диаграммы активности процесса управления дос­тупностью приведен на рис. 2.6.

На уровне процесса управления проблемами обнаружена известная ошибка. В рамках процесса управления доступностью сотрудник ИС-службы анализирует влияние компонентов ИТ-инфраструктуры на доступность различных сервисов и риск невыполнения SLA по этим серви­сам при возникновении ошибки. На основе анализа подготавливаются предло­жения по изменениям ИТ-инфраструктуре. Если предложения принимаются, то подготавливается график проведения изменений.

Процесс управления непрерывностью предоставления ИТ-сервисов (форс-мажор) (IT Service Continuity Management - ITSCM) обеспечивает выполнение требований к устойчивости предоставляемых сервисов, в первую очередь необходимых для функционирования критичных бизнес-процессов.

Рисунок 6 - Диаграмма активности процесса управления доступностью

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

В SLA должны быть зафиксированы требования к предоставлению сервисов в чрезвычайных ситуациях и ресур­сам для их обеспечения.

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

Такая поддержка означает:

· что инфраструктура и ИТ-услуги, в том числе услуги по поддержке (служ­ба Service Desk), должны быть восстановлены за заданный период времени по­сле возникновения чрезвычайной ситуации.

· на время восстановле­ния предоставление ИТ-услуг должно поддерживаться на «аварийном» уровне, приемлемом для ведения бизнеса, то есть на уровне, минимально необходимом для функционирования бизнеса.

Согласно ITIL процесс отвечает за решение следующих основных задач:

- оценка воздействия нарушений в предоставлении ИТ-услуг при возникновении чрезвычайной ситуации;

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

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

- определение общего подхода к восстановлению ИТ-услуги;

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

Процесс управления финансами ИТ-службы (Financial Management) от­слеживает фактические затраты в разрезе заказчиков, ИТ-сервисов и пользова­телей и на этой основе рассчитывает внутренние цены на услуги ИТ-службы.

Процесс взаимодействует с процессом управления уровнем сервиса для опреде­ления цен сервисов.

Основная цель процесса состоит в следующем:

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

- упорядочить поведение клиентов, предоставляя им информацию о действительной стоимости ИТ-сервисов;

- обеспечить возврат затрат на предоставление ИТ-сервисов.

Основная задача процесса управления затратами - расчет издержек, свя­занных с ИТ-сервисами, цен сервисов для бизнес-пользователей и поиск путей снижения затрат.

Функциями данного процесса являются:

- прогноз затрат и выручки (последняя определяется на основании внутренних цен на услуги);

- разработка бюджета сервисов;

- анализ использования сервисов и связанных с этим издержек, поиск путей их снижения;

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

- установление системы ценообразования и

- разработка системы выставления счетов за услуги;

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

Процесс управления безопасностью (Security Management) обеспечивает внедрение, контроль и техническую поддержку инфраструктуры безопасности, а также разработку и контроль соблюдения стандартов безопасности сущест­вующих, разрабатываемых и планируемых ИТ-сервисов. В ряде случаев он рас­сматривается вне рамок процессов предоставления ИТ-сервисов

Основная задача процесса управления безопасностью - планирование и мониторинг безопасности ИТ-сервисов.

Функции процесса управления безопасностью таковы:

- разработка корпоративной политики безопасности в части ИС, обеспечение необходимого уровня безопасности в этой области;

- анализ проблем безопасности и рисков в этой области;

- аудит безопасности и оценка инцидентов в этой области;

- установление процедур безопасности, включая защиту от вирусов;

- выбор систем и инструментов поддержания безопасности;

5. Учебный вопрос 5. Соглашение об уровне сервиса

Основным документом, регламентирующим взаимоотношения ИС- службы и бизнес-подразделений предприятия, является соглашение об уровне сервиса (Service Level Agreement - SLA). В данном документе дается качест­венное и количественное описание ИТ-сервисов, как с точки зрения службы ИС, так и с точки зрения бизнес-подразделений.

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

Типовая модель SLA должно включать следующие разделы:

- определение предоставляемого сервиса, стороны, вовлеченные в со­глашение, и сроки действия соглашения;

- доступность ИТ-сервиса;

- число и размещение пользователей и/или оборудования, исполь­зующих данный ИТ-сервис;

- описание процедуры отчетов о проблемах;

- описание процедуры запросов на изменение.

Спецификации целевых уровней качества сервиса, включая:

- средняя доступность, выраженная как среднее число сбоев на пери­од предоставления сервиса;

- минимальная доступность для каждого пользователя;

- среднее время отклика сервиса;

- максимальное время отклика для каждого пользователя;

- средняя пропускная способность;

- описания расчета приведенных выше метрик и частоты отчетов;

- описание платежей, связанных с сервисом;

- ответственности клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, про­граммного обеспечения или изменения только в соответствии с процедурой изменения);

- процедура разрешения споров, связанных с предоставлением серви­са.

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

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

- имя сервиса;

- ссылки на связанные сервисы;

- описание сервисов, функций, границ предоставления сервисов, профилей пользователей;

- поддерживаемые платформы или инфраструктуры;

- характеристики доступности, производительности;

- процедуры поддержки;

- метрики;

- процедуры мониторинга.

В операционной части приводят:

- имя владелец сервиса;

- профиль клиента;

- зависимости от других сервисов;

- модель Operations Level Agreement (OLA);

- детальная информация о технической инфраструктуре, необходи­мой для обеспечения сервиса;

- единицы инфраструктуры, рассматриваемые как активы;

- план поддержания целостности, улучшения качества сервисов, раз­вития возможностей;

- результаты аудита;

- информация о ценах.

SLA позволяет установить формализованные критерии оценки результа­тов деятельности ИС-службы, установить единообразные и обязательные для всех участников процесса процедуры оценки результатов деятельности ИС- службы.

Сервисный подход к управления ИС-службой требует определенной зре­лости как для самой ИС-службы, так и для бизнес-заказчиков. При этом следует учитывать ряд факторов:

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

- бизнес должен быть готов воспринимать некоторые «стандартные услуги» ИТ-службы как набор управляемых сервисов, выдвигать адекватные требования к уровню качества их предоставления, уча­ствовать в повышении их качества;

- обеспечение прозрачности ценообразования ИТ-сервисов, при ко­торой ИТ-служба должна обосновывать формирование цены ИТ- сервиса и возможные пути её снижения;

- наличие исключительных ситуаций, которые трудно предусмотреть заранее, процедуры выхода из них;

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

Следует отметить, что модель ITSM может применяться для предприятий с ИТ-службами различного размера: от 1 - 5 сотрудников до нескольких десят­ков сотрудников.

Для малых предприятий ролевой подход, принятый в ITSM, допускает совмещение одним и тем же сотрудником сколь угодно большого количества ролей в пределах его возможностей и компетенции. В предельном случае мо­дель ITSM может использовать ИС-служба, состоящая из одного человека. Ин­струментальные программные средства, которые используются для управления ИТ-инфраструктурой, могут варьироваться в широких пределах: от офисных пакетов, в простейшем случае, до специализированных инструментальных средств при большом размере ИС-службы.

В данной теме были рассмотрены методологические основы управления ИТ-инфраструктурой предприятия, базирующиеся на библиотеке передового опыта ITIL и модели ITSM. Для оперативных и стратегических процессов ИТ- службы проанализированы задачи и предложены диаграммы активности. Рас­смотрена роль соглашения об уровне сервиса для ИТ-службы предприятия.

Заключение — до 5 мин.

Содержание и методические рекомендации:

- обобщить наиболее важные, существенные вопросы лекции.

- сформулировать общие выводы.

- поставить задачи для самостоятельной работы.

- ответить на вопросы студентов.

Лекция разработана «___»________2011 г.

_______________________(Ежов С.М.)

(подпись, фамилия и инициалы автора)

 

– Конец работы –

Используемые теги: Лекция, дисциплине, управление, эксплуатацией, Тема, Введение, ITSM, ITIL0.103

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: ЛЕКЦИЯ № 4 по дисциплине «Управление эксплуатацией» ТЕМА «Введение в ITSM/ ITIL»

Что будем делать с полученным материалом:

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

Еще рефераты, курсовые, дипломные работы на эту тему:

ЛЕКЦИЯ–ВВЕДЕНИЕ Тема лекции: Введение в дисциплину Безопасность жизнедеятельности . Взаимодействие человека и окружающей среды
Тема лекции Введение в дисциплину Безопасность жизнедеятельности... Цель лекции изучить источники возникновения развитие науки Безопасность жизнедеятельности е исторические основы...

Тема лекции: «Введение в ITSM/ ITIL»
ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ... Кафедра ЭФ Экономические информационные системы...

Лекция № 1-2 Тема лекции: Введение. Основные понятия и законы химии
Тема лекции Введение Основные понятия и законы химии... План лекции Предмет задачи и методы химии...

Введение. Библиотека лучших практик ITIL и её альтернативы. Модель ITSM как основа ITIL
Библиотека ITIL произносится как айти л англ IT Infrastructure Library библиотека инфраструктуры информационных технологий библиотека... Процессы и организационные подразделения... Большинство компаний имеют иерархическую структуру Они состоят из подразделений объединя ющих группы сотрудников...

ТЕМА №1 ДОКУМЕНТОВЕДЕНИЕ КАК НАУЧНАЯ ДИСЦИПЛИНА Лекция №1 Документоведение как научная дисциплина
Дисциплина Документоведение предназначена для студентов обучающихся по специальности Организация и...

Лекции 1.ОСНОВНЫЕ ПОНЯТИЯ И КАТЕГОРИЯ ИНФОРМАТИКИ. 2 ЛЕКЦИИ 2. МАТЕМАТИЧЕСКИЕ ОСНОВЫ ИНФОРМАТИКИ. СИСТЕМЫ СЧИСЛЕНИЯ. 12 ЛЕКЦИЯ 3. АППАРАТНОЕ ОБЕСПЕЧЕНИЕ ЭВМ. 20 ЛЕКЦИЯ 4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КОМПЬЮТЕРОВ.. 49 Широко распространён также англоязычный вар
gl ОГЛАВЛЕНИЕ... Лекции ОСНОВНЫЕ ПОНЯТИЯ И КАТЕГОРИЯ ИНФОРМАТИКИ... ЛЕКЦИИ МАТЕМАТИЧЕСКИЕ ОСНОВЫ ИНФОРМАТИКИ СИСТЕМЫ СЧИСЛЕНИЯ...

ЛЕКЦИЯ № 1. Факторы выживания в природной среде ЛЕКЦИЯ № 2. Обеспечение водой ЛЕКЦИЯ № 3. Обеспечение питанием ЛЕКЦИИ по ОБЖ
КЛАСС Содержание Стр I четверть ЛЕКЦИЯ Факторы выживания в природной среде ЛЕКЦИЯ... ЛЕКЦИЯ Факторы выживания в природной... ЛЕКЦИЯ Обеспечение питанием...

Понятие управления. Виды управления. Управленческий труд и его особенности. МОДЕЛИ УПРАВЛЕНИЯ. ПОДХОДЫ К УПРАВЛЕНИЮ
Основатель Ф У Тейлор В г выпустил первую печатную работу которая... Основная идея используя замеры и наблюдения за работой исполнителей можно оптимизировать технологию выполнения работ...

Учебная программа курса. 4. Лекция 1. История психологии как наука. 5. Лекция 2. Античная философия и психология. 6. Лекция 3. Развитие психологии в Средневековый период. 19. Лекция 16. Тревога и защита
Введение... Учебная программа курса... Рабочая программа курса Лекция История психологии как наука...

Лекция первая. ИСТОРИЯ СОЦИОЛОГИИ КАК ОБЛАСТЬ ЗНАНИЯ Лекция вторая. ИЗ КАКИХ ИДЕЙ РОДИЛАСЬ СОЦИОЛОГИЯ: ИНТЕЛЛЕКТУАЛЬНЫЕ ИСТОКИ НОВОЙ НАУКИ Лекция третья. СОЦИОЛОГИЯ ОГЮСТА КОНТА ЛЕКЦИИ
Оглавление... ОТ АВТОРА... Лекция первая ИСТОРИЯ СОЦИОЛОГИИ КАК ОБЛАСТЬ ЗНАНИЯ Лекция вторая ИЗ КАКИХ ИДЕЙ РОДИЛАСЬ СОЦИОЛОГИЯ ИНТЕЛЛЕКТУАЛЬНЫЕ ИСТОКИ НОВОЙ НАУКИ...

0.037
Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • По категориям
  • По работам