НовостиОбзорыСобытияIT@WorkРеклама
Облака/ИТ-сервисы:

Блог

Что стоит за облачными SLA

Когда речь заходит о надежности ЦОДов, обычно указывают на какой уровень (Tier) сертифицирован тот или иной ЦОД.[spoiler] И хотя соответствие, к примеру требованиям Tier 3, подразумевает соблюдения массы условий, как правило, в разговорах упоминают только уровень доступности. В частности, для Tier 3 он должен быть не ниже 99,99%, что в годовом исчислении соответствует суммарному времени простоя не более 53 мин. В связи с ростом популярности облачных сервисов, все больше организаций волнуют вопросы и относительно их надежности и доступности. Когда на тех или иных мероприятиях начинаешь интересоваться, на что могут рассчитывать корпоративные потребители облачных услуг, получаешь стандартный ответ: в SLA-соглашениях все оговорено. Иногда в качестве иллюстрации приводят тот самый процент. Если продолжаешь занудствовать и спрашивать, как заказчику компенсируют время простоя, выходящее за рамки SLA, тебя опять же отсылают к прочтению SLA.

Недавняя публикация в InformationWeek  свидетельствует о том, что проблема с облачными SLA действительно существует, и волнует она многих. Согласно опросу, проведенному компанией Compuware, 79% пользователей облачных сервисов считают предлагаемые им SLA чересчур упрощенными, а 73% убеждены, что провайдеры скрывают от них инфраструктурные детали, способные сказаться на производительности. Как оказалось, чуть ли не единственной метрикой в облачных SLA по прежнему остается суммарное время простоя. Достижением прошедшего года считают переход ведущих облачных провайдеров Amazon EC2, Microsoft Azure и Google Compute Engine с годового уровня доступности 99,95% (4 ч 23 мин) к помесячному (не более 22 мин в месяц). Вроде бы, разница небольшая, но подобная детализация не дает возможности скомпенсировать серьезный провал в одном месяце (а он может оказаться месяцем предрождественских продаж) за счет других.

Отдельная история с компенсациями за сверхнормативный простой и иные прегрешения. Так в SLA Amazon говорится, что сверхнормативный простой или катастрофическое падение производительности компенсируется не деньгами, а дополнительным бесплатным временем использования сервиса. А компенсаций, связанных с снижением производительности, как и самих метрик такого рода в облачных SLA, как правило, и вовсе нет. Эксперты убеждены, что в этих SLA  должны быть отражены показатели производительности сервисов, гарантированное время отклика, границы эластичности (возможности оперативно наращивать и снижать потребление услуг) и другие важные характеристики. Когда это произойдет? Посмотрим.