Презентация на тему Процессы сопровождения сервисов. Модель процессов ITSM. (Лекция 3)

(IT Service Management, управление ИТ-услугами) становится в России привычным

инструментом управления информационной службой.
В ядре модели ITIL/ITSM выделяются две большие группы процессов:
процессы сопровождения услуг;
процессы предоставления услуг.
Первая группа относится к операционному уровню и обеспечивает повседневную (то есть операционную) деятельность ИС.
Процессы предоставления услуг обеспечивают постановку целей, задач и метрик для процессов операционного уровня, они относятся к тактическому уровню.

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

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

возможно более быстрое восстановление сервиса в случае возникновения инцидента.

К инцидентам, например, относятся сбой электропитания, сбой жесткого диска на рабочей станции пользователя, появление компьютерного вируса в локальной сети офиса и т.д.
В ITIL/ITSM существуют строгие правила обработки инцидентов, в частности обязательный прием, регистрация инцидента в рамках функции Service Desk.
Роль менеджера процесса можно также охарактеризовать как «специалиста по поддержке пользователей».

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

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

жизненный цикл инцидента в модели ITIL/ITSM.
Первый шаг этого

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

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

к типовым инцидентам, разрешаемым стандартными документированными процедурами. К простым запросам на обслуживание относится забытый пользователем пароль.
Если инцидент не разрешен оператором и при этом не является запросом на обслуживание, оператор передает инцидент специалистам. Они проводят изучение и диагностику инцидента, что позволяет разрешить инцидент и восстановить сервис.
Если специалистам службы ИС не удалось диагностировать инцидент и/или восстановить сервис, инцидент может быть передан на следующую линию сопровождения, т.е. специалистам головной компании, службе сопровождения поставщика оборудования и ПО и т.д.
Наконец, после того как инцидент разрешен, он должен быть закрыт. Под закрытием инцидента понимается пометка о завершении работ по инциденту. Обычно закрытие инцидента выполняет оператор Service Desk после того, как пользователь подтвердил восстановление сервиса.
На протяжении работ по инциденту оператор Service Desk выполняет функции общения с пользователем. Это функции владения (т.е. ответственности за инцидент), мониторинга (контроля за ходом разрешения инцидента) и коммуникаций (ответы на запросы пользователей о состоянии инцидента).

на Service Desk сообщение о невозможности распечатать документ на

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

выявления и устранения корневой причины сбоев, также контролирует тенденции

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

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

и понимается неизвестная первопричина одного или нескольких инцидентов.
После установления первопричины инцидентов (инцидента) проблема приобретает статус известной ошибки (known error).
Для известной ошибки устанавливается обходной путь (workaround), а затем планируется и реализуется структурное изменение, устраняющее первопричину ошибки.
Если устранением инцидентов занимаются специалисты среднего уровня согласно стандартным процедурам, то устранением проблем занимаются высококвалифицированные специалисты, действия которых и фиксируются затем в стандартных процедурах устранений инцидентов.
Роль менеджера проблем можно охарактеризовать как «компьютерного волшебника», способного решить самую сложную задачу в области инфраструктуры ИТ.

проблемами в разрешении инцидентов (б)
На рис. показано, как ошибка

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

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

рис. б).
Известные ошибки, обходные пути и рассматриваемые проблемы помещаются в общую базу данных проблем, которая доступна сотрудникам, управляющим инцидентами.
Соответственно, процессу управления инцидентами становится доступна информация о причинах инцидентов и имеющихся обходных путях, а в процесс управления проблемами поступает свежая информация об инцидентах.

корневых причин и отслеживание их устранения;
установление и контроль известных

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

связанные с работой компьютерной сети (печать, электронная почта, обращение

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

ИС организации, разрешает изменения, разрабатывает график работ по изменениям

и организует взаимодействие ресурсов, всесторонне оценивает воздействие изменения на среду ИС и связанные с ним риски (рис. ), в связи с этим взаимодействует со всеми процедурами ITSM.

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

каждое изменение конфигурации ИС организации в обязательном порядке оформляется запросом на изменение {Request for Change — RfC).
Запрос на изменение проходит стандартную процедуру одобрения. В зависимости от масштаба изменения решение принимается на уровне менеджера процесса, комитета по оценке изменений в рамках службы ИС, правления организации (рис.).
Конечный результат процесса — набор изменений, согласованных между собой и с существующей конфигурацией информационной системы и не нарушающих функционирования уже существующих сервисов. Все изменения в обязательном порядке регистрируются процессом управления конфигурацией.

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

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

по оценке изменений (Change Advisory Board — CAB).
Этот

комитет включает в себя CIO (руководитель службы ИС), представителей бизнес-подразделений (представителей от финансовой службы и основных направлений бизнеса) и сотрудников службы ИС, отвечающих по мере необходимости за следующие роли: планирование сервисов, управление изменениями, управление уровнем сервиса, управление проблемами и др.
Задача комитета — сопоставление внесения изменения и отказа от изменения с точки зрения результатов и рисков.
Изменение отвергается как в случае незначительных результатов, так и в случае значительных рисков. В остальных случаях изменение может быть принято.

не является завершением процесса управления изменениями.
На основании решения

управляющего органа разрабатывается график будущих изменений (Forward Schedule of Changes — FSC) — детальный календарный график одобренных изменений, согласованный с заказчиками изменений, а также с процессами управления уровнем сервиса, Service Desk и процессом управления доступностью.
Такое согласование позволяет учесть при реализации изменений потребности клиента наряду с возможностями службы ИС — загрузкой сотрудников, техническим обслуживанием ИС, обучением пользователей и т.д.
График будущих изменений выступает водоразделом между процессом управления изменениями и процессом управления релизами.
В первом процессе FSC формируется и контролируется, во втором — исполняется.
Ряд изменений в действительности не требуют FSC, — например, когда специалист по управлению проблемами вносит изменения самостоятельно и оформляет запрос на изменение задним числом.

разработки нового сервиса по сбору и обработке отчетности сотруднику

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

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

поддержание в актуальном состоянии данных по конфигурации информационных систем,

иначе говоря, базы данных позиций конфигураций — БДПК (Configuration Management Database — CMDB).
Под позицией конфигурации понимается компонент инфраструктуры ИТ, документация на компоненты инфраструктуры ИТ, а также ряд документов процессов ITIL/ITSM, учитываемый в рамках процесса управления конфигурациями.
В качестве компонента инфраструктуры ИТ может рассматриваться ПК, локальная сеть или отдельный ее сегмент, сервер, мэйнфрейм, комплект программного обеспечения и т.д.
В качестве документации на компонент рассматривается эксплуатационная и пользовательская документация на оборудование и ПО.
Наконец, в качестве документов процессов ITILITSM могут выступать запросы на изменения, описания процессов, должностные инструкции и т.д.

программного обеспечения, включая как системы коллективного пользования (серверы, сетевое

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

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

в БДПК может относиться к системе R/3.
Наряду с этим могут присутствовать записи, относящиеся к серверу (серверам) R/3, серверному ПО R/3, клиентским рабочим местам системы. Все перечисленные записи будут ссылаться на запись, относящуюся к системе в целом.
База данных конфигурации используется практически всеми процессами ITSM, но особенно важна данная информация в процессах управления инцидентами и проблемами, а также в процессах блока предоставления сервисов.

следующие функции:
ведет базу данных единиц конфигурации;
ведет управленческий учет активов

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

ИС, осуществляя управление проблемами (см. пример по управлению проблемами),

заменил неисправный коммутатор. По завершении работ данный сотрудник составляет запрос на изменение.
Запрос направляется менеджеру по изменениям, который одобряет сделанное изменение. После этого запрос на изменение с визой менеджера по изменениям передается сотруднику службы ИС, ведущему базу данных конфигурации, для внесения изменений в базу.
На основании запроса в базу данных заносятся данные установленного устройства и произведенные настройки.

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

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

в среду ИС организации.
Под релизом (release) понимается набор

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

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

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

три вида:
1) большой релиз ПО и/или обновление оборудования — обычно

содержит значительный объем новой функциональности, которая делает ранее сделанные исправления проблем частично или полностью избыточными. Также большой релиз обычно отменяет предшествующие малые релизы;
2) малый релиз ПО и/или обновление оборудования — обычно содержит незначительные улучшения, часть из которых могли быть выполнены ранее как чрезвычайные релизы. Соответственно, эти изменения отменяются малым релизом;
3) чрезвычайный релиз ПО и/или обновление оборудования — обычно содержит исправления некоторого числа известных ошибок.

также на три вида:
полный релиз,
дельта-релиз, или частичный релиз,
пакетный релиз.

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

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

в себя только новые или измененные позиции конфигурации.
Например,

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

различных полных или частичных релизов, которые распространяются и внедряются

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

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

и конфигурирование релиза;
подписание релиза в развертывание;
подготовка релиза и обучение

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