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

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

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

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

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

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

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

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

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

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