, автор Стюарт Ренс (Stuart Rance).

Доступность ИТ-услуг имеет большое значение. Когда услуги, необходимые заказчику, недоступны, он будет недоволен. Почему заказчик должен платить за услугу, которой в реальности нет тогда, когда он в ней нуждается? Именно поэтому согласованный показатель доступности услуг часто входит в KPI.

Сотрудники ИТ-службы прикладывают много усилий, чтобы убедиться, что обозначенная цель достигнута и показать в отчетах заказчикам цифры, подтверждающие это. Обычно ИТ-компании используют для этого проценты, например, 99,999%. К сожалению, зачастую это означает, что они сосредотачиваются только на процентном измерении и упускают из виду свою истинную цель - приносить пользу заказчику.

Проблема с процентной доступностью

В основе одного из простейших способов расчета доступности лежат две части. Вы согласуете временные интервалы, в течение которых услуга должна быть доступна в отчетном периоде. Это — согласованное время обслуживания (AST). Вы измеряете время простоя (DT) в течение этого периода. Вычитаете время простоя от согласованного срока доступности сервиса и превращаете это в процент.

Если AST составляет 100 часов и время простоя 2 часа, доступность будет такой:

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

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

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

Определение целевых показателей доступности

Если вы хотите измерять, документировать и отчитываться о доступности таким образом, чтобы это было полезно для вашей организации и ваших заказчиков, вам нужно сделать две вещи. Во-первых, определить контекст и закрепить смысл понятия "доступность" для вас и ваших заказчиков. Для этого вам нужно поговорить с ними.

Во-вторых, вам следует тщательно продумать ряд практических вопросов: что вы будете измерять, как вы будете собирать данные, как будете их документировать и сообщать о полученных результатах.

Общение с заказчиками

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

Но что именно сказать заказчикам? Отличной отправной точкой для разговора может стать влияние времени простоя. Ниже приведены пять вопросов, которые вы должны задать:

1. Какие бизнес-функции являются критически значимыми и имеют важнейший приоритет в защите от простоя?
2. Как время простоя влияет на бизнес?
3. Как частота простоя влияет на бизнес?
4. Какое влияние простои оказывают на производительность организации?
5. Как эти вынужденные простои воспринимают заказчики организации?

Критически значимые бизнес-функции

Большинство ИТ-услуг поддерживают несколько бизнес-процессов, некоторые из которых являются критическими, а другие менее важны. Например, банкомат может поддерживать выдачу наличных и печать чеков. Способность распределять наличные деньги имеет решающее значение, в то время как неспособность напечатать чек оказывает гораздо меньшее влияние.

Вам нужно поговорить с заказчиками и определить степень важности различных функций для бизнеса. Вы можете составить таблицу, в которой отметить последствия для бизнеса, которые несёт простой каждой из этих функций. Пример:

Таблица 1 - Важность услуг в процентном соотношении

NB : Цифры не должны в сумме давать 100%

Из этой таблицы видно, что данная услуга вообще не имеет значения, если нет возможности отправлять и получать электронные письма, и её ценность уменьшается до половины нормального уровня, если общедоступные папки не могут быть прочитаны. Это говорит ИТ-службе, что нужно сосредоточиться на качестве работы почтовой службы.

Продолжительность и частота простоя

Вам нужно выяснить, как на бизнес заказчика влияет частота и продолжительность простоя.

Я уже упоминал, что процентная доступность может быть недостаточной. Когда услуга, которая должна быть доступна в течение 100 часов, имеет 98% доступность, это показывает, что было два часа простоя. Но это может означать как один двухчасовой, так и несколько более коротких инцидентов. Относительное влияние одного длительного инцидента или ряда коротких инцидентов будет различным, в зависимости от характера бизнеса и бизнес-процессов.

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

Вот пример того, как можно измерить и документировать доступность, чтобы отразить тот факт, что влияние времени простоя варьируется:

Таблица 2 - Длительность отключения и максимальная частота

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

Время простоя и производительность

Я упоминал, что процентная доступность не очень полезна для общения с заказчиками о частоте и продолжительности простоя. С другой стороны, когда вы обсуждаете влияние простоя на производительность, процентное взаимоотношение может очень пригодиться.

Большинство инцидентов не вызывают полной потери обслуживания для всех пользователей. Некоторые пользователи могут быть не затронуты, в то время как другие полностью отключены. Может быть, есть всего один пользователь с неисправным ПК, который не может получить доступ к каким-либо услугам. Вы даже можете классифицировать это как потерю обслуживания на 100%, но это будет совершенно недостижимая цель для ИТ и не может являться справедливым критерием доступности.

С другой стороны, вы можете сказать, что услуга доступна, пока кто-то все еще может получить к ней доступ. Тем не менее, не нужно много воображения, чтобы понять, как будут чувствовать себя заказчики, если услуга будет значиться, как доступная, в то время как многие люди просто не могут ею воспользоваться.

Одним из способов определения воздействия является вычисление процента потерянных пользовательских минут. Чтобы сделать это:

• Вычислите PotentialUserMinutes. Это общее количество пользователей, которые работают в единицу времени. Например, если у вас 10 сотрудников, которые работают в течение 8 часов, то PotentialUserMinutes — это 10 x 8 x 60 = 4800
• Вычислите UserOutageMinutes. Это общее количество пользователей, которые не могли работать, умноженные на время, когда они не смогли работать. Например, если инцидент помешал 5 сотрудникам работать в течение 10 минут, то UserOutageMinutes — 50.
• Рассчитайте процентную доступность, используя очень похожую формулу на ту, что мы видели ранее

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

Вы можете использовать эту же методику для расчета влияния потерянной доступности IP-телефонии в колл-центре с точки зрения PotentialAgentPhoneMinutes и LostAgentPhoneMinutes; в случае приложений, которые занимаются транзакциями или производством, вы можете использовать аналогичный подход для количественной оценки воздействия инцидента на бизнес. Вы сравниваете количество транзакций, которые ожидались бы без простоя, по отношению к количеству фактических транзакций или объема производства, который предполагался по отношению к фактическому.

Измерение доступности и отчётность

После того, как вы согласовали и задокументировали целевые показатели доступности, нужно подумать о практических аспектах того, как вы можете измерять и сообщать о доступности. Например:

• Что вы будете измерять?
• Как вы будете собирать данные?
• Как вы будете документировать свои выводы и сообщать о них?

Что измер я ть

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

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

Как собирать данные

Существует много различных путей сбора данных о доступности ИТ-услуг. Некоторые из них просты, но не слишком точны, некоторые достаточно дороги. Вы можете использовать только один подход, или комбинировать несколько из них для создания своих отчетов.

Сбор данных в технической поддержке

Один из способов сбора данных о доступности — через службу поддержки. Обычно сотрудники службы определяют влияние и продолжительность каждого инцидента на бизнес, поскольку это - часть управления инцидентами. Эти данные вполне можно использовать для определения продолжительности инцидентов и количества затронутых пользователей.

