Меню
ГлавнаяПричины

Доступность системы. Лекция: Обеспечение высокой доступности

|

Масштабируемость и высокая доступность становятся всё более популярными с увеличением спроса на надежные и производительные инфраструктуры, предназначенные для обслуживания критически важных систем. Уменьшение времени простоя и устранение единых точек отказа – такие же важные проблемы, как и обработка повышенной нагрузки на систему. Высокая доступность (high availability) – качество инфраструктуры, способное устранить их.

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

Высокая доступность

В программировании термин «доступность» (availability) используется для описания интервала времени, в течение которого сервис доступен, а также времени, необходимого системе для ответа на запрос пользователя. Высокая доступность – это качество системы или компонента, которое обеспечивает высокий уровень эксплуатационных характеристик за определенный период времени.

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

Доступность часто выражается в процентах, что обозначает уровень аптайма, который ожидается от конкретной системы или компонента за конкретный период времени. В таком случае 100% доступности значит, что система никогда не выходит из строя; соответственно, система, которая обеспечивает 99% доступности в течение одного года, может иметь до 3,65 дней простоя (1%).

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

Как работает высокая доступность?

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

Когда необходима высокая доступность?

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

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

Что делает систему высоко доступной?

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

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

В данной ситуации веб-сервер не является единой точкой отказа, потому что:

  • В кластере существует «запасной» компонент, способный взять на себя все задачи.
  • На другом уровне существует механизм (балансировщик нагрузки), способный обнаруживать сбои в компонентах и адаптировать свое поведение для своевременного восстановления работы приложения.

Но что если из строя выйдет балансировщик нагрузки?

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

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

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

Для обнаружения и устранения сбоев в инфраструктуре должен существовать специальный компонент.

Обнаружение и устранение сбоев можно реализовать методом top-to-bottom: верхний слой отслеживает сбои нижнего слоя. Вернёмся к нашему примеру; в таком кластере балансировщик нагрузки – это верхний слой. Если один из веб-серверов (нижний слой) станет недоступным, балансировщик нагрузки перестанет перенаправлять на него запросы.

Такой подход достаточно прост, но он имеет свои ограничения: в инфраструктуре всегда будет точка, для которой верхний слой отсутствует либо недоступен (как в случае с балансировщиком нагрузки). Создание сервиса обнаружения неисправностей для балансировщика нагрузки на внешнем сервере равно созданию новой единой точки отказа.

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

Однако в случае с балансировкой нагрузки есть дополнительная сложность, связанная с работой серверов имен. Восстановление после сбоя балансировки нагрузки, как правило, означает переход балансировки на другой (избыточный) ресурс, а для этого нужно изменить DNS (указать доменное имя или IP-адрес резервного балансировщика нагрузки). Такие изменения могут занять значительное количество времени и повлечь за собой большой период простоя.

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

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

Какие компоненты необходимы для поддержки высокой доступности?

Для настройки высокой доступности необходимо установить несколько системных компонентов. Однако гораздо сильнее высокая доступность зависит от таких факторов:

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

Какое программное обеспечение необходимо для высокой доступности?

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

(High Availability Proxy) – популярное средство для настройки балансировки нагрузки, так как позволяет обрабатывать нагрузку на нескольких уровнях, а также для различных видов серверов, включая серверы баз данных.

Также в системный стек важно внедрить надёжное средство для точки входа в приложение. Чтобы устранить единую точку отказа, как упоминалось ранее, необходимо реализовать кластер балансировки нагрузки с гибкими IP-адресами. Для создания таких систем используются Corosync и Pacemaker.

Заключение

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

Tags:

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

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

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

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

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

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

Availability = (AST — DT)/AST ,

где AST - согласованное время предоставления услуги, DT - сумма простоев за период.

А также, вероятно, знакомы сложности ее применения:

Первая сложность связана с обсуждением показателя. Доступность определена как 99,9%. Вроде неплохо. Но 0,1% в год равен почти 9 часам. А в месяц - это почти 45 минут. А в неделю - чуть более 10 минут. Так какие 99,9% имел в виду заказчик? А сервис-провайдер?

