SLA публичного облака: что в нём написано и что в нём не написано
Разбор того, где заканчивается ответственность поставщика и где начинается ответственность заказчика - и почему это важно до инцидента, а не после.
Когда компания принимает решение перейти на публичное облако, один из главных аргументов звучит так: "Там гарантированный SLA, нам не нужно беспокоиться о надёжности". Это не совсем неправда. Но это далеко не вся правда. Решение о переходе в облако стоит принимать с правильной системой координат - собственный ЦОД, хостинг или облако - это первый выбор, а граница между виртуализацией и облаком часто остаётся размытой.
Я видел несколько ситуаций, когда после серьёзного инцидента компания обнаруживала, что поставщик всё сделал по договору - а бизнес всё равно лежал несколько часов. Проблема была не в поставщике. Проблема была в том, что никто не читал SLA внимательно.
Что поставщик действительно гарантирует
Типичный SLA публичного облака гарантирует доступность конкретного сервиса - виртуальной машины, хранилища, балансировщика. Обычно это 99,9% или 99,95% в месяц. Это примерно 45 минут или 22 минуты допустимого простоя в месяц соответственно.
Важные детали, которые там тоже написаны, но реже читаются:
- гарантия распространяется на один сервис, а не на всё приложение целиком;
- компенсация при нарушении SLA - это кредит на будущие счета, а не возмещение ущерба;
- плановые работы часто выведены за рамки SLA или считаются по отдельным условиям;
- SLA начинает действовать только если инцидент подтверждён поставщиком через его процедуры.
Что поставщик не гарантирует
Это важнее. Поставщик не гарантирует:
- доступность вашего приложения - только инфраструктуры под ним;
- корректность конфигурации, которую сделала ваша команда;
- сохранность данных, если резервное копирование не настроено или настроено неправильно;
- восстановление в нужные вам сроки, если у вас нет собственного плана DR;
- поведение в регионе, который вы выбрали, если сбой затронул именно его.
Граница ответственности проходит ровно там, где заканчивается контроль поставщика. Дальше - ваша зона.
Зона заказчика: где обычно возникают проблемы
На практике большинство инцидентов, которые ощущаются как "облако упало", происходят в зоне заказчика:
- одна зона доступности вместо двух, потому что "пока дороговато";
- отсутствие автоматического failover, потому что "разберёмся позже";
- резервные копии настроены, но не проверялись ни разу;
- зависимость от одного региона без fallback;
- конфигурация сети, которую понимает один человек в команде.
Ни одна из этих проблем не отражена в SLA поставщика - потому что они не его ответственность.
Как читать SLA правильно
Перед тем как подписывать контракт или выбирать архитектуру, я рекомендую ответить на несколько вопросов:
- Какой конкретный сервис покрывает этот SLA - и только ли он нужен для работы приложения?
- Как поставщик измеряет доступность - снаружи или изнутри?
- Что происходит с данными, если сервис недоступен дольше гарантированного окна?
- Как выглядит процедура получения компенсации и сколько она занимает?
- Есть ли у нас собственный SLA перед бизнесом - и совпадает ли он с тем, что гарантирует поставщик?
Последний вопрос самый неудобный. Если бизнес ожидает восстановление за 15 минут, а поставщик допускает 45 минут простоя в месяц по SLA - это не совпадает. Разницу нужно закрывать архитектурными решениями на своей стороне.
Практический вывод
SLA - это контракт о минимальных гарантиях, а не о надёжности вашего продукта. Надёжность продукта - это отдельная инженерная задача, которую облако упрощает, но не решает за вас.
Хороший способ проверить, насколько реалистично ваше понимание границ: разберите последний инцидент или смоделируйте гипотетический - и явно пройдитесь по каждому слою: что падает, кто чинит, в какое время. Там обычно и выясняется, где реально проходит граница.