Данный подход, как правило, довольно недорогой. Однако может привести к спорам о точности данных о доступности.

Измерение доступности инфраструктуры и приложений

Этот подход включает в себя инструментарий для всех компонентов, необходимых для обеспечения услуги, и расчета доступности на основе понимания того, какой вклад вносит каждый компонент.

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

Фиктивные заказчики

Некоторые компанию используют фиктивных заказчиков для отправки известных транзакций из определенных точек в сети, чтобы проверить доступность.

Фактически — это измерение сквозной доступности. В зависимости от размера и сложности сети, внедрение этого подхода может быть достаточно дорогостоящим, к тому же он сообщает только о доступности от конкретных фиктивных заказчиков. Это значит, что небольшие сбои могут быть пропущены, например, если инцидент привел к некорректной работе определенного веб-браузера, тогда как фиктивный заказчик использует другой браузер.

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

Доработка приложений

Некоторые компании добавляют в свои приложения специальный код, чтобы следить за сквозной доступностью. Это поможет реально измерить сквозную доступность услуг при условии, что эта задача ставилась на момент разработки приложения. Как правило, эта доработка включает код как в клиентском приложении, так в серверной части.

Если она будет реализована хорошо, то сможет не только собирать данные о доступности, но и поможет точно определить, где именно произошел сбой, что поможет повысить доступность за счет сокращения времени, необходимого на решение инцидентов.

Как документировать и сообщать о своих выводах

Когда вы собрали данные о доступности, вам необходимо подумать о том, как сообщить о результатах своим заказчикам.

Планируйте время простоя

Один аспект измерения доступности и отчетности, который часто упускается из виду, — это время простоя. Если вы не будете учитывать планируемое время простоя при разработке отчетов о доступности, вы рискуете включить в них показатели, которые не соответствуют действительности.

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

Независимо от того, что вы решите сделать, важно, чтобы ваше SLA четко определяло, как будет учитываться запланированное время простоя.

Соглашение об отчетном периоде

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

Например, рассмотрим ИТ-компанию, которая согласилась на услугу 24×7 и доступность 99%. Предположим, что произошел восьмичасовой перерыв:

• если мы отчитываемся о доступности еженедельно, то AST (согласованное время обслуживания) составляет 24 x 7 часов = 168 часов
• ежемесячно AST (24 x 365) / 12 = 730 часов
• ежеквартально AST (24 x 365) / 4 = 2190 часов

Ввод этих чисел в уравнение доступности дает:

• Еженедельная доступность = 100% x (168-8) / 168 = 95,2%.
• Ежемесячная доступность = 100% x (730 — 8) / 730 = 98,9%
• Квартальная доступность = 100% x (2190-8) / 2190 = 99,6%

Каждый из них является действительным показателем доступности службы, но только один из них показывает, что цель была выполнена.

В заключении

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

Это длинная статья, ниже перечислены ключевые моменты, которые затронуты в ней:

• Не нужно говорить заказчику, что вы предоставили 98% -ную доступность, если у вас нет понимания влияния 2-процентного времени простоя
• Поговорите со своими заказчиками и убедитесь, что вы понимаете влияние любого простоя на них и на конечных заказчиков
• Подумайте о способах защиты критических бизнес-процессов ваших заказчиков
• Найдите способы измерения частоты и продолжительности простоя, также степени влияния времени простоя на производительность, которые соответствуют потребностям ваших заказчиков
• Согласуйте, документируйте и указывайте показатели доступности способами, которые имеют смысл для ваших заказчиков и помогают планировать
• Используйте соответствующие инструменты, чтобы правильно оценить доступность и сообщить в отчете.

Что еще вы могли бы добавить к моим советам? Пожалуйста, пишите в комментариях.

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

Несколько часов простоя компьютера могут иметь серьезные последствия для бизнеса и репутации компании на рынке, особенно сейчас, когда Интернет превращается в электронный вариант рынка. В этом электронном мире конкурентов друг от друга отделяет простое нажатие на клавишу «мыши». В этой связи особенно важным фактором становится степень удовлетворенности заказчиков. Эта одна из причин, почему в настоящее время вычислительные системы должны быть доступны 24 часа в сутки семь дней в неделю.

14.1.1. Основные понятия

На рис. 14.1 схематично представлены базовые понятия процесса Управления Доступностью.

Рис. 14.1. Концептуальные понятия процесса Управления Доступностью (источник: OGC)

Доступность

Высокий Уровень Доступности означает, что заказчик имеет практически постоянный доступ к ИТ-сервису благодаря сокращению времени простоя и быстрому восстановлению предоставления услуг. Уровень Доступности определяется с помощью метрик. Доступность сервиса зависит от:

Сложности ИТ-инфраструктуры;

Надежности компонентов;

Способности быстро и эффективно реагировать на сбои;

Качества обслуживания и качества работы поддерживающих организаций и поставщиков;

Качества и границ компетенции процессов операционного управления.

Надежность, в контексте данного процесса, означает доступность сервиса в течение согласованного периода времени без каких-либо сбоев. Эта концепция включает в себя понятие устойчивости . Надежность сервиса будет возрастать, если предпринимать превентивные меры против возникновения простоев. Надежность сервиса является статистическим показателем и определяется сочетанием следующих факторов:

Надежность компонентов, используемых для предоставления сервиса;

Способность сервиса или его компонентов эффективно функционировать, несмотря на сбой одной или нескольких подсистем (устойчивость);

Профилактическое обслуживание для предотвращения простоев.

Понятия «обслуживание» и «способность к восстановлению» предполагают выполнение работ по обеспечению функционирования сервиса и его восстановлению после сбоев, а также проведение профилактического обслуживания и регламентных (плановых) проверок, а именно:

Принятие мер по предотвращению сбоев;

Своевременное обнаружение сбоев;

Проведение диагностики, включая автоматическую самодиагностику компонентов;

Ликвидация сбоев;

Восстановление функционирования после сбоя;

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

Предоставление сервиса внешними поставщиками

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

14.2. Цели процесса

Целью Процесса Управления Доступностью является обеспечение рентабельного и согласованного Уровня Доступности ИТ-сервиса, который поможет бизнесу в достижении поставленных целей. Такое определение цели процесса означает, что потребности заказчика (бизнеса) должны соответствовать тому, что могут предложить ИТ-инфраструктура и организация. Если имеется расхождение между спросом и предложением, тогда Процесс Управления Доступностью должен предложить выход из такой ситуации. Более того, данный процесс гарантирует оценку достигнутых Уровней Доступности и их дальнейшее совершенствование в случае необходимости. Это означает, что в рамках процесса выполняются как проактивные, так и реактивные виды деятельности. При разработке процесса следует исходить из следующих предпосылок:

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

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

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

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

14.2.1. Преимущества использования процесса

