Управление Доступностью

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

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

• Среднее время ремонта (Mean Time to Repair — MTTR): среднее время между возникновением
сбоя и восстановлением сервиса, также известное как «простой». Оно складывается из времени
обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сер­
виса, как способность восстановления¹ и обслуживаемость².

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

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

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

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

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

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

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

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

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

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

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

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

¹ Recoverability. ^s Serviceability. ³ Availability plan.