Чтение онлайн

ЖАНРЫ

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

Ван Бон Ян

Шрифт:

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
Сегмент сети 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)

246

Fault Tree Analysis – FTA.

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

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

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

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

отказ кондиционера.

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

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

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

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

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

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

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

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

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

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

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

247

CCTA Risk Analysis and Management Method – CRAMM.

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

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

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

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

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

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

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

248

System Outage Analysis – SOA.

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

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

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

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

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

249

Technical Observation Post – TOP.

Поделиться с друзьями: