| Печать |

Введение в ITIL

С сайта http://krylov.lib.ru

ITIL – это Библиотека Инфраструктуры Информационных Технологий. ITIL первоначально была набором примерно 60 книг, созданным в конце 1980-х CCTA (Central Communications and Telecom Agency) правительства Объединённого Королевства из совокупности передового опыта для IT. Для накопления передового опыта и обмена им создан форум ITSM Forum (www.itsmf.com) В настоящее время ITIL становится стандартом де-факто для ИТ.

По рекомендациям ITIL деятельность по обеспечению сервисов представляется в виде процессов.

Процесс - это последовательность шагов, направленная на достижение определенной цели или результата.

Каждый процесс должен иметь собственника (владельца) этого процесса
Владелец процесса - это физическое лицо отвечающее за сквозное выполнение процесса.

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

В соответствии с рекомендациями ITIL управление ИТ должно осуществляться следующими процессами(см. таблицу ниже):

 

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

В этом случае повышается статус ИТ, за счет осведомленности о реальных стоимостях предоставляемых сервисов.

С другой стороны растет заинтересованность ИТ в повышении качества предоставляемых сервисов, так как они находятся в условиях постоянной конкуренции со сторонними организациями. Однако следует понимать, что реализация этих правильных методов в организации возможна лишь при достижении ею достаточного уровня зрелости. Внедрение новых принципов управления потребует определенных усилий. Возможны различные причины неудач во внедрении проектов (в том числе и ITIL), но достаточно типовые причины следующие... Так или иначе, но для улучшения работы ИТ организация должна повысить уровень зрелости.

Service Management

Сервис – это то, что определено в Соглашении об уровне сервиса( SLA )

Цель – Обеспечение эффективного по затратам сервиса, при заданных в SLA качественных и количественных характеристиках.

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

Фокус процесса лежит на обеспечении уровня сервиса с точки зрения бизнеса, а не с точки зрения ИТ. Ключевая роль Service Level Manager создается для осуществления баланса между требованиями бизнеса и возможностями ИТ.

Что должен делать Service Manager

Рассматривать наблюдения клиента как факт.
Составлять список сервисов с указанием стоимостей уровней.
Каковы бы ни были требования клиента к сервису, следует предоставить ему возможность самостоятельно выбрать нужный вариант из предоставленного списка

Что не должен делать Service Manager

Говорить клиенту "нет".
Определять цели по достижению уровня сервиса, пока не определены все процессы поддержки.
Ставить цели, которые нельзя измерить

Деление процесса:

1.Планирование и внедрение процесса с учетом будущих усовершенствований.

2.Выполнение процесса:

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

Каталог сервисов.

Это один из наиболее важных инструментов маркетинга ИТ-услуг, а также их реализации.

Каталог состоит из части описывающей маркетинг и части, описывающей операции с сервисом.

Маркетинговый подкаталог

• Имя сервиса
• Ссылки на классификатор
• Ссылки на связанные направления деятельности
• Ссылки на связанные сервисы
• Описание сервисов, функций, границ предоставления сервисов, профилей пользователей.
• Поддерживаемые платформы или инфраструктуры
• Часы доступности
• Минимальная производительность
• Процедуры поддержки
• Правила учета
• Уровни использования и доступа
• Модель соглашения об уровне сервиса (SLA)
• Критерии построения отчетов об уровне сервиса
• Информация о контактах
• Текущий статус

Операционный подкаталог

• Владелец сервиса
• Профиль клиента
• Зависимости от других сервисов
• Ключевые поставщики
• Внешние и внутренние провайдеры
• Модель Operations Level Agreement (OLA)
• Детальная информация о технической инфраструктуре, необходимой для обеспечения сервиса
• Единицы инфраструктуры, рассматриваемые как активы
• Планы Business continuity (contingency)
• План поддержания целостности (backup, secure access)
• План улучшения качества сервисов
• План развития емкостей (Capacity plan)
• План развития ресурсов
• Операционный план
• Результаты аудита
• Связи с процессом Change management
• "Стандартные запросы"
• "Стандартные ответы"
• "Cтандартные стоимости" связанные со "стандартными запросами" и "стандартными ответами"
• Информация о ценах

ИТ без каталога сервисов то же, что ресторан без меню.

3. Управление процессом:

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

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

• определение приоритетов уровней сервиса
• контроль версий SLA
• разработка управленческих отчетов
• непрерывное улучшение процессов

Вход процесса • Конфигурационные единицы
• Информация из процесса Cost Management (Документация)

Выход процесса • Конфигурационные единицы
• Информация из процесса Cost Management (Документация)

Service Level Agreement - SLA

В соответствии с рекомендациями ITIL, SLA – это основной документ, регламентирующий взаимоотношения ИТ и клиентов.

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

Существенной частью SLA является каталог сервисов.

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

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

1. Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.
2. Дни и часы, когда сервис будет предлагаться, включая тестирование, поддержку и модернизации.
3. Число и размещение пользователей и/или оборудования, использующих данный сервис.
4. Описание процедуры отчетов о проблемах, включая условия эскалации на следующий уровень. Должно быть включено время подготовки отчета.
5. Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.
6. Спецификации целевых уровней качества сервиса, включая:

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

7. Описание платежей, связанных с сервисом. Возможно как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса.
8. Ответственности клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, программного обеспечения или изменения только в соответствии с процедурой изменения).
9. Процедура разрешения рассогласований, связанных с предоставлением сервиса.
10. Процесс улучшения SLA. В идеале, SLA определяется как особый сервис. Это позволяет сконфигурировать аппаратное и программное для максимизации способности удовлетворять SLA.