Однако значительно более существенен следующий нюанс: показатель довольно неточно отражает негативное влияние на бизнес. Что если все без малого 9 часов за год случились разом? Или услуга становилась недоступна потребителям по две минуты, но 15 раз за один день? Как это будет выражено в процентах?.. Поэтому, например, ITIL вводит такие показатели, как MTRS, MTBF, MTBSI.

Однако предлагаю вернуться в начало координат и задаться вопросом, а зачем мы вообще вводим показатели доступности? Почему бизнес предъявляет требования к доступности услуг? Почему сервис-провайдер должен обеспечивать высокую доступность и отчитываться по ее фактическим значениям? Ответ прост: бизнес несет потери вследствие простоев ИТ-услуг. Значит, идеальным для бизнеса показателем доступности, вероятно, была бы метрика «Потери вследствие простоев ИТ-услуг»?

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

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

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

От чего зависят потери бизнеса вследствие простоев?

  1. Чем меньше за отчетный период услуга была в uptime, тем больше потери. Введем показатель «Суммарное время простоев».
  2. Чем дольше разовый простой, тем больше потери. Нередко потери не являются постоянной во времени величиной и зависят от длительности прерывания экспоненциально. В первый отрезок времени ущерб складывается из несовершенных транзакций, потерь продуктивности персонала и затрат на восстановление, но с определенного момента длительный простой угрожает бизнесу штрафами, санкциями, уроном репутации и так далее. Введем показатель «Максимальный разовый простой».
  3. Ряд бизнес-процессов, напротив, «чувствительны» не к единичным длительным простоям, а к частым прерываниям. Это особенно важный фактор для процессов, в рамках которых происходят длительные вычисления, которые в случае прерывания требуется перезапускать. Таким образом, должно быть обеспечено как можно меньшее количество прерываний за период. Введем показатель «Количество нарушений».

Альтернативной (или дополнительной) метрикой, отражающей тот же аспект, но с акцентом на периоде спокойной работы пользователей, может быть показатель «Минимальная (или средняя) продолжительность работы без нарушений».

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

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

От представленных метрик можно легко перейти к известным MTRS, MTBF, MTBSI и, конечно, классическому показателю доступности. Но, на мой взгляд, предложенный набор скажет заказчику и сервис-провайдеру несколько больше о бизнес-влиянии нарушений ИТ-доступности. Или нет?

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

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

Рис. 14.6. Формула доступности (источник: OGC)

Достигнутое время работоспособности системы равно разнице между согласованным временем работоспособности и случившемся временем простоя. Например: если была достигнута договоренность о 98% доступности сервиса в рабочие дни с 7.00 до 19.00 и в течение это периода был двухчасовой отказ сервиса, то достигнутое время работоспособности (процент доступности) будет равен:

(5x12- 2)/(5 х 12) х 100% = 96,7%

Анализ простоев системы (SOA)

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

Характеристики метода SOA:

Широкая сфера действия: он не ограничивается инфраструктурой и охватывает также процессы, процедуры и аспекты корпоративной культуры;

Рассмотрение вопросов с точки зрения заказчика;

Совместная реализация метода представителями заказчика и ИТ-организации (команда метода SOA).

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

Пост технического наблюдения (ТОР)

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

Расчеты доступности сервиса

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

Программное обеспечение автоматизации процессов itil

  1. Bmc software
  2. Computer associates
  3. Hewlett-packard
  4. Microsoft

Bmc software

