SLA (Service Level Agreement) – часто встречающаяся у поставщиков сервиса форма гарантии надежности сервиса. Обычно SLA предлагается в виде оферты – и либо вы довольны и пользуетесь сервисом, либо ищете другой сервис. Типичная формулировка – «industry leading 99,95% monthly uptime SLA», который вроде бы должен устроить большинство пользователей.
Обычно потенциальный пользователь, прочитав про «99,95% monthly uptime SLA», бывает очень даже доволен – гарантия отсутствия простоев в течение более чем 21 минуты в месяц длиной 30 дней звучит довольно многообещающе.
Все относительно просто, пока вы только потребляете услугу облачного сервиса для собственных нужд. Посмотрели на 99,95%, подумали о не более чем 21 минуте в месяц – впечатлились и довольны. Что если вы сами создаете сервис на основе другого сервиса и решаете, какой SLA вы могли бы предложить?
Вот, например, сервис обработки изображений (подозрительно похожий на ABBYY Cloud OCR SDK). Какой SLA можно предложить к такому сервису? Казалось бы, нужно взять все зависимости от других сервисов, внимательно прочитать их SLA, посмотреть на число девяток, и решить, сколько девяток после запятой можно написать в свой SLA.
Предположим, сервис обработки изображений работает в Windows Azure и использует так называемые web и worker роли из Azure Cloud Services для исполнения кода и Azure Storage для хранения данных. Отлично. Открываем SLA по Cloud Services и видим там, что гарантируется доступность экземпляров ролей в течение 99,95% в течение месяца (при условии, что у каждой роли не менее двух экземпляров). Открываем SLA по Azure Storage и видим там, что гарантируется выполнение не менее 99,9% запросов к хранилищу. В случае если уровень качества не соответствует гарантированному, нужно обращаться в поддержку – и тогда поставщик вернет часть денег.
Это было очень краткое содержание SLA двух указанных сервисов. Если вы используете любой из этих сервисов, вам стоит внимательно прочитать и учесть все оговорки.
Принципиально важно следующее: даже в самом худшем случае вам вернут относительно небольшую сумму денег, которая покроет… да ничего она не покроет, потому что привязана к доле стоимости потребленной услуги, а стоимость использования облачных сервисов очень низкая по сравнению, например, с оплатой труда сотрудника, который будет обращаться в поддержку поставщика услуги. Смысл SLA с тремя девятками очень простой: «дорогие пользователи, это очень надежный сервис, мы очень стараемся, УЗБАГОЙТЕСЬ и пользуйтесь, счет выставим до 10 числа следующего месяца», SLA по сути задает ожидания от сервиса, что тоже очень важно. Если бы «гарантировалась» доступность в течение, например, 15% времени, ожидания от сервиса были бы принципиально другими.
Возвращаемся теперь в вопросу о том, какие гарантии можно дать своим пользователям, если сервис существенно зависит от другого сервиса с описанными выше SLA. Вроде бы гарантируется доступность машин, на которых выполняется код, в течение не менее 99,95% времени. Часть обращений к хранилищу может завершиться неудачно, но речь о не более чем одной десятой процента – не страшно, придется проектировать сервис так, чтобы неудачно выполненные операции с хранилищем повторялись несколько раз с увеличивающейся паузой, а если и после нескольких попыток операция не выполнилась, будем сбрасывать запрос пользователя – если это будет происходить не слишком часто, пользователь будет вполне доволен.
Соответственно, после скольких-то совещаний и двух недель переписки со всеми в копии мы можем все на все перемножить и решить, что можем предложить, например, работоспособность сервиса в течение 99,9% времени в течение месяца. Сформулировав такой SLA, мы говорим своим пользователям «у нас сервис надежный, пользуйтесь, все будет хорошо, а если нет – починим очень быстро, БЕЗ ПАНИКИ».
Вы публикуете такой SLA и через какое-то время КРАЙНЕ НЕОЖИДАННО…
… вы осознаете, что нужно очень срочно опубликовать исправление какой-то крайне досадной ошибки. Или нужно сменить настройки на уровне инфраструктуры. Или сервис сам понял, что выросла нагрузка, и решил, что нужно выдать команду на масштабирование.
Для всех перечисленных действий используется некий дополнительный сервис управления в инфраструктуре облака (возможно, вы используете портал, который работает поверх такого сервиса, или программу, которая отправляет обращения к такому сервису). Это очень важный сервис, именно благодаря его существованию облака такие гибкие и удобные в использовании. И этот очень важный сервис именно в этот очень важный момент, когда вот очень-очень срочно нужно что-то сделать, отказывается обработать ваш запрос.
В многочисленных презентациях, скринкастах и инструкциях вы видите, как этим сервисом пользуются налево и направо при разворачивании новых виртуальных машин, публикации пакета с начинкой сервиса и многих других операциях. Никто не говорит вам одну важную вещь: этот сервис – ваша единственная возможность управлять облаком. Как только с сервисом управления что-нибудь не в порядке, у вас потенциально очень большие проблемы.
Возвращаемся к формулировке своего SLA. Очевидно, что нужно как-то предусмотреть необходимость таких операций, как масштабирование и публикация обновлений, и учесть ее в своем SLA. И да, наш сервис вроде бы должен обрабатывать большое (и неизвестное заранее) число изображений от пользователей достаточно быстро, а для этого он должен уметь масштабироваться. И эти необходимые операции требуют использования «вспомогательного» сервиса управления.
Логично тогда посмотреть на SLA этого сервиса управления, чтобы понимать, чего от него ожидать.
В Windows Azure для управления инфраструктурой используется Management API (портал управления и cmdlet’ы тоже работают через него). Значит, открываем SLA сервиса Management API и…
…а нет, не получится ознакомиться с этим документом, потому что его просто нет. И у Amazon EC2 тоже нет SLA сервиса управления инфраструктурой.
Wait… OH SHI~
Да, мы только что едва не проигнорировали полное отсутствие SLA у сервиса, от которого наш сервис зависит существенным образом. Речь не только об обновлениях кода (которые как будто можно отложить, а на самом деле иногда и их нужно публиковать очень срочно) — способность масштабироваться нужна постоянно.
Почему же нет SLA к сервису управления? Можно только предполагать.
Можно предположить, что не так просто сделать инфраструктуру управления облаком достаточно надежной. Одно дело обещать, что конкретная виртуальная машина будет доступной по сети, другое дело обещать, что точно получится отмасштабироваться еще на несколько узлов.
Можно вместо этого предположить, что пользователи не рассматривают сервис управления как важный сервис и вполне довольны нынешними формулировками SLA на «основные» сервисы.
Как вариант, можно предположить и то, и другое одновременно (и можно без хлеба).
В любом случае поставщикам облачных услуг еще есть куда развивать свои сервисы, а пользователям стоит внимательнее относиться к зависимостям их собственных сервисов. Иначе от внушительного числа девяток после запятой никакого толку.
Дмитрий Мещеряков,
департамент продуктов для разработчиков
Автор: DmitryMe
