27 Июля 2020 12:56 27 Июл 2020 12:56 |

Поделиться

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

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 в качестве средства финансовой защиты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поделиться

Подписаться на новости Короткая ссылка