Основное преимущество, которое дает Процесс Управления Доступностью, состоит в том, что услуги, разработанные, внедренные и находящиеся под Управлением ИТ-организации, отвечают требованиям, предъявляемым к доступности сервиса. Полное понимание бизнес-процессов заказчика и информационных технологий в сочетании с постоянным стремлением максимально расширить доступность сервиса в разумных пределах могут во многом содействовать формированию реальной культуры сервиса. Другие преимущества данного процесса состоят в следующем:

Создание единой точки контактов по вопросам доступности продуктов и услуг и наличие одного человека, отвечающего за эти вопросы;

Гарантируется соответствие новых продуктов и услуг предъявляемым к ним требованиям и согласованному с заказчиком стандарту доступности;

Уровень Затрат поддерживается на приемлемом уровне;

Постоянный мониторинг стандартов доступности и их совершенствование по мере необходимости;

В случае недоступности сервиса выполнение восстановительных мероприятий, соответствующих ситуации;

Уменьшение количества отказов в доступе к системам и сокращение периода недоступности сервиса;

Смещение акцентов с исправления дефектов на улучшение сервиса;

Простота обоснования добавочной стоимости для ИТ-организации.

Процесс Управления Доступностью связан со следующими процессами ITIL.

Управление Уровнем Сервиса

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

Управление Конфигурациями

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

Управление Мощностями

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

Управление Непрерывностью Сервиса

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

Управление Проблемами

Процесс Управления Проблемами непосредственно участвует в обнаружении причин существующих и потенциальных проблем в сфере доступности сервиса и в их устранении.

Управление Инцидентами

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

Управление Безопасностью

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

Конфиденциальность;

Целостность;

Доступность.

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

Управление Изменениями

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

14.3. Процесс

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

Рис. 14.2. Входы и выходы Процесса Управления Доступностью (источник: OGC)

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

Входами для Процесса Управления Доступностью являются (рис. 14.2):

Требования бизнеса к доступности;

Оценка влияния на все бизнес-процессы, поддерживаемые ИТ;

Требования к доступности, надежности и обслуживанию ИТ-компонентов инфраструктуры;

Данные о неисправностях, затрагивающих услуги или их компоненты, обычно в форме записей и отчетов об инцидентах и проблемах;

Данные о конфигурациях услуг и их компонентах и данные мониторинга;

Достигнутые Уровни Сервиса в сравнении с согласованными уровнями для всех услуг, оговоренных в соглашении о предоставлении сервиса.

Выходы :

Критерии разработки архитектуры для обеспечения доступности и восстановления новых и улучшаемых ИТ-услуг;

Технология, обеспечивающая устойчивость инфраструктуры и позволяющая уменьшить или устранить воздействие дефектных компонентов;

Гарантии доступности, надежности и обслуживания компонентов инфраструктуры, необходимые для предоставления ИТ-сервиса;

Отчеты о достигнутых Уровнях Доступности, надежности и обслуживания;

Требования к мониторингу доступности, надежности и обслуживания;

План обеспечения доступности для проведения проактивного улучшения ИТ-инфраструктуры.

14.4. Виды деятельности

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

Планирование

Определение требований к доступности сервиса;

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

Проектирование систем для достижения требуемой способности восстановления ;

Вопросы безопасности;

Управление обслуживанием;

Разработка Плана Доступности.

Мониторинг

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

Ниже дается описание основных видов деятельности.

14.4.1. Определение требований к доступности сервиса

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

Ключевые бизнес-функции;

Согласованный период простоя ИТ-сервиса;

Количественная оценка требований к доступности сервиса;

Количественная оценка воздействия незапланированного простоя на бизнес-функции;

Рабочие часы заказчика;

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

Четкое определение требований к доступности сервиса на ранних этапах позволяет избежать недоразумений и неправильного толкования договоренностей на более поздних этапах. Требования заказчика необходимо сопоставлять с теми, которые организация может предоставить. Если выявляется несоответствие, то следует определить влияние такого несоответствия на стоимость услуг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Количество сбоев;

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

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

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

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

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

14.4.8. Инструментальные средства

Для достижения эффективности Процесс Управления Доступностью должен использовать ряд инструментальных средств следующего назначения:

Определение времени простоя;

Фиксация исторической информации;

Создание отчетов;

Статистический анализ;

Анализ воздействия.

Процесс Управления Доступностью берет информацию из записей Процесса Управления инцидентами, Базы Данных CMDB и из Базы Данных Процесса Управления Мощностями (CL). Эта информация может храниться в специальной Базе Данных Процесса Управления Доступностью.

14.4.9. Методы и методики

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

Анализ влияния отказа компонентов (CFIA)

Данный метод предполагает использование матрицы доступности стратегических компонентов и их ролей в каждой услуге. При разработке такой матрицы очень полезной может оказаться база данных 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 (

«Доступность», «три девятки после запятой» — эти термины часто употребляют при обсуждении новых ИТ-решений. ИТ‑архитекторы предлагают заказчику проект новой системы, особенно обращая внимание на то, что она обладает очень высокой доступностью. Контракт заключен, система построена, акты о сдаче комплекса подписаны, начинается эксплуатация… Именно на стадии эксплуатации можно проверить «качество» созданной системы, и именно тогда может наступить разочарование. Что же скрывается за магическими «девятками»? Что в действительности обещают на этапе проектирования? И кто отвечает за доступность?

Доступность: введение в предмет

Самый правильный способ понять, что такое доступ­ность, - разобраться, зачем она нужна. До­ступность - это характеристика того, что хочет получить бизнес от ИТ‑службы. К сожалению, некоторые представители бизнеса на вопрос о желаемой доступности ИТ-услуги отвечают примерно следующее: «Хочу, чтобы всё всегда работало». В этом случае писать техническое задание на услугу приходится ИТ-менеджеру, в том числе определяя параметры доступности. Итак, доступность - это параметр ИТ-услуги, которую потребляет бизнес и которую предоставляет ИТ‑служба. Формула расчета доступности такова:

Availability = (AST - DT)/AST×100 = Servise or Component Availability (%)

где
AST (agreed service time) - согласованное время предоставления услуги;
DT (actual downtime during agreed service time) - фактическое время, когда услуга была недоступна в течение согласованного времени её предоставления.

Особенности расчета доступности проще понять на конкретном примере. Попробуем определить доступность ИТ-услуги «интернет-магазин» для компании ААА, расположенной в Москве, которая продает книги. При этом книги и их доставку в любой город можно оплатить, например, с помощью кредитной карты. Очевидно, что заказы на доставку будут обрабатываться только в рабочие дни с 9 до 18.

Но каким будет AST - согласованное время предоставления услуги? Для ответа на этот вопрос необходимо учесть, что люди могут размещать заказы в нерабочее время, и обязательно взять в расчет то, что в России 11 часовых поясов. Следовательно, предоставлять услугу надо 24 часа в сутки 7 дней в неделю.

Теперь нужно разобраться с DT - временем, когда услуга может быть недоступна. Здесь без переговоров с бизнесом не обойтись. Вполне возможно, что четыре часа недоступности услуги один раз в месяц может быть вполне адекватным выбором для данного примера. Однако надо учесть один нюанс - период времени, в течение которого проводится оценка параметра DT, то есть собственно согласованное время предоставления услуги (AST). Выбор периода AST - личное дело договаривающихся сторон: бизнеса и ИТ‑службы. В качестве такого периода лучше взять неделю или несколько недель, так как месяц или год - величины непостоянные (включают разное количество дней). Однако нужно обращать внимание и на психологию: более короткие периоды времени могут быть негативно восприняты бизнесом. В нашем примере то же самое значение доступности соответствует простою примерно час в неделю. Однако бизнесу может не понравиться, что интернет-магазин будет недоступен в течение часа каждую неделю, хотя на четыре часа простоя в месяц он может согласиться. С другой стороны, иногда невозможно эксплуатировать ИТ‑систему без того, чтобы не остановить её на несколько часов для плановых работ по обслуживанию. Такие плановые простои тоже должны быть учтены при выборе DT, что, в свою очередь, может привести к пересмотру параметра AST.

Исходя из вышеизложенного мы выбираем 4 часа недоступности услуги один раз в течение четырех недель. То есть AST = 4 недели, DT = 4 часа. Тогда доступность такова:

Availability = (24×7×4–4)/(24×7×4)×100% = 99,40%

Вполне возможно, что бизнес будет не согласен. В этом случае нужно выяснить, на какой вариант он согласится. В дальнейшем можно просчитать два варианта аппаратно-программных комплексов с различной доступностью и переговоры с бизнесом вести, основываясь на сравнении стоимости обоих вариантов. Вообще переговоры с бизнесом и бюджетирование ИТ‑службы - это отдельная тема, для раскрытия которой, пожалуй, по­требуется не одна книга. Поэтому допустим, что в нашем примере доступность посчитана и согласована и можно переходить к созданию системы.

Обратите внимание, что мы определили необходимую доступность до того, как стали работать над решением, которое ее обеспечивает, а не наоборот - сначала выбрали решение и стали считать его доступность. Техническое задание первично, а требуемая доступность - это один из параметров, зафиксированный в нём. Когда система будет сдана в эксплуатацию, доступность должна соответствовать требуемому значению. Поэтому мы советуем в соглашении с бизнесом (SLA - Service Level Agreement) подробно расшифровать, что подразумевается под цифрой доступности (в нашем примере так: «4 часа недоступности услуги один (1) раз в течение четырех (4) недель»), чтобы все стороны однозначно понимали, чтó действительно скрывается за цифрами.

Три составляющие доступности

Самое первое, что нужно осознать при выборе решения, - это из чего состоит доступность ИТ-услуги. Множество разочарований во время эксплуатации объясня­ется тем, что доступность услуги, которую хочет получить бизнес, напрямую связывают с доступностью оборудования. Однако доступность ИТ-услуги представляет собой совокупность трех составляющих:
1) Reliability - обычно переводится как надежность;
2) Maintainability - переводится как «обслуживаемость»;
3) Serviceability - ремонтопригодность.
Разберем каждый из этих пунктов.

Reliability

Reliability - это доступность инфраструктуры или аппаратно-программного комплекса в целом, включая коммуникации. Например, для интернет-магазина нам нужен веб‑сервер, сервер приложений, СУБД, дисковое хранилище и доступ в Интернет. Для простоты будем считать, что программное обеспечение «сервер приложений» включает в себя веб‑сервер и будет установлено на одном аппаратном сервере, СУБД - на втором, а дисковое хранилище представляет собой внешний дисковый массив.

Начинаем творить - строим проект инфраструктуры. Под каждым компонентом напишем параметры его доступности. Доступность каждого компонента - далее будем пользоваться термином «надежность» - должна быть получена от поставщика компонента (оборудования, программного обеспечения или услуги). Если это по каким‑либо причинам невозможно (например, для программных компонентов значение надежности, как правило, неизвестно) - искомую величину придётся самостоятельно оценить и назначить. Каждый компонент является единой точкой отказа, поэтому на рабочей схеме для расчета надежности они соединены последовательно (рис. 1). Заметим, что это не схема соединения компонентов инфраструктуры, а лишь схема расчета надежности.

Итак, рассчитываем надежность. Поскольку у нас последовательное соединение компонентов, то величины надежности перемножаются:

Reliability = (0,985×0,97×0,975×0,98×0,99×0,9999×0,99)×100%= 89,47%

Это явно недостаточно по сравнению с требуемым значением 99,40%. Тогда изменим решение - включим в систему альтернативного поставщика услуг доступа в Интернет (рис. 2) и рассчитаем его надежность. Поскольку относительно интернет-доступа мы имеем параллельное соединение, общая надежность определяется следующим образом:

Общая надежность =

Reliability = ×100% = 91,72%

Думаю, что принцип «работы с надежностью» будущей системы продемонстрирован. Следует обратить внимание, что в рассмотренном примере не фигурировали компоненты сетевой инфраструктуры и надежность соединений (например, между сервером базы данных и дисковым хранилищем), а также компоненты технической инфраструктуры (электропитание, кондиционирование и т. п.), которые также являются точками отказа и должны быть включены в расчет. Отдельного внимания заслуживает оценка надежности программных компонентов. Здесь основной совет заключается в разумном консерватизме: использовать программные компоненты, которые эксплуатируются в подобных решениях продолжительное время и хорошо себя зарекомендовали.

С помощью приемов, которые были кратко рассмотрены выше, можно выбрать решение с требуемой доступностью.

Maintainability и Serviceability

Переходим к другим составляющим до­ступ­нос­ти - maintainability и serviceability. Замечу, что переводы «обслуживаемость» и «ремонтопригодность» неудачны, поскольку из них малопонятно, что это значит. Лучше использовать более понятные переводы: maintainability - деятельность внутренней ИТ‑службы организации; serviceability - услуги, предоставляемые внешними поставщиками.

Чтобы прояснить ситуацию, рассмотрим крайние варианты. В каком случае полностью отсутствует maintainability (деятельность внутренней ИТ‑службы организации)? Это бывает, когда компания собственную ИТ‑службу отдает на аутсорсинг. Здесь доступность складывается только из надежности и услуг, предоставляемых внешними поставщиками.

В каком случае полностью отсутствует serviceability (услуги, предоставляемые внешними поставщиками)? Это происходит, например, в ФСБ, которая из соображений секретности всю деятельность по поддержанию системы в рабочем состоянии вынуждена вести исключительно силами своего ИТ-подразделения, даже запчасти покупаются самостоятельно, а не поставляются в рамках контракта технической поддержки. Тогда доступность складывается только из надежности системы и деятельности внутренней ИТ‑службы организации.

