Заурбек Алехин, статья опубликована в журнале "Открытые системы", № 7-8, 2001г. стр.50-56

В статье рассматриваются два ключевых процесса ITIL [1,2], ориентированных на выявление неисправностей в ИТ-инфраструктуре и инициирование мер по их устранению. 

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

Управление инцидентами

Основной целью процесса управления инцидентами (Incident Management) является восстановление нормальной работоспособности системы в максимально короткие сроки и минимизация отрицательного влияния на бизнес, пользующийся сервисами, работоспособность которых оказалась нарушенной. Под "нормальным функционированием сервисов" понимается функционирование, соответствующее зафиксированному в специальном соглашении SLA (Соглашении об уровне сервиса).

Согласно принятому в ITIL определению [3] под "инцидентом" понимается "любое событие, не являющее элементом нормального функционирования сервиса и при этом оказывающее или способное оказать влияние на предоставление сервиса путем его прерывания или снижения качества".  Типичные примеры и основные категории инцидентов: Приложения: сервис недоступен; ошибка в приложении, не дающая клиенту нормально работать; исчерпано дисковое пространство. Оборудование: сбой системы; внутренний сигнал тревоги; отказ принтера. Заявки на обслуживание: заявки на получение дополнительной информации, совета, документации; забытый пароль. Большинство групп специалистов ИТ имеют отношение к устранению тех или иных инцидентов. Service Desk [2] отвечает за мониторинг процесса устранения всех зарегистрированных инцидентов - поскольку является собственником всех таких инцидентов. (Если инцидент не зарегистрирован - собственник отсутствует). Этот процесс в большей степени реактивный. Для эффективного реагирования на инциденты должен быть определен формальный метод работы сотрудников, включающий использование необходимого программного обеспечения.  Те инциденты, которые не могут быть разрешены непосредственно службой Service Desk, должны быть переадресованы соответствующим специалистам. Способ разрешения инцидента или вариант его обхода должны быть установлены и сообщены пользователю как можно быстрее, исходя из главной цели - минимизации отрицательного влияния на основную деятельность пользователя. После устранения причины инцидента и восстановления сервиса до оговоренного в SLA уровня, инцидент закрывается. Рис.1. Жизненный цикл инцидента

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

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

Входные данные для описания инцидентов:

• детальное описание инцидента, полученное от службы Service Desk, служб обеспечения оперативного функционирования сетей или серверов и т.д.;
• описание конфигураций и элементов, возможно связанных с инцидентом. Описания берутся из CMDB - базы данных конфигурационных единиц, к которым относятся все элементы инфраструктуры ИТ (оборудование, программное обеспечение, документация, предоставляемые сервисы и т.д.). За ведение CMDB отвечает процесс управления конфигурациями; 
• информация (при ее наличии) из базы проблем и базы известных ошибок;
• описание способа разрешения.

Результаты:

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

Мероприятия по управлению инцидентами:

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

Роли и функции:

• группы поддержки первой, второй и третьей линий, а также группы специалистов и внешние партнеры (роли);
• менеджер управления инцидентами (роль);
• менеджер Service Desk (функция).

Возможные метрики:

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

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

Передача инцидента от Service Desk на вторую линию поддержки или "функциональная эскалация" требуется при невозможности устранения инцидента на первой линии. Автоматизированная функциональная эскалация возможна, но должна быть тщательно спланирована в соответствии с SLA.

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

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

Наиболее важные приобретаемые полезные качества:

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

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

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

Таблица 1. Сравнение двух процессов.

	Управление инцидентами	Управление проблемами
Основная цель	Сокращение срока устранения инцидентов	Устранение причин возникновения инцидентов
Является собственником	Инцидентов	Проблем Известных ошибок
Имеет право инициировать	Рассмотрение проблемы Внесение временных изменений (для восстановления текущей работоспособности сервиса)	Внесение постоянных изменений Закрытие инцидентов и проблем
Имеет право закрыть	Инцидент	Проблему
Осуществляемая классификация	Максимально полное (в соответствии с принятыми процедурами) определение влияния, срочности, приоритета, а также категории инцидента и инициируемой проблемы.	Уточнение категории проблемы и связанных с ней инцидентов.
Процесс анализа	Иерархический, поэтапный	Иерархический, поэтапный
Характер процесса	Преимущественно ре-активный	Ре-активный и про-активный
Рекомендации внесения изменений	Только временные изменения (для восстановления текущей работоспособности сервиса)	Временные и постоянные
Предоставляемая информация	Отчеты об инцидентах в различных разрезах	Отчеты о проблемах, известных ошибках и способах их устранения
Общение с пользователем	Обязательно (при закрытии инцидента) и при регистрации в случае совмещения с Service Desk	Возможно (только в ходе уточнения признаков проблемы)

