SLA облачного провайдера: стандарты и лучшие практики
17.06.2020, Ср, 09:00, Мск , Текст: Сергей Зинкевич, директор по развитию сервисов КРОК Облачные сервисы
Когда компания принимает решение разместить в публичном облаке корневые бизнес-системы или приложения, сколько-нибудь важные для ежедневной клиентской работы, они в первую очередь обращают внимание на параметры предоставления облачной услуги. Все эти параметры должны быть отражены в соглашении об уровне сервиса — одном из двух основных документов (после договора), на который опирается заказчик при любом несоблюдении условий работы провайдера или возникновении внештатных ситуаций.
На что стоит обратить внимание при подписании SLA в первую очередь
Конечно же, на технические параметры облачной платформы: заявленный уровень доступности, производительность отдельных элементов вычислительной инфраструктуры, пропускную способность каналов связи и т.д. Как правило, этими параметрами клиенты руководствуются еще на этапе выбора поставщика услуги, так как подбирают их исходя из своих бизнес-задач и критичности размещенных в облаке систем. Однако важно зафиксировать их в документе до мельчайших подробностей.
Кроме того, мы рекомендуем обязательно обращать внимание в SLA на такой пункт, как проведение регламентных работ. В идеале они должны осуществляться без перерыва в работе облачного сервиса и с обязательным информированием заказчика как минимум за сутки. В частности, мы следуем такому правилу. В нашем соглашении говорится о том, что самое неприятное, что может случиться во время регламентных работ — это потеря за весь период несколько сетевых пакетов максимум.
Сергей Зинкевич, директор по развитию сервисов КРОК Облачные сервисы
Но такая практика принята далеко не у всех облачных провайдеров. На российском рынке есть игроки, которые планируют технологические обновления с перерывами в 5–6, иногда 8 и более часов, пусть и суммарно за весь год. Для многих клиентов это просто недопустимо. Представьте, что е-commerce сервис крупного ритейлера не будет работать в течение 8 часов — фактически целый рабочий день. Это автоматически означает упущенную выгоду: клиент не сможет оформить заказ и уйдет к тому продавцу, который обеспечит постоянную доступность сайта.
А за любые серьезные перебои и даунтаймы провайдер должен платить рублем. Классификация и объем штрафов также должны быть регламентированы в рамках SLA. Как правило, размер денежных санкций зависит от сложности возникшей проблемы и длительности ее устранения и рассчитывается как процент от месячной стоимости услуг. В ряде особо тяжелых случаев этот штраф может доходить до 100% от всего вознаграждения провайдера за отчетный период.
Что предпринять для повышения надежности арендуемой инфраструктуры
Начнем с того, что выбирать следует тех провайдеров, чьи платформы развернуты на базе минимум трех и более ЦОД. И крайне желательно, если эти дата-центры будут отвечать высоким параметрам надежности и отказоустойчивости, а также находиться в собственности провайдера. Последнее важно, так как мы знаем примеры, когда на объекты не пускали клиентов из-за конфликта между арендатором и собственником. Кроме того, различные вопросы, например, связанные с ремонтом помещений, проще также решить напрямую с владельцем объекта.
ИТ-инфраструктура КРОК работает без сбоев более 3000 дней
Отказоустойчивость и надежность без дополнительных проверок доказывает сертификат Uptime Institute. Идеально, если у поставщика есть полный комплект документов, в том числе по эксплуатации объекта. Наличие несколько площадок с подтвержденными регалиями говорит о том, что в случае форс-мажора в одном дата-центре поставщик подключит вторую и последующие площадки и таким образом минимизирует последствия выхода из строя своего облака.
Многие клиенты используют в дополнение к базовым услугам, таким как IaaS, сервисы резервного копирования. Если вдруг часть данных будет уничтожена случайно, предположим, по вине самого клиента, их легко восстановить из резервной копии. Более дорогостоящий, но в то же время и более надежный вариант — создание active-active площадки в облаке, на которую нон-стопом реплицируется информация. Она гарантирует, что даже в случае падения метеорита на один из ЦОД сети в другом останутся максимально полные и актуальные данные.
Без выстроенных коммуникаций никуда
Клиенты облачных провайдеров работают в разных часовых поясах. Многие из них предпочитают работать по ночам (по иронии судьбы как раз именно тогда, когда проводятся плановые обновления облачных платформ). Пользователи клиентских сервисов наших заказчиков также не ограничивают свою активность временем суток — они посещают сайты и делают онлайн-заказы в любое удобное время.
Какие требования возникают в результате этого к провайдеру? Конечно же, требование работать 24×7 и без выходных. Этот параметр крайне желательно прописать в SLA, а кроме того, указать в документе состав проектной команды с телефонами ответственных. Чаще всего на практике бывает так: за каждым клиентом закрепляется менеджер, и именно он как единая точка входа отвечает за запущенные проекты и находится на связи фактически круглосуточно.
При работе с заказчиками важно не формализовать коммуникации и не превращаться в бездушного робота. В любой ситуации нужно помнить, что клиент — такой же человек со своими особенностями. Например, он может быть закоренелым интровертом, предпочитающим общение в мессенджерах. Мы стараемся в этом вопросе проявлять всю клиентоориентированность, на какую только способны, потому в нашем SLA, помимо корпоративной электронной почты, всегда указаны личные телефоны менеджеров.
Доверяя, проверяй
Проблема переподписки из-за коронавируса, похоже, обострилась. Количество облачных клиентов в период карантина серьезно увеличилось — компании обратились к облакам из-за нехватки собственных ресурсов. В результате те провайдеры, которые не успели подготовиться к наплыву заказчиков, были вынуждены снизить качество сервисов путем более плотного размещения в облаке инфраструктур клиентов. И в результате, даже несмотря на то, что параметры производительности были прописаны в SLA, многие заказчики заметили ее деградацию. По сути это прямое нарушение соглашения. И в данном случае клиенту остается только попробовать урегулировать проблему, обратив внимание провайдера на невыполнение требований, или найти более ответственного поставщика услуги.
Полный текст статьи читайте на CNews
