При заказе любых высокотехнологичных услуг поставщик и заказчик подписывают SLA (соглашение об уровне сервиса, Service Level Agreement). Документ помогает определить достаточный уровень качества предоставления услуг, а также назначить уровень компенсации в случае нарушения соглашения. От чего зависит работа облачного сервиса и что должно быть прописано в договоре SLA, рассказывает Сергей Зинкевич, директор по развитию бизнеса КРОК Облачные сервисы.

SLA можно сравнить с гарантийным талоном: в документе фиксируются все параметры оказываемой услуги. Правильно составленное приложение страхует как клиента, так и сервис-провайдера. Ранее в SLA фиксировали общую (не)доступность облака, например, 99,9, что эквивалентно простою не более 8ч 45 мин в год. Кажется, что это не так уж и много. Но облако — это продукт в первую очередь для корпоративных клиентов, а не лампочка на кухне, которая либо светит, либо не светит. Облако может «моргать» или гореть «тускло». Но недоступность почти в 9 часов в год для такой услуги — это очень много, как показывает практика.

Поэтому со временем SLA в целом по рынку стал строже и детальнее: ключевые провайдеры теперь, как правило, указывают в документах общую недоступность на уровне 99,95 (4ч 22 мин) и расписывают все важные характеристики услуги в определенных коридорах производительности.

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

Для клиентов наиболее важна производительность вычислительного оборудования и его готовность справляться с высокими нагрузками. Просто проверьте, что провайдер описал производительность своих ядер процессоров в понятных «попугаях» и дал инструкцию, как измерить. Почему «попугаи», а не модель процессора или частота? Потому что и то, и другое на производительность влияет лишь косвенно. Да и провайдер может использовать переподписку (делить 1 ядро физическое на несколько виртуальных). Таким «попугаем» у нас считается Compute Unit — единица измерения производительности виртуальных машин, сформированная на основе результатов тестирования и эталонных значений.

Также важны параметры дисковой подсистемы. Они влияют на общую производительность для конечных пользователей не меньше, а иногда и больше, чем процессоры. Основные характеристики дисков, прописанные в SLA — это время отклика и производительность (замеряется в IOPS). Это уже не «попугаи», а общепринятые метрики. Отклик должен быть в пределах 2-3 милисекунды (или в пределах 1 мс, как у нас), А IOPS — от 500 до 50 000. Более быстрые диски нужно настолько редко, поэтому не будем их отдельно рассматривать.

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

Выбираем облачного провайдера: скорость реакции

Провайдер оказывает критические для бизнеса услуги. Его работа в режиме 24/7 даже не обсуждается. Хорошим временем реакции на запросы (инциденты) считается срок до 15 минут, в идеале — 10 минут. Быстрые и понятные ответы инженеров поддержки часто имеют решающее значение. Например, в период пандемии, когда нагрузка на вычислительные ресурсы выросла в разы, многим клиентам потребовалось быстро масштабироваться и решить рабочие вопросы. Промедление с нашей стороны могло вызвать снижение скорости работы клиентских сервисов и прикладных приложений, а это уже было чревато потенциальными потерями — финансовыми и репутационным.

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

Мы советуем выбирать из тех провайдеров, чьи платформы находятся на базе как минимум трех дата-центров. Это обеспечит дополнительные гарантии доступности сервисов в случае возникновения непредвиденной ситуации, то есть потенциальной массовой аварии, например выхода из строя целого дата-центра.

Желательно, чтобы ЦОД находился в собственности провайдера и была сквозная поддержка от физического размещения оборудования до уровня клиентского сервиса.

Чтобы проверить характеристики самого ЦОДа, стоит запросить у поставщика услуги полный комплект документов, в том числе сертификат Uptime Institute.

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

***

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

Источник: Сергей Зинкевич, директор по развитию бизнеса КРОК Облачные сервисы

Версия для печати (без изображений)   Все новости