Понятно, что выбирать решение нужно одновременно с проработкой схем обеспечения maintainability и serviceability. В целом reliability, maintainability и serviceability - это три составляющие доступности. Изменение одной из них должно быть скомпенсировано изменениями двух других - иначе изменится параметр доступности ИТ-услуги, что может нанести ущерб бизнесу.

Способы манипулирования составляющими доступности

Чтобы понять, каким образом можно манипулировать всеми составляющими доступности, рассмотрим другой практический пример. Компания, имеющая центры обработки данных в двух городах России, Зеленограде (город - спутник Москвы) и Иркутске, приобрела две одинаковые системы «под ключ». Следовательно, надежность - reliability - у них одинаковая. Обе ИТ‑системы были обеспечены одинаковыми контрактами технической поддержки на аппаратную и программную части, значит, услуги, предоставляемые внешними поставщиками, - serviceability - также были одинаковы. Однако доступность систем оказалась разная. И компания стала жаловаться поставщику на плохую доступность системы в Иркутске, утверждая, что одно из решений «бракованное», и требуя провести его аудит.

Однако в данном случае аудит решения скорее всего не выявит корневую причину «провала» доступности, так как будет исследована только одна составляющая - Reliability, которая должна быть одинаковой у обеих систем, а исследовать нужно как раз две другие составляющие. Если обратить внимание на них, то выяснится, что возможны два варианта.

Вариант 1: к потере доступности привели аппаратные сбои. Из-за географического положения центров обработки данных одинаковые контракты технической поддержки аппаратной части на самом деле могут оказаться разными. Например, сервисный центр внешнего поставщика расположен в Москве, а в контракте технической поддерж­ки написано, что он действует только в рабочие дни и инженер прибывает на место установки оборудования «первым доступным железнодорожным или авиарейсом». Очевидно, что для инженера, отбывающего из Москвы, эта величина будет разной для Зеленограда и Иркутска.

Возможные варианты решения проблемы с доступностью в этом случае:

• изменить надежность ИТ‑системы в Иркутске, например поставить дополнительный узел в кластер;
• изменить параметр serviceability - создать склад в Иркутске, получить возможность для ИТ‑специалистов компании самостоятельно менять неисправные компоненты, если это не противоречит правилам производителя.

Кроме того, имеет смысл проверить условия эксплуатации. Примеры типичных нарушений этих условий:

• проведение ремонтных работ в помещениях при включённых системах, что приводит к их запыленности, а пыль очень опасна для серверного оборудования;
• использование бытовых кондиционеров в серверных комнатах, хотя у каждого вида оборудования есть свои требования по влажности и бытовые кондиционеры не рассчитаны на поддержание её заданного уровня, а совершенно сухой воздух губителен для техники.

Вариант 2: к снижению требуемого уровня доступности привели программные сбои. В этом случае скорее всего проблема в ИТ‑службе в Иркутске. Услуги технической поддержки программного обеспечения предоставляются в дистанционном режиме. Следовательно, разницы в услугах нет за исключением того, что для разных часовых поясов существуют различные периоды предоставления услуг по отношению к местному времени, но это, как правило, существенного влияния не оказывает. Вероятной при­чиной «провала» доступности здесь является разный уровень профессионализма ИТ‑департаментов - в Иркутске он наверняка ниже, чем в Зеленограде. Возможные ре­шения:

• подтянуть maintainability до нужного уровня - провести обучение ИТ-персонала в Иркутске по программным и аппаратным продуктам, входящим в состав ИТ‑системы, организовать семинары по передаче опыта ИТ-команды из Зеленограда, скопировать процессы эксплуатации и т. п.;
• компенсировать maintainability за счет serviceabi­lity - приобрести расширенные услуги технической поддерж­ки, услуги ауттаскинга и т. п.

Если вернуться к нашему примеру с интернет-магазином, то какое сочетание reliability, maintainability и serviceability будет оптимальным? Ответ на этот вопрос зависит от каждого конкретного случая. Например, можно порекомендовать хостинг вместо того, чтобы полностью реализовывать всю инфраструктуру (ИТ и техническую) самостоятельно. В общем случае имеем следующие типовые способы управления доступностью. 1. Изменение reliability (надежности):

• изменение ИТ-решения в сторону высокой доступности (High Availability) - использование кластеров, применение оборудования с поддержкой «горячей» замены, неоднократного дублирования потенциальных точек отказа и т. п.;
• аренда всей инфраструктуры или её части у внешних поставщиков (хостинг, collocation).

2. Изменение maintainability (изменения в деятельности ИТ‑службы компании):

• распространение внутри организации собственного передового опыта управления ИТ;
• приглашение внешних консультантов для организации процессов в ИТ-подразделении;
• обучение ИТ-персонала.

3. Изменение serviceability - изменение контрактов ИТ-услуг с внешними поставщиками в сторону повышения уровня сервиса, увеличения объема услуг, расширения зоны ответственности внешних поставщиков услуг и т. п. Все приемы манипулирования тремя источниками и тремя составными частями доступности изложить в рамках одной статьи невозможно, однако основные подходы к компенсированию одних составляющих доступности другими были продемонстрированы. Для дальнейшего повышения мастерства в этой области следует изучать практический опыт проектирования и эксплуатации ИТ‑систем.

Доступность

Основные понятия

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

• Эффективность услуг . Эффективность услуги определяется в терминах максимального времени обслуживания запроса, количества поддерживаемых пользователей и т.п. Требуется, чтобы эффективность не опускалась ниже заранее установленного порога.
• Время недоступности. Если эффективность информационной услуги не удовлетворяет наложенным ограничениям, услуга считается недоступной. Требуется, чтобы максимальная продолжительность периода недоступности и суммарное время недоступности за некоторой период (месяц, год) не превышали заранее заданных пределов.

В сущности, требуется, чтобы информационная система почти всегда работала с нужной эффективностью. Для некоторых критически важных систем (например, систем управления) время недоступности должно быть нулевым, без всяких "почти". В таком случае говорят о вероятности возникновения ситуации недоступности и требуют, чтобы эта вероятность не превышала заданной величины. Для решения данной задачи создавались и создаются специальные отказоустойчивые системы, стоимость которых, как правило, весьма высока.

К подавляющему большинству коммерческих систем предъявляются менее жесткие требования, однако современная деловая жизнь и здесь накладывает достаточно суровые ограничения, когда число обслуживаемых пользователей может измеряться тысячами, время ответа не должно превышать нескольких секунд, а время недоступности – нескольких часов в год.

Задачу обеспечения высокой доступности необходимо решать для современных конфигураций, построенных в технологии клиент/сервер. Это означает, что в защите нуждается вся цепочка – от пользователей (возможно, удаленных) до критически важных серверов (в том числе серверов безопасности).

Основные угрозы доступности были рассмотрены нами ранее.

В соответствии с ГОСТ 27.002, под отказом понимается событие, которое заключается в нарушении работоспособности изделия. В контексте данной работы изделие – это информационная система или ее компонент.

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

Рис. 13.1.

где i – номер компонента,

λ i – интенсивность отказов,

