ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL
Шрифт:
Пример матрицы 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)
Анализ дерева неисправностей используется для определения цепочки событий, приводящих к сбою ИТ-сервиса. Для каждой услуги изображается отдельное дерево с использованием символов Буля. Дерево анализируется снизу вверх. Метод FTA выделяет следующие события:
246
Fault Tree Analysis – 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.
Основным достоинством данного метода является рациональный, эффективный и неформальный подход, который быстро дает результат.
14.5. Контроль процесса
14.5.1. Составление отчетов
Составление отчетов о доступности сервиса для заказчика обсуждалось выше. Для целей контроля процесса можно использовать следующие метрики:
? время обнаружения;
? время реагирования;
? время ремонта;
? время восстановления;
? оценка успешности использования соответствующих методов (CFIA, CRAMM, SOA);
? степень реализации процесса: услуги, Соглашения об Уровне Сервиса и группы заказчиков, попадающие под действия Соглашения об Уровне Сервиса.
Некоторые метрики можно задать для каждой услуги, команды или области инфраструктуры (сети, вычислительного центра и рабочей станции).
14.5.2. Критические факторы успеха и ключевые показатели эффективности
Критическими факторами успеха Процесса Управления Доступностью сервиса являются:
? наличие у бизнеса четко определенных целей и пожеланий в отношении доступности сервиса;
? налаженный Процесс Управления Уровнем Сервиса для обеспечения формализации соглашений;
? одинаковое понимание сторонами понятий доступности и простоя;
? понимание как бизнесом, так и ИТ-организацией преимуществ Управления Доступностью.
Об эффективности и рациональности Процесса Управления Доступностью свидетельствуют такие показатели эффективности, как:
? доступность сервиса в процентном выражении (время работоспособности) в проекции услуг или групп пользователей;