Лекции Жданова В. Г. «Верни себе зрение» в шести частях

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

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

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

В части взаимодействия бизнес-подразделений и ИТ-департамента в процессной модели 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 г.

_______________________(Ежов С.М.)

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

Лекции Жданова В. Г. «Верни себе зрение» в шести частях

Естественный метод восстановления зрения. Коррекция зрения по методу Шичко-Бейтса