T i – среднее время наработки на отказ.

Интенсивности отказов независимых компонентов складываются:

Рис. 13.2.

а среднее время наработки на отказ для составного изделия задается соотношением

Рис. 13.3.

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

Пуассоновская модель позволяет обосновать еще одно очень важное положение, состоящее в том, что эмпирический подход к построению систем высокой доступности не может быть реализован за приемлемое время. При традиционном цикле тестирования/отладки программной системы по оптимистическим оценкам каждое исправление ошибки приводит к экспоненциальному убыванию (примерно на половину десятичного порядка) интенсивности отказов. Отсюда следует, что для того, чтобы на опыте убедиться в достижении необходимого уровня доступности, независимо от применяемой технологии тестирования и отладки, придется потратить время, практически равное среднему времени наработки на отказ. Например, для достижения среднего времени наработки на отказ 10 5 часов потребуется более 10 4,5 часов, что составляет более трех лет. Значит, нужны иные методы построения систем высокой доступности, методы, эффективность которых доказана аналитически или практически за более чем пятьдесят лет развития вычислительной техники и программирования.

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

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

В качестве меры доступности можно принять вероятность приемлемости эффективности услуг, предоставляемых информационной системой, на всем протяжении рассматриваемого отрезка времени. Чем большим запасом эффективности располагает система, тем выше ее доступность.

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

Услуги «ИТ-инфраструктура как сервис», IaaS, становятся все популярнее у корпоративных клиентов, причем их используют уже и для критически важных задач. Настало время разобраться, что гарантируют поставщики этих услуг и какую ответственность несут в тех случаях, когда виртуальная ИТ-инфраструктура тормозит работу или вовсе становится недоступной.

Опросив ведущих поставщиков инфраструктурных сервисов IaaS корпоративного уровня, мы провели анализ их предложений. При этом под «корпоративным уровнем» понимается следующее: облачная платформа развернута в ЦОД, соответствующем требованиям Tier III (наличие сертификата от Uptime Institute не обязательно), и обеспечивает высокий уровень отказоустойчивости за счет механизмов High Availability (HA) и переезда виртуальных машин в случае аварии.

ДОСТУПНОСТЬ И ВРЕМЯ РЕАКЦИИ

Основные параметры сервиса IaaS, которые обычно указывают в соглашении SLA, - это уровень его доступности, время реакции на различные инциденты и продолжительность их разрешения, а также схема и параметры компенсации в случае простоя.

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

Обычно платформы для предоставления услуг IaaS корпоративного уровня размещаются в центрах обработки данных (собственных или внешних), соответствующих уровню отказоустойчивости Tier III, который, как известно, предполагает доступность 99,98%. Указанные провайдерами значения доступности виртуальных инфраструктур IaaS не превышают соответствующую характеристику физической площадки, что вполне естественно.

Исключение составляет доступность 99,99%, обеспечиваемая компанией Dataline в режиме метрокластера. Этот вариант катастрофоустойчивого облака охватывает два ЦОД компании - подробнее о метрокластере см. материал «Катастрофоустойчивое облако по «незаоблачной» цене», опубликованный в октябрьском номере «Журнала сетевых решений/LAN» за 2013 год ().

В принципе, поставщик может указать в SLA сколь угодно высокую доступность, хоть 100%, но тогда рискует больше потерять, чем заработать, ведь любой здравомыслящий покупатель потребует включить в договор жесткую схему компенсации за невыполнение согласованных условий. Пока какой-либо типовой схемы еще не выработано - каждый поставщик предлагает что-то свое, так что покупатель должен оценить предложенную компенсацию с учетом возможных финансовых потерь в случае простоя ИТ-сервисов.

Многие компании предлагают определенное возмещение ежемесячного платежа (в процентном соотношении) за каждый дополнительный (сверх оговоренного в SLA) час недоступности сервиса. Например, при указанном в SLA уровне доступности 99,95% (простой не более 1 часа в месяц) за каждый дополнительный час отключения от сервиса компания Inoventica готова возмещать 2% от ежемесячного платежа. Cloud4Y в стандартном варианте компенсирует 1% за 1 час простоя (при расчетах используется общая стоимость услуги за полный календарный месяц, предшествующий данному), но не более 50% стоимости услуги.

Ряд провайдеров предоставили подробные расчеты того, как размер компенсации меняется в зависимости от уровня доступности (см. Таблицу 2). В случае значительного снижения этого уровня предлагается очень существенная компенсация. Например, при значении менее 95% «Онланта» (ГК «Ланит») допускает снижение уровня оплаты услуги до 40%. А компания «ИТ-Град», если уровень доступности опустится ниже 96,71%, обещает компенсацию 50%. Ясно, что подобное ухудшение качества услуг провайдеры считают маловероятным.

«Мы ввели два самостоятельных принципа компенсации: за нарушение целевых показателей параметров услуги и целевых показателей по обработке обращений, - рассказывает Виталий Мзоков, руководитель направления «Облачные сервисы и инфраструктурные решения» из компании «Сервионика» (ГК «Ай-Теко»). - Нарушение целевых показателей параметров услуги компенсируется по прогрессивной шкале. В зависимости от фактического уровня доступности рассчитывается показатель компенсации, выражающийся в процентах от суммы счета за пользование услугой. Компенсация за нарушение целевых показателей по обработке обращений высчитывается исходя из длительности ожидания клиента с точностью до минуты».

Согласно практике, принятой в компании «Сервионика», виды обращений клиентов, а также общие целевые показатели по максимальному времени реакции на обращения и максимальному времени решения проблемы описаны в регламенте сервисного взаимодействия. А в самом договоре SLA эти показатели уточняются для конкретной услуги.

«Согласно договору, заказчик может получать у нас несколько услуг. Именно поэтому в регламенте описываются общие показатели с пометкой: «Целевые показатели, определенные в SLA на конкретную услугу, перекрывают показатели, указанные в регламенте». Это сделано для того, чтобы при необходимости можно было уточнить (расширить или уменьшить) время реакции и время решения, - поясняет Виталий Мзоков. - Мы обязаны отреагировать на обращения любого вида в течение 15 мин. Максимальное время решения, в зависимости от типа и приоритета обращения, составляет от 1 ч (для инцидентов с приоритетом № 1) до 48 ч (для обращений, по которым требуется полная проработка информационного запроса заказчика - например, предоставление информации по тарифам и другим услугам, различные уточнения и инструктажи).

Время реакции на заявку обычно зависит от ее приоритетности. Вот, например, какие уровни приоритета практикует компания Linxdatacenter:

• Critical - сервис недоступен полностью, необходимо принять срочные меры по восстановлению, время реакции 15 мин, время восстановления не более 4 ч;
• High - сервис недоступен частично, время реакции до 1 ч, повышенный приоритет;
• Normal - уточнение по параметрам сервиса, текущие несрочные вопросы, время реакции до 1 ч, на подготовку ответа отводится 24 ч.

