3.1.5 Поддержка работы системы
После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.
Дальнейшее развитие службы Service Desk может выражаться в замене того «бесплатного» инструмента регистрации и обработки запросов пользователей, который использовался в первое время работы, на более функциональный, специализированный. Новый инструмент может предоставить более детальную информацию о работе Service Desk, и тогда появится возможность проводить более тонкую настройку процесса управления инцидентами. При этом пользователи также получат дополнительные услуги, к примеру, автоматическое оповещение по электронной почте о решении инцидента. После того, как проявятся реальные положительные результаты работы службы Service Desk (а они проявятся обязательно), доказывать высшему руководству компании необходимость приобретения специализированного программного обеспечения будет намного проще. Не исключен даже вариант, когда руководство компании само предложит помощь и средства на развитие процесса обработки запросов пользователей.
4 Реализация некоторых из возможных путей решения поставленной в техническом задании задачи
Большинство групп специалистов ИТ имеют отношение к устранению тех или иных инцидентов. Service Desk отвечает за мониторинг процесса устранения всех зарегистрированных инцидентов - поскольку является собственником всех таких инцидентов. (Если инцидент не зарегистрирован - собственник отсутствует). Этот процесс в большей степени реактивный. Для эффективного реагирования на инциденты должен быть определен формальный метод работы сотрудников, включающий использование необходимого программного обеспечения.
Основной целью процесса управления инцидентами (Incident Management) является восстановление нормальной работоспособности системы в максимально короткие сроки и минимизация отрицательного влияния на бизнес, пользующийся сервисами, работоспособность которых оказалась нарушенной. Под "нормальным функционированием сервисов" понимается функционирование, соответствующее зафиксированному в специальном соглашении SLA (Соглашении об уровне сервиса).
Согласно принятому в ITIL определению под "инцидентом" понимается "любое событие, не являющее элементом нормального функционирования сервиса и при этом оказывающее или способное оказать влияние на предоставление сервиса путем его прерывания или снижения качества".
Типичные примеры и основные категории инцидентов:
Приложения:
сервис недоступен;
ошибка в приложении, не дающая клиенту нормально работать;
исчерпано дисковое пространство.
Оборудование:
сбой системы;
внутренний сигнал тревоги;
отказ принтера.
Заявки на обслуживание:
заявки на получение дополнительной информации, совета, документации;
забытый пароль.
Те инциденты, которые не могут быть разрешены непосредственно службой Service Desk, должны быть переадресованы соответствующим специалистам. Способ разрешения инцидента или вариант его обхода должны быть установлены и сообщены пользователю как можно быстрее, исходя из главной цели - минимизации отрицательного влияния на основную деятельность пользователя. После устранения причины инцидента и восстановления сервиса до оговоренного в SLA уровня, инцидент закрывается.
Рис.1.
Жизненный цикл инцидента
К инцидентам не могут быть отнесены события, не касающиеся качества предоставляемых ИТ-сервисов, а также те, которые снижая это качество, не выходят за рамки, оговоренные в SLA. Особое место занимают случаи, когда клиент не ощутил на себе наличия инцидента: все необходимые меры были приняты в автоматическом режиме или обслуживающим персоналом еще до момента реального снижения качества. В качестве примера здесь можно привести: автоматическое архивирование данных и освобождение рабочего диска при приближении к моменту его переполнения; переход на резервный сервер при сбоях основного и т.д. Тем не менее, они не могут быть исключены из списка инцидентов. Правильная организация процесса требует отработки и таких инцидентов в соответствии с полной процедурой (с последующим отображением в отчетах и принятием необходимых мер по их предотвращению в будущем).
Всякий процесс может быть формально кратко описан путем перечисления набора характеристик, наиболее заметные из которых приведены в перечисленных далее группах.
Входные данные для описания инцидентов:
детальное описание инцидента, полученное от службы Service Desk, служб обеспечения оперативного функционирования сетей или серверов и т.д.;
описание конфигураций и элементов, возможно связанных с инцидентом. Описания берутся из CMDB - базы данных конфигурационных единиц, к которым относятся все элементы инфраструктуры ИТ (оборудование, программное обеспечение, документация, предоставляемые сервисы и т.д.). За ведение CMDB отвечает процесс управления конфигурациями;
информация (при ее наличии) из базы проблем и базы известных ошибок;
описание способа разрешения.
Результаты:
запрос на временное внесение изменений для устранения инцидента, обновленная регистрационная запись инцидента (включающая способ разрешения и/или обхода);
разрешенный (устраненный) и закрытый инцидент;
сообщение для клиента;
управленческая информация (отчеты).
Мероприятия по управлению инцидентами:
определение и регистрация инцидента;
классификация инцидента и начальная помощь;
исследование и диагностика;
разрешение инцидента и восстановление системы;
закрытие инцидента;
собственность, мониторинг, отслеживание и взаимодействие.
Роли и функции:
группы поддержки первой, второй и третьей линий, а также группы специалистов и внешние партнеры (роли);
менеджер управления инцидентами (роль);
менеджер Service Desk (функция).
Возможные метрики:
общее число инцидентов;
среднее время устранения или обхода инцидента (по различным типам инцидентов);
процент инцидентов, устраненных за время, не превышающее оговоренного в SLA;
средняя стоимость устранения инцидента;
процент инцидентов, закрытых без привлечения иных специалистов;
число и процент инцидентов, устраненных удаленно (без визита к пользователю).
В целях обеспечения соблюдения временных рамок, выделенных для выполнения тех или иных действий, применяется эскалация, которая бывает функциональной и иерархической. Более точно: под "эскалацией" понимается организационный механизм, помогающий контролировать время устранения инцидента. Он должен использоваться при реализации всех мероприятий в процессе разрешения инцидента. Речь идет о необходимости передачи информации об инциденте либо более квалифицированным специалистам, либо информирование руководства о невозможности устранения инцидента в оговоренные сроки.
Передача инцидента от Service Desk на вторую линию поддержки или "функциональная эскалация" требуется при невозможности устранения инцидента на первой линии. Автоматизированная функциональная эскалация возможна, но должна быть тщательно спланирована в соответствии с SLA.
"Иерархическая эскалация" оказывается необходимой при невозможности устранения инцидента либо за выделенное время либо с необходимым качеством. Как правило, она осуществляется персоналом службы Service Desk в соответствии с их опытом и вручную. Автоматизированная иерархическая эскалация тоже используется и может строиться на основе учета временных интервалов. Предпочтительнее, если она осуществляется до времени, установленного в SLA, чтобы соответствующий руководитель имел возможность предпринять дополнительные действия.