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

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

X – сбой/дефект означает, что услуга недоступна

А – безотказная конфигурация

В – безотказная конфигурация, с переключением

" " – нет воздействия

Рис. 14.4. Матрица CFIA (источник: OGC)

Анализ дерева неисправностей[246] (FTA)

Анализ дерева неисправностей используется для определения цепочки событий, приводящих к сбою ИТ-сервиса. Для каждой услуги изображается отдельное дерево с использованием символов Буля. Дерево анализируется снизу вверх. Метод FTA выделяет следующие события:

? Основные события: входы на схеме (обозначены кружочками), такие как отключение электропи­тания и ошибки операторов. Эти события не исследуются.

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

? Условные события: события, которые происходят только при определенных условиях, таких как отказ кондиционера.

? Запускающее событие: события, которые приводят к возникновению других событий, такие как автоматическое отключение, вызванное сигналом источника бесперебойного питания.

Рис. 14.5. Анализ дерева дефектов/сбоев (источник: OGC)

События можно объединять с логическими операциями, такими как:

? операция AND (И): результирующее событие произойдет, если будут присутствовать все входы одновременно;

? операция OR (ИЛИ): результирующее событие произойдет, если будет иметь место один или не­сколько входов;

? операция XOR (Исключающее ИЛИ): результирующее событие произойдет, если будет иметь место только один вход/причина;

? операция Inhibit (Запрет): результирующее событие произойдет, если не будут выполнены вход­ные условия.

Метод Анализа и Управления Рисками[247] (CRAMM)

Данный метод рассматривался в главе, посвященной Управлению Непрерывностью ИТ-сервиса.

Расчеты доступности сервиса

Описанные выше метрики можно использовать при заключении соглашений о доступности сервиса с заказчиками. Эти договоренности входят составной частью в Соглашения об Уровне Сервиса. Приведенная ниже формула помогает определить, отвечает ли достигнутый Уровень Доступности согласованным требованиям:

Рис. 14.6. Формула доступности (источник: OGC)

Достигнутое время работоспособности системы равно разнице между согласованным временем ра­ботоспособности и случившемся временем простоя. Например: если была достигнута договорен­ность о 98% доступности сервиса в рабочие дни с 7.00 до 19.00 и в течение это периода был двухчасо­вой отказ сервиса, то достигнутое время работоспособности (процент доступности) будет равен:

(5x12- 2)/(5х 12) х 100%= 96,7%

Анализ простоев системы[248] (SOA)

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

Характеристики метода SOA:

? широкая сфера действия: он не ограничивается инфраструктурой и охватывает также процессы, процедуры и аспекты корпоративной культуры;

? рассмотрение вопросов с точки зрения заказчика;

? совместная реализация метода представителями заказчика и ИТ-организации (команда метода SOA).

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

Пост технического наблюдения[249] (ТОР)

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

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

14.5. Контроль процесса

14.5.1. Составление отчетов

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

? время обнаружения;

? время реагирования;

? время ремонта;

? время восстановления;

? оценка успешности использования соответствующих методов (CFIA, CRAMM, SOA);

? степень реализации процесса: услуги, Соглашения об Уровне Сервиса и группы заказчиков, попа­дающие под действия Соглашения об Уровне Сервиса.

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

14.5.2. Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха Процесса Управления Доступностью сервиса являются:

? наличие у бизнеса четко определенных целей и пожеланий в отношении доступности сервиса;

? налаженный Процесс Управления Уровнем Сервиса для обеспечения формализации соглашений;

? одинаковое понимание сторонами понятий доступности и простоя;

? понимание как бизнесом, так и ИТ-организацией преимуществ Управления Доступностью.

Об эффективности и рациональности Процесса Управления Доступностью свидетельствуют такие показатели эффективности, как:

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

? продолжительность простоев;

? частота возникновения простоев.

14.5.3. Функции и роли

В организации может быть назначена роль Руководителя Процесса Управления Доступностью для того, чтобы планировать и поддерживать процесс. Задача Руководителя процесса состоит в следующем: