? Ремонт: поставщик сервиса восстанавливает компоненты, которые вызвали сбой.
? Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как конфигурирование и инициализация, и затем производится восстановление предоставления сервиса пользователям.
На рис. 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). Эта информация может храниться в специальной Базе Данных Процесса Управления Доступностью.
- 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
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125