Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбоев или было несколько серьезных нарушений в работе.
В отчеты о доступности сервиса могут быть включены следующие метрики:
• Коэффициент доступности (или недоступности) сервиса, выраженный в метриках MTTR, MTBSI и MTBF;
• общее время работоспособного состояния и время простоя;
• количество сбоев;
• дополнительная информация о сбоях, которые могут привести в настоящее время или в будущем к более высокому Уровню Недоступности Систем, чем было заранее согласовано.
Проблема составления отчетов состоит в том, что представленные выше метрики могут не восприниматься заказчиком. Поэтому отчеты о доступности сервиса должны составляться с точки зрения заказчика. Отчет в первую очередь должен давать информацию о доступности сервиса для наиболее важных бизнес-функций и о доступности данных (т. е. давать бизнес-представления), а не о доступности технических ИТ-компонентов. Отчеты должны быть написаны на понятном заказчику языке.
14.4.7. Разработка Плана Обеспечения Доступности
Одним из основных результатов процесса является План Доступности[244]. Это долгосрочный План Обеспечения Доступности Сервиса на несколько последующих лет, он не является Планом Внедрения Процесса Управления Доступностью.
План – это живой документ. В начале он должен дать описание текущей ситуации, а затем в него можно включать рекомендации и конкретные виды работ по улучшению существующих услуг, а также предложения по вводу новых услуг и их обслуживанию. Для составления полного и точного плана необходимо взаимодействие с такими Процессами, как Управление Уровнем Сервиса, Управление Непрерывностью ИТ-сервиса, Управление Финансами ИТ-сервиса, а также с Управлением Разработкой Приложений (напрямую или через Процесс Управления Изменениями).
14.4.8. Инструментальные средства
Для достижения эффективности Процесс Управления Доступностью должен использовать ряд инструментальных средств следующего назначения:
• определение времени простоя;
• фиксация исторической информации;
• создание отчетов;
• статистический анализ;
• анализ воздействия.
Процесс Управления Доступностью берет информацию из записей Процесса Управления инцидентами, Базы Данных CMDB и из Базы Данных Процесса Управления Мощностями (CL). Эта информация может храниться в специальной Базе Данных Процесса Управления Доступностью.
14.4.9. Методы и методики
В настоящее время существует широкий спектр методов и методик Управления Доступностью, которые помогают в проведении планирования, улучшения доступности и в составлении отчетов. Наиболее важные из них приведены ниже.
Анализ влияния отказа компонентов (CFIA)[245]
Данный метод предполагает использование матрицы доступности стратегических компонентов и их ролей в каждой услуге. При разработке такой матрицы очень полезной может оказаться база данных CMDB.
Пример матрицы CFIA на рис. 14.4 показывает, что Конфигурационные Единицы, которые для многих услуг помечены символом «X», являются важными элементами ИТ-инфраструктуры (анализ по горизонтали) и что услуги, часто отмечаемые символом «X», являются комплексными и подвержены сбоям (анализ по вертикали). Этот метод также можно применять для изучения степени зависимости от сторонних организаций (усовершенствованный метод CFIA).
Конфигурационная единица Услуга А Услуга Б PC № 1 B B PC № 2 B Кабель № 1 B B Кабель № 2 B Разъем № 1 X X Разъем № 2 X Сегмент сети Ethernet X X Маршрутизатор X X Канал глобальной сети (WAN) X X Маршрутизатор X X Сегмент X X Сетевой информационный центр A A Сервер B B Системное программное обеспечение B B Приложения B B База данных X X
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).
К числу преимуществ данного метода относятся эффективность подхода, прямая связь между заказчиком и поставщиком и более широкая область для предложений по улучшению сервиса.