Capacity Management

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

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

Стоимость операций
Соответствие тербованиям клиента

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

Деятельности по обеспечению процесса (Process Delivery Activities)

Управление производительностью
Управление рабочими нагрузками
Выделение ресурсов для новых или измененных приложений
Управление ресурсами
Управление требованиями клиента
Моделирование
Планирование емкостей
Управление приобретениями
Отслеживание стоимостей
Деятельности по управлению качеством
Организация системы управления качеством сервисами
Определение контрольных точек для планирования емкостей
Разработка управленческих отчетов
Непрерывное усовершенствование процесса

Входы процесса

Финансовая информация (стоимости)
Проектная документация и планы
Информация о фактической доступности сервисов

Выходы процесса

Анализ использования емкостей
Проекты создания емкостей и планы по их реализации
Конфигурационные единицы (КЕ) (атрибуты и отношения с другими КЕ)
Данные о стоимостях
Запросы на изменение (Request for Change (RFC))
Данные о выполнении нарядов на работы
Проектная документация и планы

IT Service Continuity Management

Цель процесса Гарантировать доступность ИТ - сервисов в соответствии с соглашением об уровне сервисов в условиях чрезвычайных обстоятельств

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

Анализ рисков

Стоимость активов
Выявление слабых мест
Выявление угроз

Управление рисками

Разработка контрмер
Планирование деятельности в чрезвычайных обстоятельствах
Участие в Создании планов по обеспечению доступности
Определение требований к доступности в непредвиденных обстоятельствах
Предложения по повышению доступности сервисов в условиях чрезвычайных обстоятельств
Обзоры плана действий в непредвиденных обстоятельствах
Управление в условиях чрезвычайных обстоятельств

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

Определение стандартов плана действий в непредвиденных обстоятельствах
Создание управленческих отчетов
Непрерывное улучшение процесса

Управление стоимостями и оплатами (Cost & Charging Management)

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

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

Процесс состоит из компонент:

Costing - знание стоимостей предоставляемых сервисов
Charging - возрат затрат на предоставление сервисов от клиентов

Availability Management

Цель процесса

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

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

Деятельности по предоставлению сервисов

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

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

Определение процедур взаимодействия с поставщиками
Определение стандартов плана действий в непредвиденных обстоятельствах
Создание управленческих отчетов
Непрерывное улучшение процесса

Управление инцидентами (Incident Management)

Об ошибках ITIL

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

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

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

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

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

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

Деятельности по обеспечению процесса (Process Delivery Activities)

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

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

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

Problem Management

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

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

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

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

Собственник процесса - Problem Manager (Process Delivery Activities

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

Анализ тенденций инцидентов (Analyze incident trends)

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

Деятельности по обеспечению процесса (Quality Control Activities )

Организация системы управления проблемами/известными ошибками (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)

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

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

Это реализуется путем идентификации. мониторинга, контроллинга и обеспечения информации о Конфигурационных Единицах (КЕ) и их версиях. ( IT Service Management, an introduction, Publisher: Van Haren Publishing, 2002, ISBN 90-806713-63, )

Владелец процесса - менеджер изменений.

Важно не путать процессы Управление конфигурациями и Управление активами.

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

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

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

Планирование:

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

Идентификация:

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

Принципы идентификации вытекают из задач Управления сервисами. Например, если предъявляются требования к безопасности, то необходимо учитывать 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).

Мониторинг статуса:

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

Верификация:

Насколько информация в базе конфигураций соответствует реальности?

Отчеты:

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

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

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

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

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

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

1. Запросы на изменение хаотичны, возникают спонтанно. Клиент не осведомлен о трудоемкости реализации запроса на изменение. Клиент не осведомлен о целостной картине бизнеса и влиянии данного изменения на бизнес в целом. Принятие решения на основе личного героизма ЛПР и мнений авторитетных лиц. Высшее руководство не вовлечено непосредственно в процесс одобрения и реализации изменений. Все говорят о необходимости улучшений, но реально ничего не делается. Спонтанные попытки улучшения не приносят никакой пользы, кроме вреда.
2. Выявлена определенная повторяемость процесса принятия заявок на изменения, одобрения их и очередности выполнения. Высшее руководство непосредственно включено в процесс. Однако процесс не определен формально, не документирован и не стандартизован. Клиенты имеют представление о трудоемкости изменений на основе прежнего опыта, однако многолетний опыт зачастую сводится к многократному повторению однолетнего. Поведение клиентов и сотрудников ИТ реактивно.
3. Приняты стандарты на проведение изменений. Процесс описан формально, однако еще не производится измерений эффективности. Существует процесс регистрации запросов на изменение, одобрение и реализации изменений. Существует процесс выявления корневой причины потребности в изменениях. Разработчики осуществляют проактивное изменение систем, имея прогнозы изменения бизнеса. Существует формализованное описание сервисов (каталог сервисов), согласованное с клиентами. Существует процесс управления изменениями каталога. Проводятся регулярные тренинги сотрудников.
4. Процесс стандартизован, производятся измерения эффективности проведения изменений. Участники процесса осведомлены о влиянии изменений на бизнес. Имеется модель бизнеса, позволяющая проверить последствия изменений.
5. Производится непрерывная оптимизация процесса в соответствии с изменениями рынка.