Для чего нужен SLA и что кроется под заветными процентами

Что такое SLA

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

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

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

Кому выгоден SLA и в чём его особенности

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

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

Соглашение об уровне обслуживания фиксирует следующие требования:

• Однозначность. Максимальная прозрачность в отношениях достигается за счёт отказа от расплывчатых формулировок, которые могут трактоваться двояко. Клиент и провайдер оперируют одинаковыми терминами и понимают друг друга.


• Ответственность. В документе чётко определяются обязанности облачного провайдера и пользователя услуги.


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


• Контроль сроков. Провайдером устанавливаются сроки для решения инцидентов и фиксируются условия штрафа за несоблюдение этих сроков.

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

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

Время реакции на инциденты и другие цифры

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

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

Время инцидента = Время реакции на произошедшее + Время решения инцидента

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

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

Доступность — это те самые девятки, которые показываются как SLA. И в них кроется особая магия. Посмотрите:

Вы заметили, как с ростом процентной точности снижается время простоя? 99% — это почти 4 дня простоя в год, а заявленные Cloud4Y 99,982% — всего полтора часа. Разница по времени колоссальная, хотя по цифрам — меньше 1 процента.

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

От чего зависят проценты? От организации инфраструктуры провайдера. Определённый уровень отказоустойчивости сервиса напрямую зависит от того, как построена виртуальная инфраструктура. Уровень доступности в 99,95% требует от провайдера наличия как минимум одного кластера active-passive. Показатель 99,982% дают распределённые системы с использованием нескольких ЦОДов Tier III. У Cloud4Y для обеспечения такого уровня доступности используется Hi-End оборудование корпоративного уровня, каждый элемент нашей инфраструктуры многократно дублируется, а информация передаётся по защищённым каналам и хранится в современных дата-центрах, расположенных в России и за рубежом.

Подчеркнём, что 99,99% и тем более 99,999% не должны быть самоцелью. Во-первых, такой уровень доступности будет стоить сильно дороже. Во-вторых, он не всегда нужен. Да, Cloud4Y может предложить некоторые сервисы с таким уровнем доступности. Но подавляющему большинству клиентов достаточно базового 99,982%.

Ещё один интересный нюанс — совокупная доступность. Она считается по наименьшему показателю. Если, к примеру, ваше приложение имеет доступность 99,95%, а дата-центр и облако, в котором оно развёрнуто — 99,982%, то общая доступность всё равно будет 99,95%. Всё определяется самым слабым звеном, не забывайте об этом. Нестабильное, часто сбоящее приложение не спасёт даже самое надёжное геораспределённое решение.

Чтобы снять все вопросы, приведём заявленный уровень доступности дата-центров разного уровня:

Что ещё может учитываться в SLA

Несомненно, доступность является самым важным параметром облачных ИТ-сервисов. Но виртуальные машины могут здорово потрепать нервы и при 100% доступности. Сетевые задержки, недостаточное количество IOPS, медленная СХД — эти и другие проблемы тоже нужно предусмотреть. Какие метрики нужно прописать в SLA?

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


• Производительность СХД (IOPS). Метрика IOPS показывает количество операций в секунду. Это важный параметр, поскольку разные типы дисков имеют разную скорость чтения/записи. Подсчёт IOPS показывает, сколько операций ввода-вывода СХД может обработать за секунду или другой период времени. Тип СХД, размер блока для чтения/записи, возможность уменьшения IOPS от эталонного значения — всё это можно прописать в SLA.


• Производительность СХД (скорость доступа к диску на ВМ). Эта метрика дополняет предыдущую, так как если СХД не сможет быстро передавать на ВМ большой объём данных, то работа будет похожа на пошаговую стратегию. Задержки должны быть меньше 50 мс, и это тоже прописывается в Соглашении.


• Сетевые задержки. Средний показатель сетевых задержек не должен превышать 5 мс. Не забывайте, что SLA подразумевает ответственность за сетевую задержку в пределах сети передачи данных провайдером.


• Потери пакетов. Процент потери пакетов может колебаться в пределах от 0 до 1%. Если потери пакетов превышают норму, это свидетельствует об ошибках в настройках системы или каналах связи.

Вместо заключения

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

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