Компания BMC Software - всемирно известный разработчик и поставщик средств администрирования сетей, приложений, баз данных, ERP- и CRM-систем, повышающих доступность, производительность и восстанавливаемость критических бизнес-приложений и данных. Продукты BMC доступны для широкого спектра платформ, включая различные реализации и версии UNIX, Windows, OS/2, OS/390, OpenVMS и NetWare. Из характерных для продуктов BMC особенностей в первую очередь следует отметить ориентацию на поддержку соглашений об уровне обслуживания пользователей (Service Level Agreement, SLA) и построение модели функционирования, направленной на реализацию такого соглашения, а также их высокую производительность (рис. 1). Компания предлагает следующие семейства продуктов для управления ИТ-инфраструктурой:

  • BMC Application Management - средство предназначено для управления производительностью и доступностью бизнес-приложений (включая приложения компаний Oracle и SAP) и серверных продуктов (таких, как Microsoft Exchange и J2EE-серверы BEA WebLogic, IBM WebSphere и др.);
  • BMC Database Management - средство для администрирования, управления производительностью и восстановлением баз данных, управляемых СУБД ведущих производителей - Oracle, IBM, Microsoft, Sybase;
  • BMC Infrastructure Management - средство для управления операционными системами серверов и мэйнфреймов, хранилищами данных, сетями, аппаратным обеспечением, ПО промежуточного звена, а также для оптимизации производительности указанных категорий программного обеспечения;
  • BMC Operations Management - средство для выполнения рутинных операций по расписанию и для составления отчетов о событиях в сети;
  • BMC Remedy Service Management - средство для поиска, обнаружения, моделирования сбоев в приложениях и реагирования на них;
  • BMC Security Management - средство для управления правами доступа пользователей к приложениям и корпоративным ресурсам.

Данные приложений BMC могут храниться в базе данных о конфигурациях BMC Atrium CMDB (Configuration Management Database), обладающей удобными средствами визуализации данных.

Bmc software

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

Рис. 1. Области управления ИТ-инфраструктурой, охватываемые продуктами BMC

Computer associates

Семейство продуктов Unicenter для управления ИТ-инфраструктурой компании Computer Associates (CA) можно адаптировать для применения практически в любой вычислительной среде.

В состав данного семейства входят следующие продукты:

  • Unicenter Asset Management - инструмент для автоматизации управления ИТ-активами предприятия, с помощью которого осуществляется комплексный учет и контроль ИТ-ресурсов. Функциональность системы Unicenter Asset Management способствует повышению качества управленческих решений, связанных с ИТ-активами предприятия, и уменьшению сопутствующих рисков. Unicenter Asset Management обеспечивает мониторинг использования приложений на серверах, персональных компьютерах и других клиентских устройствах. Кроме того, этот продукт позволяет автоматизировать процессы управления ИТ-активами, включая учет и инвентаризацию программных и аппаратных средств, работающих в сети предприятия, обслуживание различных составляющих ИТ-инфраструктуры, администрирование лицензий и формирование отчетов в гетерогенных средах (рис. 2);

Рис. 2. Области интегрированного управления ИТ-инфраструктурой, охватываемые продуктами Computer Associates

  • Unicenter Software Delivery - обеспечивает автоматизацию процессов развертывания и обновления программного обеспечения на настольных, мобильных и карманных компьютерах, а также на серверах в гетерогенных сетевых средах, включая доставку приложений, распространение исправлений и обновлений, управление системными конфигурациями и откат инсталляций на различных программных и аппаратных платформах. Данный продукт создает условия для повышения оперативности работы ИТ-служб и снижения расходов на информационную поддержку бизнеса за счет автоматизации ИТ-процессов и внедрения каталогов приложений с развитыми возможностями самообслуживания. Одним из ключевых преимуществ Unicenter Software Delivery является высокая степень автоматизации процессов установки и обслуживания ПО и гибкое и детальное управление разрешениями на доставку приложений;
  • Unicenter Remote Control - это надежная и защищенная корпоративная система удаленного управления Windows-компьютерами. Перечень задач удаленного управления включает обслуживание удаленных сервисов, таких как сетевые приложения, администрирование серверов и удаленное управление компьютерами конечных пользователей (например, при оказании технической поддержки). Эта система является одним из лучших отраслевых решений в своем классе и обеспечивает централизованное обслуживание систем, управление на основе политик, разграничение прав доступа, аудит сеансов и развитые возможности администрирования. Unicenter Remote Control полностью отвечает запросам крупных предприятий в части удаленного управления и позволяет оператору одновременно выполнять сразу несколько задач: копировать файлы на удаленный компьютер, общаться с пользователем, запускать приложения, наблюдать и фиксировать пользовательские действия, а также управлять параметрами настройки и безопасности. Отметим, что при разработке Unicenter Remote Control особое внимание было уделено сокращению сроков внедрения и освоения системы.

