назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [ 60 ] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


60

!4. У611*АВЛГ.НИ£ ДОС-ГУкЛ-НкЛЫО

14.4.8.Инструментальные средства

Для достижения эффектипиостн Процесс Управле(И1я Доступностью должен исиользовать ряд инструментальных средств следующего назначения;

•определение времени простоя;

•фиксация исторической информации;

•создание отчетов;

•статистический апалггз;

•анализ воздействия.

Процесс Управления Доступностью берет 1П1()ормацию из записей Процесса Управления Инцидентами, Базы Данных CMDB и из Базы Данных Процесса Уиравления Мощностями (CDB). Эта ин-({юрмация можег храниться в специальной Базе Данных Процесса Управления Доступностью.

14.4.9.Методы и методики

В настоящее время существует широкий спектр методов и методик Управления Доступностью, ко-горые помогают в проведении плашфоватш, улучшения дсютуппости и в составлении отчетов. Наиболее важные из них приведены 1шже.

Анализ влияния отказа компонентов (CFIA)

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

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

Конфигурационная единица

Услуга А

Услуга Б

РС№1

PC №2

Кабель №1

кабель №2

Разъем № 1

Разъем № 2

Сегмент сети Ethernet

Маршрутизатор

Канал глобальной сети (WAN)

Маршрутизатор

Сегмент

Сетевой инфоршционный центр

Сервер

Системное программное

обеспечение

Приложения

База дангш

X - сбой/дефект означает, что услуга недоступна А - безотказная конфигурация В - безотказная конфигурациях переключением • • - нет воздействия

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

Availability Магизетеш Database - AMDB. Component Failure Impact Analysis - CfIA



14. УПтйАШИЕ ДОСТУЙОСГЬЮ

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

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

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

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

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

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

Недоступность услуги

Запрет

Вне рабочего времени?

Систечв недоступна

Отказ приложения

Отказ обычного канала связи

Отказ резервного канала связи

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

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

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

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

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

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

fault Tree Analysis - FTA.



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

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

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

Достигнутое время работоспосбоности Согласованное время работоспособности

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

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

(5}i12- 2)/(5 X 12) X 100% = 96,7%

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

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

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

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

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

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

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

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

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

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

14.5. Контроль процесса 14.5.1. Составление отчетов

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

ССТА Risk Anarysis and Management Method - CRAMM System CXitage Analysis - SOA Technical Obsen/ation Post - ТСЭР

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [ 60 ] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]