Ч-4. ¥ОРАВДё;:УИЁ AOCryOHOCTfeiO

•рабочие часы заказчика;

•С1)гла1иеиия об «окнах» для планового обслуживания.

Четкое определение трсбоваши! к доступностп сервиса на jiannHx этапах позволяет избежать недоразумений и неправильного толкования договорегпюстсй на более поздних этапах. Требования заказчика необходимо сопоставлять с темп, котор]ле органпзаппя может предоставить. Ecjm выяв.11яется несоответствие, то следует определить влияние такого несоответствия на стоп-мость услуг.

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

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

Хорошее проектирование, выполненное с учетом стандартов доступности, позволит заключтггь с поставиппсами эффективные до10воры на обслуживание. При проектировании используется ряд методов, таких как Анализ степени влияния сбоя компонента (CFIA - см. раздел 14.4.9) для выявления отказов. вызван11ых наличием SPOF, методика ССТА по анали.зу и Управлению Рисками (CRAMM - см. главу «Управление Непрерывностью ИТ-сервиса») и методы моделирования. Если требования стандартов доступности не могут быть удовлетворены, лучпнтй путь - попытаться внести соот15етствующие усовернтенствования в проект. R обеспечении соответствия стандартам может помочь использование дополнительных технологий, других методов, инструментальных средств разработки, другой стратегии Управления Релизами, улучшение или измене1И1е нроцесса проектирования.

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

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

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

Задачи, отвстст1!епность и полномочия должны быть четко определены.

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

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

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

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

•определение видов авторизащти.

Single points of failures - 5ЮТ

Component Failure impact Analysis - CTIA

CCTA Risk Analysis and Manasement - СКАЛАМ.

14- уурдйлй:миг AOCiV«iS4<x.TivH..

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

В обычной практике всегда бывают запланированные периоды недоступноеги сервиса. Эти периоды можно попользовать для проведегшя превснтив1гых действий, гаких как обповлеиие про1-ралглн-1ого и аппаратного обеспечения, а также выполнения изменений. 0,чиако в условиях псп1)ерывного бизнеса становиться все труднее определить периоды, выделяемые для оба1уживания. Проектирование, реа/итзащтя и конт1Х)ль деятельности но обслужнваншо систем стали од1гим из важных направлений работы Процесса Управления Доступностью.

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

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

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

Если Вы ие намеряете, Бы пе можете управлять. Если Вы ие измеряете. Вы пе можете улучшать. Если Вы ие измеряете, Ван, вероятно, все равно. Если Вы tie можете влиять, то не стоит и излшрмтъ.

Цикл жизш! И1тцидепга вюночает в себя следчошие этапы;

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

•Обнаружение: поставщик сервиса проинформирован о сбое. Инцидеш- получает статус «Coo6nie-но». Затраченное на это время известно как время обнаружения.

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

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

•Восстановление сервиса: сервис восстановлен. При этом выполняются такие работы, как icoikjih-п>рирование и ипициaJИIзalия, и затем производится восстапавлеиие нредоставления сервиса пользователям.

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

Инцидент

Интервал между систеллныли инцидентами

Простой, время ремагга

Время

Время реагиро- вания .

Врем.яВремя

ремонта восстановления

Диагностика Время разрешения инцидента

Период работоспособного состояния.

интервал мел!АУ сбоями

Восстановление

Инцидент

Время/жизненный цикл

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

Component Failure Impact Analysis - CfIA

14. У-«1-У*ВА)гИИе AOCTVOsRiCTbSO

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

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

•Среднее время ремонта (Mean Time to Repair - MTTR): среднее время между возникновепием сбоя и восстановлением сервиса, также известное как «простой». Оно складывается из времени обнаружения сбоя и времени разрешения сбоя. Данная метрика относится к таким аспектам сервиса, как способность восстановления и обслуживаемость.

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

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

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

В отчеты о доступности сервиса могу т быть включены следующие метрики:

•Коэффициент доступности (или недоступности) сервиса, выраженный в метриках MTTR, MTBSI и MTBF;

•общее время работоспособного состояния и время простоя;

•количество сбоев:

•дополнительная ин()ормация о сбоях, которые могут привести в настоящее время или в будущем к более высокому Уровню Недоступности Систем, чем было заранее согласовано.

Проблема составления отчетов состоит в том, что представленные выше метрики могут не воспри-пиматься заказчиком. Поэтому отчеты о доступности сервиса должны составляться с точки зрения заказчика. Отчет в первую очередь должен давать информацию о доступности сервиса для наиболее важных бизнес-функций и о доступности данных (т. е. давать бизнес-представлепия), а не о доступности технических ИТ-компонентов. Отчеты должны быть написаны на понятном заказчику языке.

14.4.7. Разработка Плана Обеспечения Доступности

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

n.iiaii - эго живой документ. В начале ои должен дать описание текущей ситуации, а затем в пего можно включать рекомендации и конкретные виды работ по улучшению существующих услуг, а также предложения по вводу новых услуг и их обслуживанию. Для состав.пения полного п точного плана необходимо взаимодействие с такими Процессами, как Управление Уровнем Сервиса, Управление Непрерывностью ИТ-сервиса, Управление Финансами ИТ-сервиса, а также с Управлением Разработкой При.пожсний (напрямую или через Процесс Управления Изменениями).

Recoverability - Serviceability. Availability plan.