Hewlett-packard

HP OpenView представляет собой комплекс программных продуктов, ориентированных на управление корпоративными информационными технологиями любого масштаба - от небольших систем на базе Windows-серверов до крупных распределенных систем на базе различных версий UNIX, Linux и Windows, содержащих несколько тысяч компьютеров. В данный комплекс входят средства управления сетями, операционными системами, приложениями, а также их производительностью, копированием и хранением данных, сервисами.

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

Рис. 3. Портфель программных решений HP OpenView для ИТ-подразделений

К средствам управления серверами и приложениями следует отнести в первую очередь HP OpenView Operations for Windows и HP OpenView Operations for Unix . Эти продукты предназначены для мониторинга и управления производительностью приложений, а также для осуществления контроля событий в сети и приложениях. HP OpenView Operations for Windows интегрируется со средствами управления сетевой инфраструктурой HP OpenView Network Node Manager , что позволяет производить автоматический поиск новых серверов, добавленных в сеть, а затем выполнять автоматическое развертывание требующихся компонентов и политик на основе результатов поиска сервисов.

Hewlett-packard

Для управления производительностью приложений в состав указанного семейства входят средства HP OpenView Performance Manager и Performance Agents , позволяющие с помощью единого интерфейса осуществлять централизованный мониторинг, анализ и прогнозирование использования ресурсов в распределенных и неоднородных средах, а также HP OpenView Performance Insight, помогающий осуществлять мониторинг событий в сети и приложениях, анализировать их. Решения HP OpenVew Report Packs и HP OpenView Reporter предназначены для создания отчетов о работе распределенной IT-инфраструктуры предприятия на основе данных, полученных от приложений HP OpenView.

Для управления идентификацией и доступом к ИТ-ресурсам в состав семейства HP OpenView входят продукты HP OpenView Select Identity, HP OpenView Select Access и HP OpenView Select Federation , а для управления резервным копированием и восстановлением данных серверных СУБД - HP OpenView Storage Data Protector . Последний из названных продуктов является решением корпоративного уровня для защиты данных и восстановления систем в чрезвычайных ситуациях, реализующим технологию мгновенного восстановления, а также альтернативные варианты аварийного восстановления для устранения внеплановых простоев, что позволяет восстановить работоспособность информационной системы за несколько минут.

Отметим также наличие в данном семействе продуктов, предназначенных для осуществления взаимодействия с конечными пользователями с целью улучшения качества их обслуживания, - HP OpenView Service Desk , а также средства мониторинга бизнес-процессов HP OpenView Business Process Insight и средства управления архитектурой, ориентированной на сервисы, - HP OpenView Service Oriented Architecture Manager .

Hewlett-packard

Для управления Интернет-сервисами в данном семействе продуктов предусмотрено решение HP OpenView Internet Services , позволяющее осуществлять внешнее зондирование прикладных служб, Интернет-сервисов и протоколов посредством моделирования запросов пользователей к каталогам, почтовым службам, веб-службам, сервисам удаленного доступа (в том числе коммутируемого и беспроводного доступа).

Семейство продуктов IBM Tivoli, предназначенных для управления приложениями предприятий различного масштаба, основано на наборе базовых компонентов, из которых строится решение для конкретного предприятия. Главной отличительной особенностью данного семейства продуктов является так называемое упреждающее управление IT-инфраструктурой, способное выявлять и устранять неисправности еще до их возникновения. Продукты семейства Tivoli доступны для платформ AIX, HP-UX, Sun Solaris, Windows, Novell NetWare, OS/2, AS/400, Linux, z/OS, OS/390. Отметим, что в последнее время IBM рекомендует внедрять продукты семейства Тivoli с целью следования методикам библиотеки ITIL (Information Technology Infrastructure Library), сместив акцент в позиционировании своих продуктов с управления ИТ-ресурсами и системами на управление ИТ-услугами (рис. 4).

