Управление обслуживанием
В обычной практике всегда бывают запланированные периоды недоступности сервиса. Эти периоды можно использовать для проведения превентивных действий, таких как обновление программного и аппаратного обеспечения, а также выполнения изменений. Однако в условиях непрерывного бизнеса становиться все труднее определить периоды, выделяемые для обслуживания. Проектирование, реализация и контроль деятельности по обслуживанию систем стали одним из важных направлений работы Процесса Управления Доступностью.
Обслуживание следует проводить в такие периоды, когда степень его воздействия на предоставление услуг является минимальной. Это значит, что необходимо заранее определить цели обслуживания, период его проведения, и какие работы при этом будут выполняться (для этого можно использовать метод Анализа влияния отказа компонентов — CFIA[12]). Такая информация об обслуживании очень важна для Процесса Управления Изменениями и для других процессов.
Проведение измерений и составление отчетов
Проведение измерений и составление отчетов являются важными видами деятельности в Процессе Управления Доступностью, т. к. они создают основу для верификации соглашений о предоставлении сервиса, для разрешения проблем и выработки предложений по улучшению сервиса.
Ц
икл
жизни инцидента включает в себя следующие
этапы:
• Возникновение инцидента: время, когда пользователь узнал о сбое или когда сбой был обнаружен (автоматически или вручную).
• Обнаружение: поставщик сервиса проинформирован о сбое. Инцидент получает статус «Сообщено». Затраченное на это время известно как время обнаружения.
• Реагирование: поставщику сервиса необходимо время, чтобы прореагировать на инцидент. Это время реагирования, оно используется для проведения диагностики, за которой следует выполнение ремонтных работ. В Процесс Управления Инцидентами входят такие виды работ, как Прием и Регистрация инцидентов, Классификация, Сопоставление, Анализ и Диагностика.
• Ремонт: поставщик сервиса восстанавливает компоненты, которые вызвали сбой.
• Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как конфигурирование и инициализация, и затем производится восстановление предоставления сервиса пользователям.
На рис. 14.3 показаны периоды времени, которые поддаются измерению.
Время/жизненный цикл
Рис. 14.3. Измерение доступности (источник: OGC)
Проведение измерений и составление отчетов
Как видно из рисунка, время реагирования ИТ-организации и внешних подрядчиков является одним из факторов, определяющих время простоя. Поскольку этот фактор непосредственно влияет на качество сервиса и ИТ-организация может его контролировать, то в соглашения об Уровне Сервиса можно включать договоренности относительно времени реагирования. При измерениях можно брать средние значения для получения правильного представления о соответствующих параметрах. Средние значения можно использовать для определения достигнутого Уровня Сервиса и для оценки ожидаемой в будущем доступности. Эту информацию можно использовать при разработке Планов Улучшения Сервиса.
В Процессе Управления Доступностью, как правило, используются следующие метрики:
§ Среднее время ремонта (Mean Time to Repair — MTTR): среднее время между возникновением сбоя и восстановлением сервиса, также известное как «простой». Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сервиса, как способность восстановления[13] и обслуживаемость[14].
§ Среднее время между сбоями (Mean Time Between Failures — MTBF): среднее время между восстановлением после одного сбоя и возникновением другого, также известное как «период работоспособного состояния» (uptime). Данная метрика относится к надежности сервиса.
§ Среднее время между системными инцидентами (Mean Time Between System Incidents — MTBSI): среднее время между двумя последовательными инцидентами. Данная метрика представляет собой сумму двух метрик MTTR и MTBF.
Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбоев или было несколько серьезных нарушений в работе.