ВКС

от 250 руб/мес

Платформа корпоративных

коммуникаций

IaaS

от 490руб./мес

VMware / ПО РФ

SLA 99,95% Pay-as-you-go

HRM

от 0 руб.

Готовая HRM

от ФАКТ

HRM

от 8500 руб.

HCM-платформа

для автоматизации HR

IaaS

По запросу

ЦОД Tier III

ФЗ-152 УЗ-1 К1 и Г1 ФЗ-187

IBP

по запросу

Универсальная CPM/EPM

self-service платформа

  • IaaS

    от 490руб./мес

    VMware / ПО РФ

    SLA 99,95% Pay-as-you-go

  • HRM

    от 0 руб.

    Готовая HRM

    от ФАКТ

  • HRM

    от 8500 руб.

    HCM-платформа

    для автоматизации HR

  • IaaS

    По запросу

    ЦОД Tier III

    ФЗ-152 УЗ-1 К1 и Г1 ФЗ-187

  • IBP

    по запросу

    Универсальная CPM/EPM

    self-service платформа

  • BPM

    от 12 000 руб/год

    Цифровые процессы

    с комфортом для людей

  • IaaS

    от 249,95 руб.

    Для любых задач

    Оплата pay-as-you-go

  • IP-телефония

    от 0 руб.

    Продуманная связь

    для вашего бизнеса

  • Low-code

    от 667 руб.

    Цифровая трансформация

    с ELMA365

BPM

от 12 000 руб/год

Цифровые процессы

с комфортом для людей

IaaS

от 249,95 руб.

Для любых задач

Оплата pay-as-you-go

IP-телефония

от 0 руб.

Продуманная связь

для вашего бизнеса

Low-code

от 667 руб.

Цифровая трансформация

с ELMA365

Корпоративные мессенджеры

от 250 руб/мес

Защищенная платформа

коммуникаций

Корпоративные мессенджеры

От 200 руб/мес

Передовое

решение

На что обратить внимание в SLA и о чем позаботиться помимо SLA

Бизнес Интернет Цифровизация ИТ в банках ИТ в госсекторе Ритейл Маркет

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

CNews: На что следует обратить внимание в SLA?

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

Приведу для примера выдержку из SLA глобального облачного провайдера с гарантированной доступностью сервисов 99,99%. В документе говорится: «Unavailable» means that all connection requests to the running Multi-AZ instance fail during a 1 minute interval». Получается, что если подключения к базе не отрабатывают даже в течение 59 секунд, провайдер не считает это даунтаймом. Не признает он даунтаймом и ошибки, вызванные неправильным сайзингом и плановыми работами.

Говоря прямо, недоступность инфраструктуры во время плановых работ не считают даунтаймом большинство провайдеров. При этом некоторые никак не оговаривают и максимальную продолжительность таковых. В теории это дает им возможность каждый день по несколько часов что-то «чинить», соблюдая при этом самые жесткие параметры SLA. Другой типичный пример — доступность виртуальных машин по сети. Спросите у провайдера, учитывает ли он при оценке недоступности процент потерь трафика?

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

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

CNews: На что смотреть кроме SLA (что является индикатором того, что заявленный уровень сервиса выполним в принципе)?

Александр Тугов: Заявляемый уровень сервиса — это именно заявление. На практике оно может быть каким угодно — бумага все стерпит. В реальности отказоустойчивость зависит от архитектуры, технологий, мониторинга систем, опытности инженеров и многого другого.

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

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

CNews: Какие рекомендации заказчикам вы можете дать? Что предпринять для повышения надежности арендуемой инфраструктуры?

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

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

CNews: Как правильно действовать при аварии?

Александр Тугов: Крайне важно заранее составить аварийный план восстановления (Disaster Recovery Plan или DRP). Это основной инструмент в обеспечении непрерывности бизнеса. Вот основные шаги:

1. Ранжируйте бизнес-задачи и определите, простой каких сервисов принесет наибольшие убытки. Исходя из этого, обозначьте допустимые сроки простоя (по сути, это внутренний SLA с указанием целевых значений RTO/RPO) и максимальную стоимость технических решений, которое эти сроки обеспечат.

2. Поручите техническому директору найти несколько решений, которые соответствуют выделенному бюджету и внутреннему SLA.

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

4. Документально оформите и утвердите все элементы DRP: техническое решение, инструкции для сотрудников, список ответственных лиц.

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

Короткая ссылка