Ян Ван Бон - ИТ Сервис-менеджмент. Введение

Если вы не можете влиять, то не стоит и измерять.

Цикл жизни инцидента включает в себя следующие этапы:

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

• Обнаружение: поставщик сервиса проинформирован о сбое. Инцидент получает статус «Сообщено». Затраченное на это время известно как время обнаружения.

• Реагирование: поставщику сервиса необходимо время, чтобы прореагировать на инцидент. Это время реагирования, оно используется для проведения диагностики, за которой следует выполнение ремонтных работ. В Процесс Управления Инцидентами входят такие виды работ, как Прием и Регистрация инцидентов, Классификация, Сопоставление, Анализ и Диагностика.

• Ремонт: поставщик сервиса восстанавливает компоненты, которые вызвали сбой.

• Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как конфигурирование и инициализация, и затем производится восстановление предоставления сервиса пользователям.

На рис. 14.3 показаны периоды времени, которые поддаются измерению.

Рис. 14.3. Измерение доступности (источник: OGC)

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

В Процессе Управления Доступностью, как правило, используются следующие метрики:

• Среднее время ремонта (Mean Time to Repair – MTTR): среднее время между возникновением сбоя и восстановлением сервиса, также известное как «простой». Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сервиса, как способность восстановления [242] Recoverability. и обслуживаемость [243] Serviceability. .

• Среднее время между сбоями (Mean Time Between Failures – MTBF): среднее время между восстановлением после одного сбоя и возникновением другого, также известное как «период работоспособного состояния» (uptime). Данная метрика относится к надежности сервиса.

• Среднее время между системными инцидентами (Mean Time Between System Incidents – MTBSI): среднее время между двумя последовательными инцидентами. Данная метрика представляет собой сумму двух метрик MTTR и MTBF.

Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбоев или было несколько серьезных нарушений в работе.

В отчеты о доступности сервиса могут быть включены следующие метрики:

• Коэффициент доступности (или недоступности) сервиса, выраженный в метриках MTTR, MTBSI и MTBF;

• общее время работоспособного состояния и время простоя;

• количество сбоев;

• дополнительная информация о сбоях, которые могут привести в настоящее время или в будущем к более высокому Уровню Недоступности Систем, чем было заранее согласовано.

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

14.4.7. Разработка Плана Обеспечения Доступности

Одним из основных результатов процесса является План Доступности [244] Availability Plan. . Это долгосрочный План Обеспечения Доступности Сервиса на несколько последующих лет, он не является Планом Внедрения Процесса Управления Доступностью.

План – это живой документ. В начале он должен дать описание текущей ситуации, а затем в него можно включать рекомендации и конкретные виды работ по улучшению существующих услуг, а также предложения по вводу новых услуг и их обслуживанию. Для составления полного и точного плана необходимо взаимодействие с такими Процессами, как Управление Уровнем Сервиса, Управление Непрерывностью ИТ-сервиса, Управление Финансами ИТ-сервиса, а также с Управлением Разработкой Приложений (напрямую или через Процесс Управления Изменениями).