Управление проблемами

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

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

Контроль проблем и ошибок вместе с про-активным управлением проблемами составляют сферу ответственности процесса управления проблемами. В терминах формальных определений, "проблема" - это неизвестная основная причина возникновения одного или нескольких инцидентов, а "известная ошибка" - это успешно диагностированная проблема, для которой найден обходной путь (или способ устранения).

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

Входные данные:

• детали инцидента от управления инцидентами;
• детальное описание конфигураций из CMDB;
• все известные обходные пути (от управления инцидентами).

Мероприятия по управлению инцидентами:

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

Результаты:

• описание новых известных ошибок;
• запросы на внесение изменений;
• обновленная регистрационная запись проблемы (включающая вариант решения проблемы и/или любой доступный обходной путь);
• для разрешенных проблем - закрытая регистрационная запись проблемы;
• поиск аналогов инцидента среди известных ошибок и рассматриваемых проблем;
• управленческая информация.

Роли и функции:

• сотрудники, ответственные за обработку проблем (роли);
• менеджер управления проблемами (роль);

Возможные метрики:

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

Эффект от внедрения процесса управления проблемами

Наиболее важные приобретаемые полезные качества:

• Качество сервисов. Управление проблемами помогает поддерживать непрерывный цикл постоянного повышения качества ИТ-сервисов.
• Сокращение числа инцидентов. Процесс управления проблемами является инструментом для сокращения числа возникающих инцидентов, отрицательно влияющих на бизнес организации.
• Непрерывное решение. В результате работы процесса сокращается число и влияние на бизнес уже решенных проблем и известных ошибок.
• Усовершенствованное обучение. Процесс основывается на концепции использования накопленных знаний из прошлого и предоставляет возможности для анализа трендов и предотвращения сбоев, либо снижения их значимости и влияния на основной бизнес. 
• Увеличение количества инцидентов, разрешаемых Service Desk при первом обращении. Это достигается путем предоставления в распоряжение Service Desk рекомендаций по путям предотвращения и обхода возникающих инцидентов.

В противовес посмотрим, к чему может привести отказ от реализации процесса:

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

