Jan van Bon (стр. 51 из 60)
14.4.6. Проведение измерений и составление отчетов
Проведение измерений и составление отчетов являются важными видами деятельности в Процессе Управления Доступностью, т. к. они создают основу для верификации соглашений о предоставлении сервиса, для разрешения проблем и выработки предложений по улучшению сервиса.
- Если вы не измеряете, вы не можете управлять.
- Если вы не измеряете, вы не можете улучшать.
- Если вы не измеряете, вам, вероятно, все равно.
- Если вы не можете влиять, то не стоит и измерять.
Цикл жизни инцидента включает в себя следующие этапы:
- Возникновение инцидента: время, когда пользователь узнал о сбое или когда сбой был обнаружен (автоматически или вручную).
- Обнаружение: поставщик сервиса проинформирован о сбое. Инцидент получает статус "Сообщено". Затраченное на это время известно как время обнаружения.
- Реагирование: поставщику сервиса необходимо время, чтобы прореагировать на инцидент. Это время реагирования, оно используется для проведения диагностики, за которой следует выполнение ремонтных работ. В Процесс Управления Инцидентами входят такие виды работ, как Прием и Регистрация инцидентов, Классификация, Сопоставление, Анализ и Диагностика.
- Ремонт: поставщик сервиса восстанавливает компоненты, которые вызвали сбой.
- Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как конфигурирование и инициализация, и затем производится восстановление предоставления сервиса пользователям.
На рис. 14.3 показаны периоды времени, которые поддаются измерению.
Рис. 14.3. Измерение доступности (источник: OGC)
Как видно из рисунка, время реагирования ИТ-организации и внешних подрядчиков является одним из факторов, определяющих время простоя. Поскольку этот фактор непосредственно влияет на качество сервиса и ИТ-организация может его контролировать, то в соглашения об Уровне Сервиса можно включать договоренности относительно времени реагирования. При измерениях можно брать средние значения для получения правильного представления о соответствующих параметрах. Средние значения можно использовать для определения достигнутого Уровня Сервиса и для оценки ожидаемой в будущем доступности. Эту информацию можно использовать при разработке Планов Улучшения Сервиса.
В Процессе Управления Доступностью, как правило, используются следующие метрики:
- Среднее время ремонта (Mean Time to Repair – MTTR): среднее время между возникновением сбоя и восстановлением сервиса, также известное как "простой". Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сервиса, как способность восстановления[242]и обслуживаемость[243].
- Среднее время между сбоями (Mean Time Between Failures – MTBF): среднее время между восстановлением после одного сбоя и возникновением другого, также известное как "период работоспособного состояния" (uptime). Данная метрика относится к надежности сервиса.
- Среднее время между системными инцидентами (Mean Time Between System Incidents – MTBSI): среднее время между двумя последовательными инцидентами. Данная метрика представляет собой сумму двух метрик MTTR и MTBF.
Соотношение метрик 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)
Данный метод рассматривался в главе, посвященной Управлению Непрерывностью ИТ-сервиса.
Расчеты доступности сервиса
Описанные выше метрики можно использовать при заключении соглашений о доступности сервиса с заказчиками. Эти договоренности входят составной частью в Соглашения об Уровне Сервиса. Приведенная ниже формула помогает определить, отвечает ли достигнутый Уровень Доступности согласованным требованиям: