Соглашение об уровне облачного сервиса: секреты правильного оформления

Облака уже стали стандартом в ритейле. Среди клиентов КРОК Облачные сервисы доля розничных компаний приближается к четверти с тенденцией к росту. Параллельно с этим увеличивается средний чек на услуги. Это говорит и о росте количества систем, перенесенных в облако, и о динамичном потреблении вычислительных мощностей для поддержки высоконагруженных приложений, например, платформы для real-time аналитики. А там, где затрагивается вопрос надежной работы core-бизнеса, важно соблюдение всех договоренностей с провайдером, зафиксированное в SLA (Service Level Agreement).

На что обращать внимание при составлении такого документа, рассказывает Сергей Зинкевич, продакт-менеджер КРОК Облачные сервисы.

Технические моменты

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

Опциональный, но важный момент – лучше, если здание дата-центра находится в собственности провайдера. Без посредников с ним проще выстроить отношения и легче выявить ответственных в спорных ситуациях.

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

Командная работа

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

В SLA обязательным пунктом прописываются критерии работы службы техподдержки: ее доступность, скорость и эффективность реагирования на запросы заказчика. Многие провайдеры заявляют, что работают 24х7, но по факту это происходит далеко не всегда. Обратитесь с вопросом к Help Desk и проверьте, выдерживает ли персонал компании обещанные сроки реакции. Иногда в SLA прописываются в том числе контакты ответственных сотрудников. Это может существенно ускорить решение многих вопросов, так как обращения будут направляться непосредственно управленцам, а далее спускаться к исполнителям.

Консалтинговая экспертиза

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

Общие требования к SLA и его наполнению

Подготовка хорошего SLA начинается с краткого описания системы (название, технология и т.д.) и ролей участников процесса (пользователи, сотрудники HelpDesk, перечисление подразделений компании и т.д.).

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

Если компания обладает сложной ИТ-инфраструктурой со множеством систем, можно прописать SLA на каждую. Здесь важно еще на старте сделать универсальными все метрики из SLA и их значения. Лучший вариант для этого – разбивка систем на классы (Mission Critical, Business Critical и т.д.). Необходимо помнить, что SLA – инструмент-регулятор, который нуждается в регулярном пересмотре (обычно – раз в год).