Рис. 4. Некоторые из программных продуктов Tivoli, поддерживающих ITIL-процесс управления услугами

Семейство продуктов Tivoli включает решения для управления конфигурацией и операционной поддержки:

  • IBM Tivoli Configuration Manager - позволяет управлять установкой и обновлением ПО, в том числе и на карманные компьютеры;
  • IBM Tivoli License Manager - предназначено для инвентаризации программного обеспечения;
  • IBM Tivoli Remote Control - позволяет устанавливать политики для управления IT-ресурсами предприятия и удаленно администрировать настольные системы;
  • IBM Tivoli Workload Scheduler - дает возможность автоматизировать рабочие нагрузки.

Помимо средств управления конфигурациями, семейство продуктов Tivoli включает решения для управления производительностью и доступностью:

  • IBM Tivoli Monitoring - для осуществления распределенного мониторинга различных систем, автоматического обнаружения и устранения проблем и анализа тенденций;
  • IBM Tivoli Monitoring for Databases (поддерживаются СУБД производства IBM, Oracle и Microsoft) и Tivoli Manager for Sybase - для централизованного управления серверами и базами данных;
  • IBM Tivoli Monitoring for Web Infrastructure - для управления web-серверами и серверами приложений;
  • IBM Tivoli Monitoring for Applications - для управления бизнес-приложениями SAP;
  • IBM Tivoli Analyzer для Lotus Domino 6.0 и IBM Tivoli Monitoring for Transaction Performance - для обнаружения проблем производительности систем, основанных на серверных продуктах самой IBM;
  • IBM Tivoli Web Site Analyzer - для анализа трафика посетителей, статистики посещаемости страниц, целостности информационного наполнения web-сайта;
  • IBM Tivoli Service Level Advisor - для обеспечения упреждающего управления и прогнозирования отказов посредством количественного анализа производительности;
  • IBM Tivoli NetView - для управления сетью;
  • IBM Tivoli Switch Analyzer - для обнаружения и заполнения всех коммутаторов сетевого уровня;
  • IBM Tivoli Enterprise Console - для многоуровневого поиска причин неисправностей и анализа событий.

Кроме того, имеется ряд решений для автоматизированного управления распределением ИТ-ресурсов и пиковыми нагрузками.

В состав семейства Tivoli входят также продукты для обеспечения безопасности:

  • IBMDirectory Server - для синхронизации данных о безопасности в масштабе всех используемых приложений;
  • IBM Directory Integrator - для интеграции идентификационных параметров, содержащихся в каталогах, базах данных, системах коллективной работы и бизнес-приложениях;
  • IBM Tivoli Identity Manager и IBM Tivoli Access Manager for Operating Systems - для управления доступом к приложениям и операционным системам;
  • IBM Tivoli Risk Manager - для централизованного управления защитой сети.

Помимо этого семейство Tivoli включает широкий спектр продуктов для управления резервным копированием и системами хранения данных.

Microsoft

Хотя сегодня Microsoft и не является лидером рынка средств управления ИТ-инфраструктурой, средства управления приложениями производства этой компании применяются в нашей стране достаточно широко.

Основное назначение средств Microsoft Microsoft Systems Management Server (SMS) и Microsoft Operations Manager (MOM), а также средств администрирования, доступных пользователям последних версий серверных операционных систем Microsoft (таких, как Automated Deployment Services, Remote Installation Services, Microsoft Group Policy Management Console, Microsoft Windows Update Services), - управление программным обеспечением, автоматическая установка операционных систем Microsoft и предназначенных для них приложений, автоматическая доставка обновлений, управление доступом и правами пользвателей (рис. 5).

Рис. 5. Управление информационными системами с помощью Microsoft Operations Manager и Microsoft Systems Management Server

