ИТ Сервис-менеджмент. Введение
Шрифт:
Проблема составления отчетов состоит в том, что представленные выше метрики могут не восприниматься заказчиком. Поэтому отчеты о доступности сервиса должны составляться с точки зрения заказчика. Отчет в первую очередь должен давать информацию о доступности сервиса для наиболее важных бизнес-функций и о доступности данных (т. е. давать бизнес-представления), а не о доступности технических ИТ-компонентов. Отчеты должны быть написаны на понятном заказчику языке.
14.4.7. Разработка Плана Обеспечения Доступности
Одним из основных результатов процесса является План Доступности [244] . Это долгосрочный План Обеспечения Доступности
План – это живой документ. В начале он должен дать описание текущей ситуации, а затем в него можно включать рекомендации и конкретные виды работ по улучшению существующих услуг, а также предложения по вводу новых услуг и их обслуживанию. Для составления полного и точного плана необходимо взаимодействие с такими Процессами, как Управление Уровнем Сервиса, Управление Непрерывностью ИТ-сервиса, Управление Финансами ИТ-сервиса, а также с Управлением Разработкой Приложений (напрямую или через Процесс Управления Изменениями).
244
Availability Plan.
14.4.8. Инструментальные средства
Для достижения эффективности Процесс Управления Доступностью должен использовать ряд инструментальных средств следующего назначения:
• определение времени простоя;
• фиксация исторической информации;
• создание отчетов;
• статистический анализ;
• анализ воздействия.
Процесс Управления Доступностью берет информацию из записей Процесса Управления инцидентами, Базы Данных CMDB и из Базы Данных Процесса Управления Мощностями (CL). Эта информация может храниться в специальной Базе Данных Процесса Управления Доступностью.
14.4.9. Методы и методики
В настоящее время существует широкий спектр методов и методик Управления Доступностью, которые помогают в проведении планирования, улучшения доступности и в составлении отчетов. Наиболее важные из них приведены ниже.
Анализ влияния отказа компонентов (CFIA) [245]
Данный метод предполагает использование матрицы доступности стратегических компонентов и их ролей в каждой услуге. При разработке такой матрицы очень полезной может оказаться база данных CMDB.
245
Component Failure Impact Analysis – CFIA.
Пример матрицы CFIA на рис. 14.4 показывает, что Конфигурационные Единицы, которые для многих услуг помечены символом «X», являются важными элементами ИТ-инфраструктуры (анализ по горизонтали) и что услуги, часто отмечаемые символом «X», являются комплексными и подвержены сбоям (анализ по вертикали). Этот метод также можно применять для изучения степени зависимости от сторонних организаций (усовершенствованный метод CFIA).
Конфигурационная единица | Услуга А | Услуга Б |
PC № 1 | B | B |
PC № 2 | B | |
Кабель № 1 | B | B |
Кабель № 2 | B | |
Разъем № 1 | X | X |
Разъем № 2 | X | |
Сегмент
| 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)
246
Fault Tree Analysis – FTA.
Анализ дерева неисправностей используется для определения цепочки событий, приводящих к сбою ИТ-сервиса. Для каждой услуги изображается отдельное дерево с использованием символов Буля. Дерево анализируется снизу вверх. Метод FTA выделяет следующие события:
• Основные события: входы на схеме (обозначены кружочками), такие как отключение электропитания и ошибки операторов. Эти события не исследуются.
• Результирующие события: узловая точка на схеме, появившаяся в результате объединения двух более ранних событий.
• Условные события: события, которые происходят только при определенных условиях, таких как отказ кондиционера.
• Запускающее событие: события, которые приводят к возникновению других событий, такие как автоматическое отключение, вызванное сигналом источника бесперебойного питания.
Рис. 14.5. Анализ дерева дефектов/сбоев (источник: OGC)
События можно объединять с логическими операциями, такими как:
• операция AND (И): результирующее событие произойдет, если будут присутствовать все входы одновременно;
• операция OR (ИЛИ): результирующее событие произойдет, если будет иметь место один или несколько входов;
• операция XOR (Исключающее ИЛИ): результирующее событие произойдет, если будет иметь место только один вход/причина;
• операция Inhibit (Запрет): результирующее событие произойдет, если не будут выполнены входные условия.