Взаимоотношение между инцидентами, проблемами, известными ошибками и запросами на внесение изменений Возникая в результате различных ошибок или сбоев, инциденты обычно вызывают отклонения от стандартного качества предоставляемых сервисов. Если причина инцидента понятна и очевидна, то отсутствует необходимость дальнейших исследований проблемы и достаточно сразу сформулировать способ ее устранения либо пути обхода. Порой с такими инцидентами пользователи справляются самостоятельно, не обращаясь в Service Desk (например, осуществив перезагрузку ПК или перезапуск модема). Если причина инцидента не ясна, должна быть зарегистрирована новая проблема, подлежащая исследованию. В таком понимании проблема обозначает наличие неизвестной ошибки в инфраструктуре. В принципе, регистрация новой проблемы допускается только в случае, если разрешен дальнейший анализ. Успешное исследование поднятой проблемы завершается идентификацией ошибки и в этом случае запись должна быть преобразована в известную ошибку, должен быть также разработан вариант обхода ошибки и/или сгенерирован запрос на внесение изменений (Рис. 2). Рис.2. Взаимоотношение между инцидентами, проблемами, известными ошибками и запросами на внесение изменений Таким образом, мы приходим к следующим определениям: проблема: неизвестная причина одного или нескольких инцидентов; известная ошибка: успешно диагностированная проблема, для которой разработан способ обхода; запрос на внесение изменений: запрос на изменение какого-нибудь компонента ИТ инфраструктуры или какого-нибудь аспект ИТ-сервиса. Проблема может оказаться причиной целого ряда инцидентов. Более того, иногда ее не удается диагностировать без накопления информации о различных вариантах проявления в течение продолжительного времени. Обработка проблем существенно отличается от обработки инцидентов и поэтому осуществляется процессом управления проблемами. Рассмотрим гипотетический, но в то же время - вполне возможный вариант. Допустим, жесткий диск, на котором размещена информационная база данных, содержит сбойный кластер и чтение информации с него происходит не всегда удачно (в нашей терминологии это ошибка в инфраструктуре). Сама по себе информация, расположенная на этом кластере, используется достаточно редко и обращение к ней происходит, как правило, при поиске со сложными условиями. Пользователь, в ответ на запрос поиска информации, получает список ссылок, при обращении к одной из которых иногда возникает сбой. Некоторые пользователи это сбой игнорируют, другие сообщают о нем в службу поддержки, тем самым инициируя регистрацию инцидента. Поскольку информация не столь уж важная, а также в связи с тем, что примерно с пятого раза она все же читается, служба поддержки регистрирует новую проблему и одновременно - возможный вариант ее обхода ("попытаться обратиться несколько раз"). Все инциденты этого типа уже имевшие место, а также возникающие в ходе дальнейшей работы, связываются с этой проблемой. Во время планового анализа проблемы специалисты выявляют причину (описывая ее как известную ошибку) и размещают заявку на необходимость замены жесткого диска (запрос на внесение изменений). После выполнения необходимых формальностей и в разрешенное для работ время когда потребность в информации минимальна, соответствующие специалисты осуществляют замену жесткого диска и тем самым полностью устраняют проблему. Далее в соответствии с принятыми процедурами, должны быть закрыты сама проблема и все связанные с ней инциденты. При обработке инцидента может оказаться, что служба Service Desk самостоятельно обнаружила способы обхода проблем и/или определенные закономерности. Вся выявленная дополнительная информация должна быть внесена в форму регистрации проблемы, и таким образом стать доступной управлению проблемами. Возможны случаи, когда инцидент практически сразу должен рассматриваться как проблема и передаваться на рассмотрение управлению проблемами.

Реализация и внедрение процессов

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

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

Допустимо (и рекомендуется) совмещение функций Service Desk и функций управления инцидентами (при отсутствии серьезных ограничений, организации поступают именно таким образом). Но важно помнить, что это разные процессы: первичное общение с пользователями не входит в функции процесса управления инцидентами. К тому же, пользователь может обратиться в службу поддержки не только в связи с возникшим инцидентом, но и по иной причине: потребность информации, необходимость пополнения расходуемых материалов и т.д. С другой стороны, при некоторых способах реализации (например, в случае построения службы поддержки на основе Web-технологий, когда пользователь самостоятельно вносит все необходимые данные в формы) необходимость выделенной службы Service Desk остается под вопросом. В то же время ни в коем случае нельзя отказываться от управления инцидентами - откуда бы ни поступило сообщение об их возникновении, кто-то обязательно должен отвечать за их устранение.

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

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

Производители инструментария стараются учитывать упомянутые рекомендации. Например, HP OpenView Service Desk 3.0 имеет модульную структуру. В виде отдельного модуля реализованы возможности регистрации и управления обращений пользователей, инцидентов и проблем, что вполне соответствует упомянутым рекомендациям: интеграция в данном случая является максимально полной. Пользователи системы, построенной на основе этого продукта, имеют возможность стоить связи между регистрационными записями всех перечисленных типов, осуществлять поиск по контексту и с учетом этих связей, определять известные способы решения проявляющихся неисправностей. Разделение этих функций может снизить эффективность работы инструментального средства, а как следствие - и качество реализации процессов. В то же время, в основе всякого решения по управлению ИТ инфраструктурой лежит учет имеющегося оборудования, приложений, документации и т.д. - всего того, что и составляет инфраструктуру ИТ. Эти возможности также доступны в рамках HP Service Desk 3.0. Кроме этого в продукте в виде отдельных модулей реализованы возможности, предназначенные для автоматизации управления изменениями и управления соглашениями об уровнях сервисов. Интеграция этих модулей с названным первым реализуется в максимально полном объеме, предоставляя возможность использовать рассматриваемый продукт в качестве основы для построения комплексной системы управления информационными технологиями.