Microsoft Systems Management Server предназначен для обеспечения автоматического распространения и учета программного обеспечения в крупных распределенных системах на основе операционных систем самой Microsoft, включая планирование с определением оборудования и ПО в локальной сети, проверку, анализ, внедрение бизнес-приложений для различных целевых групп пользователей, установку приложений на вновь появившиеся рабочие места в соответствии с правами пользователя. Данный продукт позволяет осуществить целевую установку различного ПО для разных групп пользователей, а также решать проблемы, связанные с инвентаризацией ПО и с контролем над использованием ПО и аппаратных ресурсов за счет сбора информации об установленных в сети программных продуктах и оборудовании и об их использовании.

Microsoft

Microsoft Operations Manager предназначен для выявления и устранения неполадок в работе сети, оборудования и приложений за счет прямого мониторинга происходящих событий, а также состояния и производительности сетевых ресурсов и выдаче предупреждений о потенциальных проблемах (рис. 6).

Рис. 6. Мониторинг состония серверов с помощью Microsoft Operations Manager

Для управления ИТ-инфраструктурой небольших компаний или специализированными группами серверов (до 10 шт.) предназначен продукт Microsoft Operations Manager 2005 Workgroup Edition . Он позволяет выявить потенциальные опасности в функционировании программного обеспечения и благодаря встроенным средствам анализа предотвратить перерастание их в серьезные проблемы, повысить эффективность ИТ-операций, упростить поддержку гетерогенных платформ и приложений, а также создавать собственные пакеты обновления.

Кроме того, существуют отдельные решения для управления произвоительностью и для анализа событий для компонентов ИТ-инфраструктуры, основанной на серверных продуктах Microsoft, такие как Active Directory Management Pack - для отслеживания состояния службы каталогов Active Directory, Exchange Management Pack - для управления сервисами обмена сообщениями и хранилищами данных Exchange, а также ряд других продуктов. Для обеспечения взаимодействия со средствами управления ИТ-инфраструктурой производства других компаний имеется продукт MOM Connector Framework , позволяющий осуществлять двунаправленную трансляцию предупреждений и синхронизацию данных с помощью web-служб.

