SLA облачного провайдера: стандарты и лучшие практики

На что стоит обратить внимание при подписании SLA в первую очередь

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

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

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

А за любые серьезные перебои и даунтаймы провайдер должен платить рублем. Классификация и объем штрафов также должны быть регламентированы в рамках SLA. Как правило, размер денежных санкций зависит от сложности возникшей проблемы и длительности ее устранения и рассчитывается как процент от месячной стоимости услуг. В ряде особо тяжелых случаев этот штраф может доходить до 100% от всего вознаграждения провайдера за отчетный период.

Что предпринять для повышения надежности арендуемой инфраструктуры

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

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

Многие клиенты используют в дополнение к базовым услугам, таким как IaaS, сервисы резервного копирования. Если вдруг часть данных будет уничтожена случайно, предположим, по вине самого клиента, их легко восстановить из резервной копии. Более дорогостоящий, но в то же время и более надежный вариант — создание active-active площадки в облаке, на которую нон-стопом реплицируется информация. Она гарантирует, что даже в случае падения метеорита на один из ЦОД сети в другом останутся максимально полные и актуальные данные.

Без выстроенных коммуникаций никуда

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

Какие требования возникают в результате этого к провайдеру? Конечно же, требование работать 24х7 и без выходных. Этот параметр крайне желательно прописать в SLA, а кроме того, указать в документе состав проектной команды с телефонами ответственных. Чаще всего на практике бывает так: за каждым клиентом закрепляется менеджер, и именно он как единая точка входа отвечает за запущенные проекты и находится на связи фактически круглосуточно.