ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

van Bon Jan

14.4.2. Проектирование систем для достижения требуемого Уровня Доступности

Следует как можно раньше выявить различные виды уязвимости, влияющие на доступность. Это позволит избежать неоправданно высокой стоимости разработки, незапланированных расходов на более поздних этапах, наличия Единой точки сбоя [238] (SPOF), дополнительных затрат по счетам поставщиков и задержек с выпуском релизов

Хорошее проектирование, выполненное с учетом стандартов доступности, позволит заключить с поставщиками эффективные договоры на обслуживание. При проектировании используется ряд методов, таких как Анализ степени влияния сбоя компонента [239] (CFIA –

см. раздел 14.4.9) для вы­явления отказов, вызванных наличием SPOF, методика CCTA по анализу и Управлению Рисками [240] (CRAMM – см. главу "Управление Непрерывностью ИТ-сервиса") и методы моделирования. Если требования стандартов доступности не могут быть удовлетворены, лучший путь – попытаться внести соответствующие усовершенствования в проект. В обеспечении соответствия стандартам мо­жет помочь использование дополнительных технологий, других методов, инструментальных средств разработки, другой стратегии Управления Релизами, улучшение или изменение процесса проекти­рования.

238

Single Points of Failures – SPOF.

239

Component Failure Impact Analysis – CFIA.

240

CCTA Risk Analysis and Management – CRAMM.

Если требования особенно высоки, то можно попытаться использовать другую отказоустойчивую технологию, другие Процессы Управления Услугами (Управление Инцидентами, Проблемами и Из­менениями) или дополнительные ресурсы Сервис-менеджмента. Выбор варианта во многом зависит от имеющихся финансовых средств.

14.4.3. Проектирование систем для достижения требуемого Уровня Обслуживания

Поскольку постоянная доступность бывает редко достижима, следует учитывать периоды возмож­ной недоступности сервиса. При прерывании сервиса важно быстро и правильно устранить сбой и попытаться достигнуть согласованных стандартов доступности. Проектирование процедур восстановления включает в себя такие аспекты, как использование эффективного Процесса Управления Инцидентами и соответствующие процедуры эскалации, оповещения, резервного копирования и восстановления. Задачи, ответственность и полномочия должны быть четко определены.

14.4.4. Ключевые вопросы безопасности

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

Среди вопросов могут быть следующие:

? определение лиц, имеющих право доступа в защищенные области;

? определение видов авторизации.

14.4.5. Управление Обслуживанием

В обычной практике всегда бывают запланированные периоды недоступности сервиса. Эти периоды можно использовать для проведения превентивных действий, таких как обновление программного и аппаратного обеспечения, а также выполнения изменений. Однако в условиях непрерывного бизне­са становиться все труднее определить периоды, выделяемые для обслуживания. Проектирование, реализация и контроль деятельности по обслуживанию систем стали одним из важных направлений работы Процесса Управления Доступностью.

Обслуживание следует проводить в такие периоды, когда степень его воздействия на предоставле­ние услуг является минимальной. Это значит, что необходимо заранее определить цели обслужива­ния, период его проведения, и какие работы при этом будут выполняться (для этого можно исполь­зовать метод Анализа влияния отказа компонентов – CFIA [241] ). Такая информация об обслуживании очень важна для Процесса Управления Изменениями и для других процессов.

14.4.6. Проведение измерений и составление отчетов

241

Component Failure Impact Analysis – CFIA.

Проведение

измерений и составление отчетов являются важными видами деятельности в Процессе Управления Доступностью, т. к. они создают основу для верификации соглашений о предоставлении сервиса, для разрешения проблем и выработки предложений по улучшению сервиса.

? Если вы не измеряете, вы не можете управлять.

? Если вы не измеряете, вы не можете улучшать.

? Если вы не измеряете, вам, вероятно, все равно.

? Если вы не можете влиять, то не стоит и измерять.

Цикл жизни инцидента включает в себя следующие этапы:

? Возникновение инцидента: время, когда пользователь узнал о сбое или когда сбой был обнаружен (автоматически или вручную).

? Обнаружение: поставщик сервиса проинформирован о сбое. Инцидент получает статус "Сообще­но". Затраченное на это время известно как время обнаружения.

? Реагирование: поставщику сервиса необходимо время, чтобы прореагировать на инцидент. Это время реагирования, оно используется для проведения диагностики, за которой следует выполне­ние ремонтных работ. В Процесс Управления Инцидентами входят такие виды работ, как Прием и Регистрация инцидентов, Классификация, Сопоставление, Анализ и Диагностика.

? Ремонт: поставщик сервиса восстанавливает компоненты, которые вызвали сбой.

? Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как конфи­гурирование и инициализация, и затем производится восстановление предоставления сервиса пользователям.

На рис. 14.3 показаны периоды времени, которые поддаются измерению.

Рис. 14.3. Измерение доступности (источник: OGC)

Как видно из рисунка, время реагирования ИТ-организации и внешних подрядчиков является од­ним из факторов, определяющих время простоя. Поскольку этот фактор непосредственно влияет на качество сервиса и ИТ-организация может его контролировать, то в соглашения об Уровне Сервиса можно включать договоренности относительно времени реагирования. При измерениях можно брать средние значения для получения правильного представления о соответствующих параметрах. Средние значения можно использовать для определения достигнутого Уровня Сервиса и для оценки ожидаемой в будущем доступности. Эту информацию можно использовать при разработке Планов Улучшения Сервиса.

В Процессе Управления Доступностью, как правило, используются следующие метрики:

? Среднее время ремонта (Mean Time to Repair – MTTR): среднее время между возникновением сбоя и восстановлением сервиса, также известное как "простой". Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сер­виса, как способность восстановления [242] и обслуживаемость [243] .

242

Recoverability.

243

Serviceability.

? Среднее время между сбоями (Mean Time Between Failures – MTBF): среднее время между восстановлением после одного сбоя и возникновением другого, также известное как "период рабо­тоспособного состояния" (uptime). Данная метрика относится к надежности сервиса.

? Среднее время между системными инцидентами (Mean Time Between System Incidents – MTBSI): среднее время между двумя последовательными инцидентами. Данная метрика пред­ставляет собой сумму двух метрик MTTR и MTBF.

Соотношение метрик MTBF и MTBSI помогает понять, имело ли место много незначительных сбо­ев или было несколько серьезных нарушений в работе.