Управление иб

  1. Cobit - «цели контроля для информации и связанных с ней технологий»
  • Читать раздел 1
  • Microsoft operational framework
    • Читать раздел 1
  • Модель команды mof
    • Читать раздел 1
  • Модель управления рисками mof
    • Читать раздел 1

    Стандарт «Цели контроля для информации и связанных с ней технологий» (CobiT), сейчас уже в третьем издании, помогает реализовать многочисленные потребности в области управления, формируя взаимосвязи между бизнес-рисками, требованиями контроля и техническими вопросами. Это позволяет сформировать хорошую практику управления ИТ во всех группах процессов в рамках стандарта, также описать виды ИТ-деятельности в виде управляемой и логически выстроенной структуры. «Хорошая практика» по CobiT – это согласованные рекомендации экспертов, которые помогают оптимизировать инвестиции в информатизацию и предоставляют систему показателей, на которые можно ориентироваться в случае возникновения внештатных ситуаций.

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

    Стандарт CobiT включает в себя следующую серию книг:

    1. Краткое изложение для руководства.

    2. Основы.

    3. Цели контроля (детализированных целей - 318 штук)

    4. Руководство по управлению.

    5. Руководство по проведению аудита.

    6. Методики внедрения.

    Стандарт CobiT выделяет 34 ИТ-процесса, объединенные в четыре следующие группы (рисунок 1.1):

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

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

    Cobit - «цели контроля для информации и связанных с ней технологий»

    3. Эксплуатация и сопровождение – процессы, фактически предоставляющие требуемые услуги.

    4. Контроль – процессы управленческого надзора и независимой оценки с привлечением внутреннего и внешнего аудита или других источников.

    Для каждого из 34 ИТ-процессов определена одна цель контроля уровня ИТ-процессов (намерение или желаемый результат, который достигается посредством внедрения процедур контроля в ИТ-деятельность). Данные цели контроля в дальнейшем разбиваются на детализированные цели контроля. Таких детализированных целей в стандарте CobiT определено 318.

    Рисунок 1.1. ИТ-процессы CobiT

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

    1. Полезность – информация является актуальной и соответствует БП, своевременно поставляется, непротиворечива и пригодна для использования.

    2. Эффективность – предоставление информации на основе оптимального использования ресурсов.

    3. Конфиденциальность – защита информации от НСД.

    4. Целостность – точность и полнота информации в соответствии с бизнес-ценностями и ожиданиями.

    5. Доступность – информация доступна по требованию БП в настоящее время и в будущем.

    6. Соответствие требованиям – соответствие требованиям законодательства, регулирующих органов и договорных обязательств, которым подчиняются БП.

    7. Достоверность – обеспечение руководства необходимой информацией для осуществления управления организацией и исполнения им обязанностей в отношении финансовой деятельности и представления отчетности регулирующим органам.

    Cobit - «цели контроля для информации и связанных с ней технологий»

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

    CobiT определяет также ИТ-ресурсы, которые задействованы в обеспечении выше указанных требований к информации. Выделено 5 классов ИТ-ресурсов:

    1. Данные – информационные объекты в широком смысле, в том числе неструктурированные, графика, звук.

    2. Приложения – совокупность ручных и программных процедур.

    3. Технология – аппаратное обеспечение, ОС, СУБД, сети, мультимедиа, и т.д.

    4. Инфраструктура – все ресурсы для размещения и поддержки ИС.

    5. Персонал – включает в себя персонал и его навыки, осведомленность и умение планировать, организовывать, приобретать, поставлять, обслуживать и контролировать ИС и услуги.

    Цели контроля ИТ-процессов, связь их с требованиями к информации и ИТ-ресурсами представлены на рисунке 1.2.

    Рисунок 1.2. Цели контроля ИТ-процессов

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

    В книге CobiT «Руководство по управлению» вводится модель уровня развития процессов организации с оценкой уровня развития от 0 (не существующего) до 5 (оптимизированного). Данная модель зрелости в дальнейшем используется при проведении аудитов ИТ-процессов и ответа на вопрос – в какой степени ИТ-процессы соответствуют необходимым требованиям. С этой точки зрения CobiT имеет хорошие точки соприкосновения с банковским стандартом России.

    В CobiT для каждого из 34 процессов вводятся ключевые показатели достижения цели. Они определяют контрольные показатели, которые постфактум сигнализируют руководству о достижении процессом ИТ требований бизнеса. Эти контрольные показатели обычно выражены такими требованиями к информации как:

    Cobit - «цели контроля для информации и связанных с ней технологий»

    Доступность информации необходимой для обеспечения потребностей бизнеса.

    Отсутствие рисков для целостности или конфиденциальности.

    Рентабельность процессов и эксплуатации.

    Подтверждение надежности, полезности и соответствия требованиям.

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

    Для каждого из 34 ИТ-процессов определена качественная шкала (0-5), которая указывает – в каком случае процесс нужно относить к определенной модели уровня развития.

    В книге CobiT «Руководство по проведению аудита», для каждого из 34 процессов определено, каким образом оценивать уровень его соответствия установленным требованиям. Для каждого из них определены:

    1. Лица организации, которых следует опросить при проведении аудита.

    2. Информация и документы, которые нужно получить от опрашиваемых лиц.

    3. Факторы, которые требуется оценить (вида опросного листа).

    4. Факторы, которые требуется протестировать (проверить).

    В книге CobiT «Методики внедрения» говорится о том, на кого надо повлиять для внедрения COBIT в организации, дается план мероприятий по внедрению COBIT. Даются опросные листы для персонала, используемые на этапе внедрения, для внутренней оценки корпоративного управления ИТ, внутренней диагностики руководства. Приведены формы по аудиту и оценке риска.

  • Ветеринарно – санитарные требования к качеству воды (СанП и Н), гигиена поения. Расчеты в потребности воды.
  • высшего профессионального образования. «Российский государственный университет сервиса»

    • Услуги «ИТ-инфраструктура как сервис», 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». С ним можно связаться по адресу: