Главная E-commerce

Управление доступностью ит-услуг. Три источника и три составные части доступности Защита данных bronze

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

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

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

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 за счет serviceability - приобрести расширенные услуги технической поддержки, услуги ауттаскинга и т. п.

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

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

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

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

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

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

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

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

Владимир Курилов, компания «Онланта».

Так разговор дошёл до показателей надёжности. И вёлся он вокруг сравнения уровней доступности ЦОДов, в которых располагались облака. Достаточно быстро выяснилось, что только двое кандидатов располагают ЦОДами с уровнем доступности 99,98%. Выбор был сделан в пользу зарубежного провайдера облачных услуг - победила цена. Коллега объяснил всё просто, - «Какой смысл платить больше за те же самые показатели надёжности?»

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

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

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

Ответы на эти вопросы я и попробую сформулировать далее.

Надёжность приложения - из чего она складывается в облаке

Надёжность сервиса приложения

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

От чего зависит работоспособность приложения и, как надёжность приложения связана с доступностью ЦОДа?

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

Рис. Упрощённый пример расчёта доступности Сервиса Приложения

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

Доступность такой системы (As) определяется как произведение показателей доступности всех элементов:

A i – доступность каждого последовательно соединённого компонента.
A s = 0,99995 0,99995 0,993 0998 ≈ 0,99091 или 99,091

Как видим, доступность Сервиса Приложения имеет значение, далёкое от доступности инженерной платформы ЦОДа. Можно пересчитать цифры доступности в значения простоя системы. Получается, несмотря на допустимый годовой простой инженерной платформы, в 1 час. 45 мин., для сервиса приложения годовой простой составит 86 ч. 22 мин.

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

Надёжность сетевого приложения

Следовательно, при выборе сервис-провайдеров правильно было бы ориентироваться на совокупную доступность сервисов приложений? К сожалению, тут не всё так просто.

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

Один из вариантов реализации применения специализированных библиотек компанией Microsoft - Transient Fault Handling Application Block (см. http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50).aspx).

Надёжность программной платформы

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

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

Надёжность инфраструктурной платформы

Эта составляющая надёжности полностью зависит от сервис-провайдера и должна оцениваться Вами наравне с доступностью инженерной платформы ЦОДа. Необходимо запросить этот параметр у провайдера, поскольку как правило он не указывается в маркетинговых материалах. При этом необходимо получить разъяснения - как этот параметр рассчитывался.

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

Тем не менее:

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

Теперь у Вас есть возможность максимально достоверно определить доступность Вашего сервиса приложения. 90% СП в России, исходя из нашего опыта, имеют суммарную доступность не выше 99%. А это риск простоев до 87 часов в год. Это нормальные показатели доступности, если у Вас нет критических для бизнеса приложений, часовой простой которых приносит Вам миллионные убытки. А если часовая остановка сродни катастрофе для Вашего бизнеса, то для Вас есть оставшиеся 10%, СП, предоставляющие сервис корпоративного уровня с доступностью Сервиса приложения на уровне 99,99%. О том, какими способами это достигается в следующем разделе.

Решения, обеспечивающие высокую доступность сервиса приложения

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

Системы, которые мы ранее обсуждали, имели последовательную структуру. Доступность, которую мы посчитали выше как произведение отдельных элементов - это технический предел, обеспечиваемый подобными системами. На деле в силу появления различных дополнительных факторов доступность ещё ниже. Помните вначале статьи рассказ про секундное отключение электричества и пять часов простоя?

Есть ли возможность повысить доступность приложения, если параметры доступности конкретного ЦОДа заданы и изменить их нельзя?

Ответ - можно.

Вот, например, два подхода, которые позволяют это сделать:

Географически распределённый кластер высокой доступности;
Восстановление обработки в географически удалённом резервном центре обработки данных (Disaster recovery).

Рис. Структурная схема географически распределённого кластера высокой доступности

Рис. Структурная схема для восстановления обработки в географически удалённом резервном центре обработки данных

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

В обоих случаях необходимо говорить о географической удалённости ЦОДов, чтобы максимально избежать возможности взаимосвязанных ресурсов. Например, использования одних и тех же подстанций, обеспечивающих электропитание ЦОДов. Можно вспомнить отключение электричества на юго-востоке г. Москва в мае 2008 года из-за пожара на Чагинской подстанции, New York 2003 год. Поэтому резервный ЦОД должен располагаться подальше от основного.

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

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

Где: A s – Суммарная доступность, доступность всей системы,
A i – доступность каждого параллельно соединённого компонента.

Для примера, рассчитаем систему географически распределённого кластера высокой доступности из двух ЦОДов с доступностью = 99%, каждый.

A s = 1-(1-0,99)*(1-0,99)= 0,9999 или 99,99

Т.е., два не самых надёжных ЦОДа могут обеспечить доступность на уровне mission-critical систем.

Определить доступность сервиса приложения в варианте восстановления обработки в географически удалённом резервном центре обработки данных с 15 минутным интервалом синхронизации для случая единичного сбоя рассчитывается так: надо запросить время восстановления сервиса приложения, гарантируемое СП; далее считаем процент от годового интервала - и результат вычитаем из единицы. Получаем доступность после первого сбоя. Например, для системы с 15 минутным интервалом синхронизации:

Общее количество часов в году 365*24=8760
Гарантированное время простоя = Время максимального простоя
15 минут или 0,25 часа, что составляет ≈ 0,003 от годового времени

Т.е. каждый сбой будет иметь вес в 0,003%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,997%, после второго сбоя 99,994%. Посчитаем тоже самое для системы с часовым интервалом синхронизации:

Гарантированное время восстановления = Время максимального простоя = 1 час, что составляет ≈ 0,01 от годового времени

Каждый сбой будет иметь вес в 0,01%. Таким образом, система до сбоя система имеет доступность, равную 100%, после первого сбоя, 99,99%, после второго сбоя 99,98%. Дальше, приверженцы теории вероятности могут поупражняться в оценке вероятности наступления первого, второго, третьего сбоев. Результат убедит, что влияние этого фактора ничтожно мало на получаемые результаты. Это позволяет мне рекомендовать предложенную методику для оценки доступности сервисов для Ваших приложений в облаке .

Резюмируя вышесказанное...

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

Изменение взглядов бизнеса на предоставление ИТ-услуг приводит к необходимости внедрения процесса управления их доступностью.

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

доступность - способность ИТ-услуги или ее компонентов выполнять свои функции в определенный период времени;

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

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

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

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

Планирование и разработка ИТ-услуг с учетом требований бизнеса к уровню доступности;

Оптимизация доступности ИТ-услуг путем проведения эффективных с точки зрения затрат усовершенствований;

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

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

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

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

При проектировании доступности ИТ-услуг проводится анализ ИТ-инфраструктуры с целью определения наиболее уязвимых компонентов, не имеющих резерва и способных в случае сбоя оказать негативное влияние на предоставление ИТ-услуг. В терминологии ITIL подобные компоненты называются Single Point of Failure (SPOF), и для их определения используется метод «Анализ влияния сбоев компонентов инфраструктуры» (Component Failure Impact Analysis, CFIA). Данный метод применяется для оценки и прогнозирования воздействия отказов ИТ-компонентов на ИТ-услугу. Основные цели CFIA таковы:

Определение точек сбоев, влияющих на доступность;

Анализ влияния сбоя компонентов на бизнес и пользователей;

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

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

Определение и документирование вариантов восстановления.

Для анализа рисков используется метод анализа и управления рисками (CCTA Risk Analysis and Management Method, CRAMM), в котором анализируются возможные угрозы и зависимости ИТ-компонентов, проводится оценка вероятности возникновения нестандартных ситуаций или чрезвычайных событий.

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

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

Еще один аспект планирования - определение времени простоя. Все ИТ-компоненты должны быть объектами стратегии обслуживания. В зависимости от применяемых ИТ, критичности и важности поддерживаемых конкретным ИТ-компонентом бизнес-функций частота и уровень обслуживания могут различаться. В случае необходимости предоставления услуги в режиме 24х7 следует найти оптимальный баланс между требованиями по обслуживанию ИТ-компонентов и потерями для бизнеса от простоя услуги. Утвержденные расписания обслуживания должны быть зафиксированы в соглашениях об уровне обслуживания (Service Level Agreement, SLA).

Улучшение доступности ИТ-услуг

Зачем нужно улучшать доступность? Причин может быть множество: несоответствие качества ИТ-услуг требованиям SLA; нестабильность предоставления ИТ-услуг; тенденции к снижению уровня доступности ИТ-услуг; недопустимо большие сроки восстановления; запросы со стороны бизнеса на увеличение уровня доступности.

Улучшение доступности требует обоснованных дополнительных финансовых затрат, и для установления возможности улучшения ИТ-услуг используются определенные методы и технологии, среди них анализ дерева отказов (Fault Tree Analysis, FTA) и анализ системных простоев (Systems Outage Analysis, SOA).

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

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

Определение основных причин сбоев предоставления ИТ-услуг;

Определение эффективности поддержки ИТ-услуг;

Подготовка отчетов;

Инициирование программы по исполнению принятых рекомендаций;

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

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

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

Измерение доступности ИТ-услуг

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

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

Роли и ответственности

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

Внедрение процесса

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

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

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

Эффект и проблемы

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

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

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

Отказ от внедрения процесса по причине того, что текущая доступность ИТ-услуг считается приемлемой;

Предположения, что при наличии других внедренных процессов ITSM процесс управления доступностью будет выполнен автоматически;

Сопротивление централизации в управлении ИТ-инфраструктурой со стороны ИТ-менеджеров;

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

Евгений Булычев ([email protected]) - консультант отделения «Ай-Теко Бизнес Консалтинг» (Москва).

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

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

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

Здесь может быть лирическое отступление про резервирование каналов и т.д., но у нас перед глазами есть пример – здание комплекса Москва-Сити, в котором пару лет назад неожиданным образом и основной, и резервный канал оказались от одного провайдера. А беда, как известно, не приходит одна. В итоге дважды на 7-8 часов (в рабочее время) оказывались без связи компании из рейтинга «Fortune 500».
Поэтому особо дотошные юридические службы компаний, чей бизнес особо чувствителен к качеству связи, стараются исчислять размер ущерба компании не только стоимостью не потреблённых сервисов, но и выгодой, упущенной клиентом вследствие простоя связи.

Отправные точки

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

ASR (Answer Seizure Ratio) - параметр, определяющий качество телефонного соединения в заданном направлении. ASR рассчитывается как процентное отношение числа установленных в результате вызовов телефонных соединений к общему количеству совершенных вызовов в заданном направлении.
PDD (Post Dial Delay) - параметр, определяющий период времени (в секундах), прошедший с момента вызова до момента установления телефонного соединения.
Коэффициент доступности Услуги - отношение времени перерыва в предоставлении услуг к общему времени, когда услуга должна предоставляться.

Коэффициент потери пакетов информации - отношение правильно принятых пакетов данных к общему количеству пакетов, которые были переданы по сети за определенный промежуток времени.
Временные задержки при передаче пакетов информации - промежуток времени, необходимого для передачи пакета информации между двумя сетевыми устройствами.
Достоверность передачи информации - отношение количества ошибочно переданных пакетов данных к общему числу переданных пакетов данных.
Периоды проведения работ, время оповещения абонентов и время восстановления сервисов.
Иными словами, доступность услуги 99,99% говорит о том, что оператор гарантирует не более 4,3 минут простоя связи в месяц, 99,9% - что услуга может не оказываться 43,2 минуты, а 99% - что перерыв может длиться более 7 часов. В некоторых практиках встречается разграничение доступности сети и предполагается меньшее значение параметра – в нерабочее время. На разные типы услуг (классы трафика) также предусмотрены разные значения показателей. Например, для голоса важнее всего показатель задержки – он должен быть минимальным. А скорость для него нужна невысокая, плюс часть пакетов можно терять без потери качества (примерно до 1% в зависимости от кодека). Для передачи данных на первое место выходит скорость, и потери пакетов должны стремиться к нулю.

Мировые стандарты

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

Задержка передачи сигнала (Latency, ms)

	Sprintnet		Verizon		Cable&Wireless		NTT
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	18.9	45	15.178	30	17.6	35.0	24.00	35
США	36.91	55	42.851	45	45.9	65.0	45.83	60
Азия	83.78	105	100.640	125	48.3	90.0	47.34	95
Европа-Азия	207.63	270	-	-	174.1	310.0	260.23	300
Европа-США	74.53	95	78.784	90	78.7	90.0	71.57	90

Потеря пакетов (Packet Loss, %)

	Sprintnet		Verizon		Cable&Wireless		NTT
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	0	0.3%	0.025%	0.5%	0	0.2%	0	0.3%
США	0.01%	0.3%	0.019%	0.5%	0.1%	0.2%	0	0.3%
Азия	0	0.3%	0.004%	1%	0	0.2%	0	0.3%
Европа-Азия	0	0.3%	-	-	0	0.2%	0	0.3%
Европа-США	0	0.3%	0	0.5%	0.1%	0.2%	0	0.3%

Джиттер (вариация задержки, jitter, ms)

	Sprintnet		Verizon		Cable&Wireless		NTT
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	0.0017	2	0.026	1	-	-	0	0.5
США	0.0007	2	0.058	1	-	-	0	0.5
Азия	0.0201	2	-	-	-	-	0	0.5
Европа-Азия	0.0001	2	-	-	-	-	0	0.5
Европа-США	0.0001	2	-	-	-	-	0	0.5

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

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

В случае недоступности сервиса по вине NTT, оператор устанавливает для себя рамки для выявления и решения проблемы в 15 минут – по истечению которых клиенту возмещают от 1/30 до 7/30 от ежемесячного платежа. Если SLA не соответствует скорость задержки сигнала, клиент может рассчитывать на возврат суточного платежа единоразово.

Наши реалии

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

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

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

Какие выводы нужно сделать из этих историй

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