Поделиться
Специалисты LanCloud — подробно и откровенно про SLA на IaaS
SLA (Service Level Agreement), или «Соглашение об уровне сервиса», является одним из ключевых параметров договора услуг облачных сервисов. Если в самом договоре на облачные сервисы, как правило, прописываются только количественные характеристики вычислительных ресурсов и сервисов, то в именно в SLA прописываются качественные показатели услуги, такие как надежность, производительность, зоны ответственности Исполнителя, а также штрафы за нарушение обозначенных условий. Таким образом, соглашение об уровне сервиса — это обязательный документ, который должен являться неотъемлемой частью договора услуг облачных сервисов.
К сожалению, заказчики не всегда обращают внимание на тонкости SLA, и уже в процессе использования услуг сталкиваются с непредвиденными проблемами, которые вполне можно было избежать или, как минимум, предвидеть еще на этапе заключения договора. Например, бывает, что сервис не работал несколько дней, а оказывается, что по SLA это не является нарушением, или SLA постоянно нарушается, но в договоре за это не предусмотрено никакой компенсации.
Бывает, заказчик арендовал виртуальный сервер с SSD-дисками, но получил производительность меньше, чем у самого дешевого SATA-диска, и это тоже не является нарушением SLA, т.к. производительность дисков в соглашении просто не была зафиксирована. Наиболее серьезные последствия связаны с утратой информации, когда в результате какого-либо сбоя происходит повреждение данных клиента, и внезапно выясняется, что резервное копирование в SLA прописано не было. И, к удивлению многих заказчиков, у подавляющего большинства облачных провайдеров резервное копирование отсутствует в принципе или включается только как отдельная платная услуга.
В рамках данной статьи мы подробно и обстоятельно разберемся со всеми тонкостями SLA-соглашений.
Уровень доступности (SLA — 99,9999%)
Как правило, доступность сервиса выражается в %. В договорах облачных провайдеров можно увидеть цифры вида 99,9% или 99,999% и т.д., но что обозначают эти девятки?
В общем случае уровень доступности сервиса определяется как отношение времени рабочего состояния сервиса в заданном временном интервале к самому временному интервалу. Допустим, в календарном месяце сервис не работал 8 минут. Тогда уровень доступности составит (30*24*60 – 8) / (30*24*60) * 100% = 99,982%, и можно говорить о том, что фактический SLA (уровень доступности) в этом месяце составил 99,982%.
Но в договоре на облачные сервисы прописывается не фактический SLA, а тот SLA, который провайдер готов гарантировать, и в случае нарушения которого провайдер должен нести какую-либо ответственность.
Финансовая гарантия SLA
Одним из ключевых параметров, на которые стоит обратить внимание, является финансовая ответственность провайдера за нарушение SLA. Например, провайдер может декларировать SLA «пять девяток» 99,999%, но если в договоре нет финансовой ответственности за нарушения данных показателей, то смысла в этих цифрах нет, и можно написать хоть 100%.
Но даже если финансовая ответственность прописана, то важен еще и размер этой ответственности. Так, например, зачастую размер ответственности прописывается как отношение минут недоступности сервиса за месяц к общему числу минут в месяце, умноженному на стоимость услуг в данном месяце.
Предположим, стоимость услуг составляет 100 000 р./мес., и сервис был недоступен 2 дня, то размер компенсации будет равен: (2*24*60)/(30*24*60) * 100 000 = 6600 р., что очень несущественно для провайдера, но может быть очень существенно с точки зрения убытков бизнеса заказчика за эти 2 дня простоя.
Да, 100-процентная компенсация может быть несоизмерима с убытками бизнеса заказчика за эти 1,5 дня, но это существенный убыток для провайдера. Убыток, который является существенной мотивацией не допускать подобных сбоев. Тем более, в случае сбоя массового характера, провайдер должен вернуть деньги не одному клиенту, а всем сразу.
Зоны ответственности Исполнителя
Важно, чтобы в договоре было прописано, на что именно Исполнитель гарантирует обозначенный SLA. Так, многие провайдеры, как под копирку, пишут SLA — 99,982%, а заказчик не уточняет, на что именно эти цифры распространяются. Следует помнить, что 99,982% — это среднестатистический уровень доступности TIER-III ЦОД-а, но никак не доступность арендуемых заказчиком сервисов.
Также необходимо различать гарантию доступности сервера и гарантию доступности сервиса. Если клиент арендует виртуальные серверы, то в зоне ответственности провайдера находится только работа серверного оборудования, системы хранения данных, гипервизора и сети, а все, что работает внутри виртуального сервера, находится в зоне ответственности заказчика.
Предположим, гипервизор и виртуальная машина работают, а внутри виртуального сервера не запускается 1С:Предприятие. С этой проблемой клиенту придется разбираться самостоятельно, под SLA она не попадает.
Если же заказчик использует услугу SaaS, например, Cloud 1C, то за работу сервиса 1С: Предприятие будет отвечать непосредственно провайдер, и это должно быть прописано в договоре.
Таким образом, в SLA на IaaS гарантируется только работа виртуального сервера, а в SLA на SaaS гарантируется работа конкретного сервиса (будь то 1С, Exchange, облачная телефония или иной сервис).
Гарантия производительности
В SLA обязательно должны быть зафиксированы гарантированные показатели производительности по каждому арендуемому вычислительному ресурсу или сервису.
Если заказчик приобретает облачный виртуальный сервер с конфигурацией 8 vCPU, 32 GB vRAM, 6000 ГБ SSD, то у него сразу должен возникнуть вопрос, какую конкретную производительность имеют vCPU и SSD. Так, провайдер может использовать старые процессоры Xeon E5 с частотой 2.2 ГГц или Xeon Scalable Gold последнего поколения с частотой 4 ГГц. Производительность IaaS на базе Xeon Scalable Gold будет в 2-4 раза выше.
Но даже если провайдер заявляет, что у него используются самые современные Intel Xeon Scalable Gold 6254 с частотой 3,1 ГГц, это еще не означает, что заказчик получит должную производительность. Система виртуализации позволяет назначить 1 физическое ядро одновременно двум, трем, восьми или десяти виртуальным машинам разных клиентов. Соответственно, каждый заказчик получит условно 1/2, 1/3, 1/8 или 1/10 производительности реального физического ядра.
Интересный момент — изнутри виртуальной машины (из панели управления) узнать об этом невозможно. Просто в какой-то момент ваша 1С начинает работать в несколько раз медленнее…
Предъявлять провайдеру претензии практически бесполезно, так как жалоба «тормозит 1С» не является измеримым критерием в случае услуги IaaS.
Как быть? Необходимо зафиксировать в SLA производительность процессорного ядра внутри виртуальной машины, которую можно измерить множеством бесплатных утилит, например, Benchmark в CPU-Z или тест производительности MIPS (Million Instructions Per Second) в архиваторе 7-Zip.
В таком случае, если заказчик видит, что 1С тормозит, он может измерить производительность процессора, и сравнить ее с указанными в SLA цифрами.
То же самое касается и дисков. Внутри виртуальной машины не видно, какой тип диска подключен. Можно продать заказчику SSD, а на самом деле «положить» виртуальную машину на самый дешёвый SATA-диск c черепичной записью (SMR — Shielded Magnetic Recording). Если уж именитых вендоров уличали в том, что под видом PMR продавались SMR, то что говорить про обычных российских хостеров…
Но и SSD бывает разных типов, начиная от медленных и дешевых QLC SATA SSD и заканчивая сверхбыстрыми Optane NVMe. Цены на разные модификации SSD могут отличаться в 100 и более раз.
Понятное дело, что и приложения на разных дисках будут работать по-разному. Например, СУБД, такие как Microsoft SQL Server, особенно критичны к скорости работы дисковой подсистемы.
Соответственно, как и в случае с vCPU, важно зафиксировать в SLA минимальную производительность жестких дисков, чтобы заказчик всегда мог протестировать и определить, соответствует ли реальная производительность заявленной.
Скорость работы жестких дисков определяется двумя основными характеристиками — это скорость последовательного чтения и записи, которая выражается в МБайт/сек, а также скорость случайного чтения и записи, которая выражается в IOPS (количество операций ввода/вывода в секунду, обычно блоком 4K). Например, линейная скорость у SSD и SATA дисковых массивов может быть примерно одинаковая — 500 МБайт/с, но IOPS у SSD в 100-1000 раз выше. И это легко измеряется при помощи бесплатных утилит CrystalDiskMark, diskspd, Intel IOMeter и других.
Итог один: в SLA должны быть указаны детальные измеримые характеристики IaaS (частота процессора, скорость работы дисков и др.). Те характеристики, которые сможет измерить и заказчик IaaS-услуг, чтобы оценить качество представляемых сервисов.
Гарантия целостности данных, или то, о чем никто не вспоминает никогда
Немаловажным критерием является гарантия сохранности/целостности данных заказчика. Одно дело 30 минут недоступности какого-то виртуального сервера или сервиса электронной почты. Другое дело — безвозвратная утеря критической для бизнеса информации.
Условно, представьте ситуацию, когда вы через 30 минут почтовый сервер вновь стал доступен, новая почта приходит и отправляется, но вашей старой почты за 5 лет больше нет. Или, что еще хуже, пропала база 1С:Предприятие за 10 лет работы. Что про это говорится в SLA?
В большинстве случаев в SLA такая ситуация вообще не прописана, а, значит, не предусмотрено и ответственности и, что еще хуже, особых мер во избежание подобных инцидентов провайдером не применяется.
У подавляющего большинства провайдеров, резервное копирование отсутствует как класс, причем даже у крупных и известных. Взять хотя бы Office 365 от Microsoft. Резервного копирования там нет даже за доплату. Виртуальные машины Azure тоже по умолчанию не резервируются. За доплату можно приобрести Azure Backup, но многие ли это делают?
Вывод прост — на этапе заключения договора с провайдером необходимо тщательно проработать в SLA политики обеспечения целостности и сохранности всей критической информации. Причем важно не путать вопрос обеспечения доступности данных и их целостности и сохранности.
К примеру, следует понимать, что отказоустойчивые RAID-массивы, многоконтроллерные SAN-хранилища и геораспределенные кластеры обеспечивают только доступность информации (т.е. минимизируют время простоя в случае сбоя), но не обеспечивают сохранность данных. Ни один RAID-массив не защитит от вируса-шифровальщика, взлома, повреждения данных из-за программного сбоя или банального (возможно, злонамеренного) удаления данных пользователем. От этого может защитить только правильно разработанная и внедренная политика резервного копирования, которая обязательно должна быть зафиксирована в SLA.
Компания LanCloud для всех арендуемых заказчиком виртуальных серверов по умолчанию обеспечивает бесплатное еженедельное резервное копирование, даже если заказчик его не заказывал. И это прописано в SLA для всех жестких дисков, кроме самых дешевых SATA R6, которые как раз и рекомендуется использовать для хранения резервных копий.
Еженедельное резервное копирование может не удовлетворять требованиям для наиболее критичных сервисов. В этом случае заказчик за дополнительную оплату может подключить сервис Cloud Backup и настроить более частое резервное копирование.
Кстати, для SaaS-сервиса Cloud 1C в SLA LanCloud по умолчанию предоставляется резервирование 4 раза в день, а резервные копии хранятся 30 дней. Cloud Exchange резервируется 1 раз в неделю, но имеет встроенные механизмы восстановления удаленных писем и ящиков в течение 30 дней.
Сегодня в SLA с некоторыми клиентами у нас прописано, что в случае утери информации LanCloud должен вернуть сумму, уплаченную заказчиком за последний год. Поэтому для сохранности данных клиентов предпринимаются все технически возможные и организационные меры.
История сбоев LanCloud: чистосердечное признание
За 10 лет работы облачной платформы LanCloud сбои в системе происходили всего несколько раз.
Самый длительный простой был в 2014г. На тот момент LanCloud размещалcя не в ЦОД TIER-III, и произошло выгорание корневого маршрутизатора у оператора связи. На восстановление работоспособности ушло около 3,5 часов. Согласно SLA заказчикам было выплачено 25% от месячной суммы платежа. После переезда в ЦОД TIER-III проблемы с каналами не возникли ни разу. Более того, сейчас сервисы работают одновременно по 4 независимым интернет-каналам.
Дважды наблюдались инфраструктурные сбои с простоем примерно в 1 час. Оба раза из-за ошибок в программном обеспечении гипервизора отказывал кластер виртуализации. Данную ошибку Microsoft исправил в 2016 году. Мы возвращали заказчикам 25% уплаченных денег.
С 2016 г. глобальных сбоев не было, разве что редкие и кратковременные сбои некоторых отдельных сервисов с простоем не более 5 минут. Например, 1 сервер кластера выпал в BSOD после установки обновлений.
За 10 лет работы LanCloud имел место быть всего один случай частичной утери данных, и тот был связан с человеческим фактором: инженер по ошибке удалил боевую базу 1С вместо тестовой. Вскоре база была восстановлена из бэкапа (для того они и делаются), но заказчик потерял результаты последних 4 часов работы. Мы вернули заказчику месячную стоимость оплаченных им сервисов, и он продолжил с нами работать.
Подводя итог, следует подчеркнуть, что хорошо проработанный SLA — это основа надежности IaaS и тот самый документ, который подчеркивает серьезность провайдера к построению безотказной облачной инфраструктуры. Ведь даже если компенсации по SLA не являются существенными для бизнеса заказчиков, то они всегда существенны для бизнеса самого облачного провайдера.
Короткая ссылка