В Таблице 3 показан еще один пример - разделение запросов по категориям, применяемое компанией Cloud4Y; время реакции - не более 30 мин.

Оперативно стараются работать в T-Systems. Как сообщил Всеволод Егупов, директор по продажам ICT-направления T-Systems RUS, специалисты этой копании «в 80% случаев реагируют в течение 30 с» (!). Но, как и большинство наших респондентов, он отметил, что время реакции зависит от критичности ситуации.

ИНСТРУМЕНТЫ МОНИТОРИНГА

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

Ссылаясь на практику компании «Сервионика», Виталий Мзоков отмечает, что клиенты больше заинтересованы в получении от оператора прозрачной и точной отчетности, чем в освоении каких-то особых инструментов для самостоятельного мониторинга. Как правило, «Сервионика» ежемесячно предоставляет отчеты по согласованному набору параметров, но, по желанию клиента, контрактом может предусматриваться и более частая отчетность.

Многие компании, по умолчанию, предоставляют отчеты о состоянии работоспособности сервиса раз в месяц, но могут и чаще - по запросу клиентов. Пример отчета, предлагаемого компанией «Онланта», показан на Рисунке 1. Как утверждает Михаил Ляпин, руководитель ее облачного направления, «Онланта» - единственная в России компания, предоставляющая заказчикам отчет о доступности облачных ресурсов с таким уровнем детализации. По его данным, большинство сервис-провайдеров обходятся статистикой по уровню доступности виртуальных машин.

Ряд компаний предлагают клиентам воспользоваться консолью самообслуживания в онлайновом режиме. По словам Руслана Заединова, заместителя генерального директора, руководителя направления ЦОД и облачных вычислений компании «Крок», у каждого потребителя услуги IaaS есть доступ к такой консоли с встроенной возможностью онлайн-мониторинга функционирования тех или иных составляющих. Например, в случае виртуальных машин ИТ-специалисты заказчика могут проконтролировать, насколько загружен процессор, как работает ввод-вывод, сколько памяти занято и пр. Эти данные доступны в режиме реального времени, а также - по запросу - в виде статистики за любой период.

НАДО ЛИ ГАРАНТИРОВАТЬ ПРОИЗВОДИТЕЛЬНОСТЬ

Очевидно, что при росте нагрузки на IaaS-платформу провайдера возможна деградация уровня производительности виртуальной машины. Поставщики услуг всячески стремятся не допустить такого развития событий. В этом солидарны все компании. Однако некоторые включают параметры производительности в SLA, а другие считают подобную меру ненужной.

Вот что говорит по этому поводу Виталий Слизень, член совета директоров Inoventica: «Мы не наблюдаем деградации [производительности] даже при росте нагрузки, так как своевременно производим расширение и модернизацию мощностей дата-центров. Отдельно в SLA данные параметры (производительность ВМ и СХД) не отражены, поскольку их соблюдение является нашей первостепенной обязанностью, независимо от обращений клиентов». Специалисты Inoventica осуществляют постоянный мониторинг всех основных параметров арендованных инфраструктурных мощностей, что позволяет им оперативно получать информацию о потенциальных проблемах и своевременно их прогнозировать.

Об отсутствии деградации говорит и Игорь Дроздов, менеджер технической поддержки продаж Linxdatacenter: «Наша компания предоставляет в пользование гарантированные вычислительные ресурсы. Они зарезервированы в облаке и расширяются по мере увеличения числа клиентов, поэтому производительность виртуальных машин и СХД остается на стабильно высоком уровне. Кроме того, мы производим своевременную модернизацию серверов и выполняем мониторинг производительности при помощи специализированных продуктов VMware».

Компания Orange Business Services тоже относится к числу сервис-провайдеров, не регламентирующих в стандартном SLA параметры производительности. При этом, как отмечает Дмитрий Дородных, руководитель отдела развития продуктов унифицированных коммуникаций и ИТ Orange Business Services в России и СНГ, «если клиент требует, чтобы для его виртуальных машин гарантированно выделялись определенные вычислительные ресурсы, мы применяем стандартные средства современных платформ виртуализации, которые при возникновении конкуренции за ресурсы позволяют переместить виртуальные машины на другие серверы».

Всеволод Егупов считает, что вносить характеристики производительности в SLA «не имеет смысла, так как деградация сказывается на уровне доступности сервиса, регулируемом соглашением». В T-Systems производительность виртуальных машин и СХД контролируется департаментом по управлению мощностями, его специалисты отвечают за недопущение ее деградации.

Немало и компаний, которые полагают, что внесение в SLA характеристик производительности целесообразно. Самым узким местом виртуализированной ИТ-среды многие эксперты считают производительность системы хранения, поэтому большинство поставщиков уделяют наиболее пристальное внимание таким характеристикам СХД, как количество операций ввода-вывода в секунду (IOPS) и время доступа к диску (latency).

Dataline указывает метрики производительности СХД и виртуальных машин в каждом SLA (см. Таблицу 4). При этом, как отмечает Дмитрий Тишин, руководитель отдела развития услуг этой компании, «в зависимости от требований, выдвигаемых к системному ландшафту со стороны клиента, метрики могут быть изменены». Значения IOPS измеряются системой мониторинга NetApp DFM, а время доступа к диску - штатными средствами ПО виртуализации (vCenter). В случае возникновения проблем с виртуальной машиной дежурная смена и инженеры группы виртуализации получают соответствующее предупреждение. Кроме того, Dataline обеспечивает мониторинг различных параметров на уровне операционной системы и запущенных в ней сервисов. Если клиент пользуется сервисом компании по администрированию ОС и сервисов, такой мониторинг осуществляется по умолчанию.

Для недопущения деградации производительности виртуальных машин специалисты Dataline применяют комплекс мер. Так, для кластера используется механизм Distributed Resource Scheduler (DRS), который отслеживает загрузку физических серверов по основным параметрам, - в случае достижения определенной нагрузки на сервер часть виртуальных машин автоматически перемещается на другой. В кластере поддерживается избыточность серверов с таким расчетом, чтобы нагрузка на весь кластер составляла не более 70%. В рамках заключенных сервисных контрактов с поставщиками оборудования ресурсные мощности кластеров можно наращивать по плану-графику.

Компания Safedata тоже регламентирует в SLA такие характеристики производительности, как IOPS и MIPS. «Снизить производительность ниже указанных в SLA значений мы не можем, - рассказывает Антон Антонов, начальник отдела продаж Safedata. - Если при повышении нагрузки на физических серверах наблюдается деградация сервиса, вводятся в строй дополнительные резервные хосты EXSi».

Регламентируемые в SLA Cloud4Y характеристики производительности дисковой системы СХД указаны в Таблице 5. Как сообщил Евгений Бессонов, руководитель отдела маркетинга Cloud4Y, в случае нарушения гарантированных показателей производительности CPU, HDD, RAM предусматривается компенсация, которая оговаривается отдельно или выплачивается в соответствии со стандартными условиями: 1% от месячной стоимости за 1 ч.