Продукт компании Remedy строится несколько сложнее, основой его является Remedy Action Request System, которая устанавливается на сервере. К данной системе в качестве прикладной части могут приобретаться функциональные модули: Help Desk, Asset Management, Change Management и Service Level Agreement. Каждый из модулей может использоваться как самостоятельно (без других прикладных модулей), так и в составе единого комплексного решения. Вопросы автоматизации процессов управления проблемами и инцидентами, как и для случая продукта от HP, реализуются в модуле Remedy Help Desk. При этом имеются некоторые отличия и реализуются отдельные собственные подходы к пониманию данных процессов, но основные пожелания и требования ITIL полностью учтены.

Рекомендации и возможные трудности

Успешное внедрение рассматриваемых процессов требует, как минимум, следующего:

• Наличия актуальной и своевременно обновляемой CMDB. Если эта база недоступна, информация об имеющих отношение к инциденту конфигурационных единицах будет добываться вручную, что существенно увеличит время обработки инцидента и повысит ее сложность.
• Должна быть доступна обновляемая база знаний по ошибкам/проблемам и способам их разрешения, а также обхода. Наличие такой базы позволяет быстро разрешать многие проблемы. Желательно иметь возможность подключения к этой базе аналогичных баз, разработанных другими организациями и компаниями. Возникающие при этом вопросы совместимости могут привести к большим сложностям, поэтому рекомендуется использовать решения с открытой архитектурой, содержащие средства для импорта и экспорта данных. В последнее время все чаще в качестве стандартного способа доступа к информации используется доступ через Web-интерфейс, являющийся удобным и понятным, а также широко распространенным. 
• С точки зрения потенциально конфликтной ситуации между управлением проблемами и управлением инцидентами (из-за их разных целей), стоит уделить внимание совместной работе и сотрудничеству исполнителей обоих процессов. При этом нельзя забывать о том, что из тех же соображений один и тот же человек не может исполнять и те и другие обязанности одновременно: ему будет очень трудно найти баланс интересов.
• Эффективная автоматизированная система регистрации инцидентов, с возможностями детальной и качественной классификации, является чрезвычайно важным элементом для организации функционирования как службы Service Desk, так и рассматриваемых процессов в чистом виде. В настоящее время использование для этих целей бумажных технологий не рекомендуется.

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

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

Проиллюстрируем последние возможности на примере уже упоминавшегося продукта Service Desk 3.0. Будучи представителем семейства продуктов HP OpenView, Service Desk содержит возможности получения сообщений от других продуктов данного семейства, в том числе: от NNM (Network Node Manager) - средства мониторинга и управления сетевыми устройствами, а также от VantagePoint Operations - средства мониторинга и управления серверами и приложениями. Данные продукты могут в автоматическом режиме, на основании собираемой информации о контролируемых объектах, генерировать запросы для Service Desk, которые автоматически передаются и анализируются операторами службы поддержки и/или обрабатываются в автоматическом режиме. При соответствующей настройке, источниками аналогичных сообщений могут стать и иные диагностические средства. Продукт предусматривает возможности автоматического информирования (путем отправки сообщений) руководителей соответствующих уровней при нарушении сроков устранения инцидента. В продукте реализованы расширенные возможности по поиску необходимой информации среди уже учтенных проблем, инцидентов и иных данных. В продукте представлены возможности интеграции с почтовыми, телефонными и пейджинговыми системами. …

В виду крайней актуальности и полезности перечисленных выше дополнительных возможностей, производители программных решений стараются включать в свои продукты максимальное число различных дополнительны возможностей. Таким образом, многое из сказанного о HP Service Desk относится и к продуктам других производителей: Remedy, Tivoli, CA, Peregrin, FrontRange.

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

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

Заключение

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

Об авторе: Заурбек Алехин (alekhin@i-teco.ru), руководитель проекта, компания i-Teco г.Москва.

Литература:

[1] З.Алехин. ITIL - основа концепции управления ИТ-службами. "Открытые системы". №3, 2001, стр. 32-36.
[2] З.Алехин. Service Desk - цели, возможности, реализации. "Открытые системы". №5-6, 2001, стр. 43-48
[3] CCTA. Best Practice for Service Support. London: The Stationery Office,2000, 306p.