Поделиться
Как разобраться в SLA облачной платформы: основные моменты
Число компаний, желающих перенести свою инфраструктуру в облако, растет с каждым годом. Вместе с этим увеличивается и количество облачных провайдеров, которые предлагают свои услуги бизнесу. На что обратить внимание при выборе такого партнера и какие условия обязательно должны быть в соглашении об уровне обслуживания? Об этом рассказывает Владимир Свиридов, менеджер продуктов в SberCloud.
SLA — это что?
Service level agreement (SLA) — это соглашение об уровне сервиса, которое облачный провайдер заключает с клиентами. Документ содержит информацию о том, какие услуги будут предоставлены и на каких условиях — например, там прописывают время реагирования на заявки, описывают процедуры отчетов и технические параметры инфраструктуры. Иными словами, SLA позволяет сформировать ожидания от работы с облачной платформой и взаимодействовать с ней на основе заранее сформулированных договоренностей.
Для этого заказчику необходимо свободно ориентироваться в соглашении об уровне сервиса, чтобы понимать, за что он платит деньги, и не подвергать корпоративные данные и приложения риску — например, если они требуют одного типа оборудования и защиты, а на деле клиент получает иной набор услуг.
Основное отличие от обычного договора состоит в том, что SLA прописан гораздо подробнее с точки зрения отдельных сервисов — с формулами и математическими расчетами — и может составлять десятки страниц. На первый взгляд, такой документ выглядит довольно сложным, однако разобраться в нем можно, не обладая глубокими познаниями в сфере облачных технологий.
На что обратить внимание
Ключевым пунктом в SLA является фактическая доступность облака — это те самые «девятки», описывающие максимально возможное время простоя инфраструктуры. В связи с этим соглашение об уровне услуг должно обязательно содержать технические параметры оценки доступности, а также гарантированные характеристики платформы — например, производительность и latency систем хранения данных и время готовности CPU, зависящее от переподписки ресурсов провайдера. Отдельное внимание в этом отношении нужно уделить пункту, который посвящен оплате услуг — там должна быть указана валюта и стоимость (фиксированная абонентская плата или тарифная сетка), а также размер компенсации за нарушение условий договора.
Также в SLA должны быть прописаны исключения, при которых провайдер не гарантирует доступность. Поскольку этот раздел освобождает его от выполнения обязанностей, список должен быть строгим. Часто облачные платформы просят послаблений в случае выхода из строя оборудования, за которое отвечают третьи лица — например, при серьезной аварии на стороне интернет-провайдера.
При выборе партнера важно удостовериться в надежности дата-центра, где размещена облачная инфраструктура, поскольку этот фактор напрямую влияет на показатели доступности. Многие компании с готовностью отвечают на вопросы и даже проводят небольшие экскурсии в ЦОДе. В некоторых случаях самостоятельно изучать все нюансы устройства и ездить по ЦОД может быть сложно, поэтому есть более простой способ — проверить наличие сертификации от Uptime Institute для ЦОД.
Такая сертификация помогает оценить, насколько отказоустойчива облачная ИТ-инфраструктура — по механическим, электрическим и даже архитектурным аспектам. В классификации представлены дата-центры четырех уровней (tier). Те, что находятся на первом, защищены от ошибок, вызванных человеческим фактором, а последующие — от непредвиденных отказов, что достигается благодаря резервным источникам питания на топливных элементах, а также кластеризации на уровне приложений и сетевых образов виртуальных машин.
Несмотря на то, что каждый последующий Tier предлагает более высокую отказоустойчивость инфраструктуры, это не означает, что он лучше предыдущего. Просто все они ориентированы на разные задачи. Например, малому бизнесу и стартапам подойдут дата-центры первых уровней — их проектам редко нужно резервирование сетевых кабелей.
Однако более крупным фирмам, для которых даже кратковременная остановка виртуальных машин чревата серьезными финансовыми потерями, стоит обратить внимание на ЦОДы класса Tier III — именно такой уровень надежности ЦОДов обеспечивает стабильную работу наших облачных платформ — SberCloud.Advanced и SberCloud.Enterprise. Замечу, что некоторые провайдеры заявляют о сертификации с плюсом (например, Tier II+), когда один или несколько компонентов превышают необходимые требования UI. Однако это, в большинстве случаев, не более чем маркетинговый ход, так как надежность облачной платформы принято рассчитывать по самому слабому звену.
Помимо сертификата Uptime Institute стоит дополнительно обратить внимание и на физическую защищенность площадки, где размещено оборудование провайдера. Существуют дата-центры, расположенные внутри горы и отгороженные от внешнего мира рвом с водой или толстой дверью ядерного бункера. Для абсолютного большинства компаний такие меры будут излишними, однако часто на территории дата-центров Tier III и Tier IV имеются камеры видеонаблюдения, датчики движения, вооруженная охрана и даже шлюзовые кабины с биометрическими сканерами. Также на таких объектах действует строгий пропускной режим, а доступ посторонних к серверам ограничен.
Еще одним гарантом высокой защищенности будет наличие у провайдера сертификата соответствия требованиям международного стандарта ISO/IEC 27001. В его основу положены лучшие мировые практики в сфере информационной безопасности: по защите приложений, сетей и других технологических решений. Недавно такой сертификат получил SberCloud, и теперь мы можем активнее предлагать свои услуги иностранным компаниям.
При выборе провайдера и изучении SLA необходимо обращать внимание не только на «проценты доступности» и наличие сертификатов. Нужно изучить, насколько поддержка провайдера готова к решению инцидентов. Так, в соглашении о качестве услуг должно быть прописано время работы технических специалистов и сроки реакции на обращения. Например, у нас поддержка работает круглосуточно в рабочие и выходные дни, при этом критические сбои, которые влекут потерю работоспособности сервисов, мы устраняем за четыре часа, а стандартные запросы, не влияющие на работу приложений — за сутки. Мы оповещаем о плановых работах на «железе» в нескольких каналах коммуникаций, чтобы клиенты смогли сформировать ожидания и подготовиться.
За что отвечает облачная платформа
SLA также определяет границы ответственности облачной платформы и ее клиентов. В частности, там прописаны территориальные параметры, которые определяют, как и где оказывается сервис, и задачи, за которые отвечает каждая сторона соглашения. Обычно на плечи провайдера ложится поддержка работоспособности ЦОД, запуск и остановка виртуальных машин, реализация сетевого доступа и обслуживание «железа» с гипервизором, изолирующим клиентские приложения друг от друга.
Еще облачная платформа предлагает возможность разместить свои сервисы и приложения на нескольких удаленных друг от друга площадках. Так клиент получает возможность построить географически распределенную инфраструктуру, устойчивую к сбоям. Мы в SberCloud дополнительно предлагаем сервис репликации виртуальных машин. При временной недоступности основного окружения или обрыве магистрали клиент может самостоятельно переключиться на реплику в другом ЦОД и продолжить работу в обычном режиме.
Клиент, в свою очередь, отвечает за используемые приложения и операционные системы, управляет доступом к ним. Однако он может заказать дополнительные сервисы (обычно они имеют свой SLA) у провайдера и расширить его зону ответственности. Например, для работы с бэкапами клиенты SberCloud, использующие облако SberCloud.Advanced, могут подключить службы резервного копирования или аварийного восстановления, клиентам «Виртуального ЦОДа» доступна услуга аварийного восстановления на основе VMware vCloud Availability. Эти сервисы позволяют минимизировать затраты на аппаратные и программные средства и их дальнейшее сопровождение. Также наши специалисты оказывают профессиональные услуги в реализации георезервированных инфраструктур заказчиков на базе площадок SberCloud, помогают решать нетипичные вопросы и дают консультации по составлению планов миграции и выборе инструментария.
Что запомнить
Подведу краткие итоги — на что обратить внимание при изучении облачного SLA:
- В соглашении должна быть прописана доступность инфраструктуры. Она будет гарантом того, что неполадки устранят в строго отведенное время.
- Cертификация Uptime Institute поможет понять, какой ЦОД стоит за той или иной облачной платформой. К выбору ЦОДа нужно подходить с учетом задач, стоящих перед вашей организацией. К значку «плюс» рядом с классом дата-центра нужно относиться со здоровой долей скептицизма — он не влияет на общую надежность инфраструктуры.
- Важно обращать внимание на защищенность «железа». Пропускной режим, видеонаблюдение и охрана территории — важные факторы безопасности.
- В SLA должны быть расписаны задачи, за которые отвечают все стороны соглашения — понимание этих процессов поможет сэкономить время и средства на настройке компонентов ИТ-инфраструктуры.
- Поговорите с техподдержкой провайдера. Если специалисты готовы вникать в ваши задачи и предлагать гибкие решения — это хороший знак.
Поделиться
Короткая ссылка