«Мы гарантируем обеспечение производительности виртуальных машин по нижней границе, не ограничивая ее сверху, - рассказывает Руслан Заединов. - Таким образом, если на сервере, где расположена виртуальная машина, имеются свободные вычислительные ресурсы сверх гарантированных, они будут доступны заказчику». Что касается СХД, то в настоящее время все клиенты «Крок» пользуются общим каналом связи с системами хранения. Долгое время это не вызывало проблем, но сейчас, чтобы удовлетворить растущие потребности заказчиков, компания переводит облачные СХД с дисков Fibre Channel и SATA на флэш-накопители с прямым доступом к ним из виртуальных машин через сеть Infiniband. Параллельно внедряется ПО для обеспечения гарантированной пропускной способности системы хранения данных в облаке. Соответствующие изменения в SLA будут внесены уже этой осенью.

По согласованию с заказчиком компания «Сервионика» фиксирует в SLA каждого проекта показатели производительности отдельных компонентов облачной платформы. Кроме того, в соглашении указываются способы измерения этих показателей и периодичность проводимых измерений. «Написать «гарантируется 100 500 OPs на 1 Гбайт дискового пространства» может любой оператор, но далеко не все способны доказать, что этот критерий выдержан. Мы за максимально прозрачные отношения между оператором облачной платформы и ее потребителем», - подчеркивает Виталий Мзоков. Производительность виртуальных машин и СХД определяется в SLA «Сервионика» показателями IOPS и Latency.

Как рассказал Максим Захаренко, генеральный директор сервис-провайдера «Облакотека», в заключаемых ими договорах пиковые показатели производительности регламентируются таким образом, чтобы загрузка пропускной способности ввода-вывода и сети не превышала 80%. Мониторинг осуществляется с помощью системы Microsoft SCOM. Он отмечает, что для разных систем важны различные показатели: для Web-сайтов - время отклика, для размещения ИТ-инфраструктур - показатели пиковой загрузки процессора, памяти, виртуальной сети и т. д. В свой SLA эта компания включает также параметры гарантированного резервного копирования, способы и сроки предоставления и хранения пользовательских данных («Честное расставание»).

СКВОЗНЫЕ SLA

Сколь бы ни была высока надежность самой платформы IaaS, размещенной в отказоустойчивом ЦОД, узким для заказчика местом могут стать каналы доступа к этой платформе. Хорошей новостью является то, что многие из опрошенных нами провайдеров практикуют заключение сквозных SLA, охватывающих как сам сервис IaaS, так и каналы доступа. При этом, по их утверждению, при правильной организации и резервировании каналов уровень доступности связи оказывается не ниже, чем у платформы SLA, а потому в сквозных SLA эта важная характеристика не снижается.

Впрочем, как замечает Всеволод Егупов, снижение или сохранение уровня доступности зависит от способа организации каналов связи - если канал зарезервирован, доступность не ухудшается. В ином случае уровень доступности в сквозном SLA снижается до уровня доступности канала. У компании T-Systems RUS имеется собственная сеть центров обработки данных, расположенных по всему миру. Обслуживание российских клиентов в основном осуществляется из центров обработки данных, которые находятся в Германии и Австрии. У компании подписано SLA с «Ростелекомом», «Билайном», сотрудничает она и с другими операторами связи.

Те поставщики услуг IaaS, которые являются одновременно и операторами связи, используют это преимущество. Так, будучи международным оператором связи, Orange Business Services практикует заключение сквозных SLA, охватывающих IaaS и услуги связи. Уровень доступности в таких SLA - 99,95%. Но, как поясняет Дмитрий Дородных, эта характеристика зависит от географического местонахождения клиента - например, в Центральном регионе этот уровень выше, чем за Уралом и в Сибири. Для «последней мили» могут быть свои параметры SLA. Схемы и механизмы контроля SLA на каналах связи за десятилетия уже отработаны, поэтому вопрос мониторинга не является для Orange Business Services проблемой.

Как отмечает Виталий Слизень, Inoventica располагает своими магистральными каналами связи и географически распределенной сетью ЦОД, благодаря чему становится возможна реализация геокластеров. Это позволяет сохранить данные и работоспособность сервисов даже в случае физического разрушения одного из ЦОД. По его сведениям, Inoventica - «единственная компания на российском рынке, предоставляющая полную цепочку услуг «ЦОД – канал – сервис – клиент (АРМ)» в соответствии со SLA, которым предусматриваются минимальная за держка при передаче пакетов (round trip delay) менее 10 мс и почти нулевая потеря пакетов». В настоящее время комплексное решение Inoventica доступно клиентам в пяти федеральных округах РФ.

Поставщики услуг IaaS, не являющиеся операторами связи, активно сотрудничают с таковыми. Так, «Сервионика» сформировала SLA для работы с операторами связи, обслуживающими ее ЦОД (а это более 10 крупных телеком-провайдеров). Условия этих SLA компания транслирует в договорах с клиентами, которые пользуются услугами связи. А контроль за соблюдением SLA обеспечивают технические службы ЦОД «ТрастИнфо». «Мы указываем в наших контрактах те же параметры SLA, что и у операторов, - то есть берем на себя ответственность за качество их работы и бесперебойное предоставление каналов связи», - отмечает Виталий Мзоков.

Для предоставления клиентам каналов связи Dataline практикует использование услуг телекоммуникационных операторов по схеме субподряда. При такой схеме компания контролирует качество в рамках своего договора с оператором, клиент же получает от нее комплексную услугу и имеет дело только с одним контрагентом. Уровень доступности такой комплексной услуги не снижается. У Dataline имеется собственная сеть передачи данных в Москве, где гарантируются следующие характеристики: доля потерянных пакетов - не более 0,2%, средняя задержка в сети - не более 5 мс.

Как утверждает Руслан Заединов, «Крок» использует широкие каналы, пропускной способности которых вполне хватает на всех заказчиков в облаке. Технически действующие гарантии обеспечиваются перекрестным резервированием каналов между разными ЦОД «Крок» при помощи собственного оптического кольца. Для тех организаций, для которых критична фиксированная пропускная способность канала связи, компания реализует индивидуальное подключение к облаку по отдельным каналам с гарантированной пропускной способностью или даже по «темной» оптике. Такое подключение чаще всего оснащается индивидуальными средствами шифрования, в том числе сертифицированными.

Итак, услуги IaaS предлагаются в России довольно большим числом компаний, причем по вполне понятным и документированным (в SLA) правилам. В отрасли еще не пришли к согласию относительно того, надо ли регламентировать в SLA характеристики производительности виртуальных ИТ-инфраструктур, но гарантируемые показатели доступности выглядят вполне приемлемыми даже для самых требовательных корпоративных заказчиков. К тому же провайдеры понимают потребность заказчиков в сквозных SLA и работают над их совершенствованием.

Александр Барсков - ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: