Возврат денег за сбой облачного сервиса: инструкция по взысканию компенсации за нарушение SLA
Каждый, кто развернул хотя бы один продакшен на облаке, знает это ощущение: открываете мониторинг в понедельник утром, а там — дыра в графиках, алерты о недоступности инстансов и десятки пропущенных обращений в поддержку.
Аврора Шинкарева·Обновлено: 14 июля 2026 г.·9 мин
Возврат денег за сбой облачного сервиса: инструкция по взысканию компенсации за нарушение SLA
Сервис лежал три часа, клиенты ушли к конкурентам, а вы считаете убытки в уме. И первое, что приходит в голову: «Провайдер мне должен». Технически — да, должен. Но то, как именно он рассчитывается за простой, для большинства команд оказывается неприятным сюрпризом. Никто не переведёт вам деньги на расчётный счёт и не компенсирует потерянных клиентов. Вместо этого вы получите скидку на будущие счета того же провайдера — и только если успеете правильно оформить претензию в отведённое окно.
Разберёмся, как устроена эта механика, что реально можно взыскать и на что рассчитывать не стоит.
Почему облачные провайдеры не возвращают деньги на карту
Первое, что нужно усвоить: компенсация за нарушение SLA — это не возврат средств в классическом смысле. Когда вы читаете в документации провайдера фразу «компенсация предоставляется в виде сервисных кредитов», это означает ровно то, что написано. Вы не получите перевод на расчётный счёт, не увидите возврат на карту и не добьётесь зачисления реальных денег — за исключением крайне редких судебных кейсов, которые выходят далеко за рамки стандартной процедуры.
Сервисные кредиты — это внутренняя валюта провайдера. Баллы или скидки, которые применяются к вашему следующему счёту за использование облачных ресурсов. Получили 10% кредитов за простой в январе — в феврале счёт за инстансы и хранилища уменьшится на эту сумму. Не больше, не меньше. И только за услуги того же провайдера.
Почему так? Модель «кредитов вместо денег» — отраслевой стандарт, который защищает провайдера дважды. Во-первых, он удерживает клиента: раз вы уже получили скидку на следующий месяц, логично продолжить пользоваться тем же облаком. Во-вторых, он ограничивает финансовую ответственность провайдера жёсткими рамками — об этом поговорим отдельно.
На российском рынке условия устроены идентично западному. Yandex Cloud, Selectel, VK Cloud — все крупные провайдеры работают по единой логике: выявление нарушения порога доступности, самостоятельная подача заявки клиентом, начисление сервисных кредитов на будущие периоды. Различаются цифры и сроки, но принцип — один.
Сервисные кредиты — это не «возврат денег», а скидка на следующий счёт. Провайдер компенсирует вам потерянное время ресурсом, а не рублями.
Математика доступности: как считается допустимый простой
Чтобы понять, полагается ли вам компенсация, нужно разобраться с цифрами, которые провайдер декларирует в SLA. И здесь кроется первая ловушка: на слуху у всех «девять девяток», но что конкретно стоит за каждым девятым знаком — мало кто считал.
Стандартный порог доступности для большинства коммерческих облачных сервисов — 99,9%. На практике это означает, что провайдер гарантирует работу ресурса в течение месяца с допустимым простоем примерно в 43 минуты. Всё, что укладывается в этот лимит, формально не является нарушением SLA. Если ваш инстанс был недоступен 40 минут — претензию подать нельзя: провайдер остался в рамках обязательств.
| Уровень доступности | Допустимый простой в месяц | Типичный сценарий |
|---|---|---|
| 99,9% (три девятки) | ≈ 43 минуты | Стандарт для большинства IaaS/PaaS-сервисов |
| 99,95% | ≈ 22 минуты | Повышенный тариф для критичных workload |
| 99,99% (четыре девятки) | ≈ 4 минуты | Premium-уровень, часто — отдельный контракт |
Разберём конкретный пример. Допустим, вы арендуете виртуальные машины в Yandex Cloud по стандартному SLA в 99,9%. В феврале (28 дней, 40 320 минут) произошёл сбой: ваши инстансы были недоступны 2 часа. Допустимый простой — 40,3 минуты. Фактический — 120 минут. Нарушение составляет 79,7 минут сверх лимита.
Именно от этой «переборки» зависит размер компенсации. Но — и это важно — не от ваших убытков, не от количества потерянных заказов и не от суммы, которую вы платите за весь стек услуг. Только от стоимости конкретного пострадавшего ресурса за этот конкретный месяц.
Условия начисления кредитов обычно выглядят ступенчато. Взять тот же Yandex Cloud: если доступность опустилась ниже 99,9%, но осталась выше 99,0% — вам полагается 10% от стоимости пострадавшей услуги. Если ниже 99,0% — 25%. У других провайдеров пороги могут отличаться, но логика та же: чем дольше лежал сервис, тем больше процент компенсации. И у всех — потолок в 100% ежемесячной платы за конкретный ресурс, сверх которого ничего не начисляется.
Алгоритм подачи претензии: почему автоматизация не работает в вашу пользу
Одно из самых опасных заблуждений об облачных SLA — идея о том, что компенсация начисляется автоматически. Это не так. Практически ни один крупный провайдер не запускает процесс возврата сервисных кредитов без явного запроса клиента. Вы можете годами пользоваться облаком, переживать простои и никогда не получить ни копейки компенсации — просто потому, что не знали, что нужно спрашивать.
Вот как устроен стандартный алгоритм:
1. Мониторинг и фиксация. Вы или ваша команда DevOps/SRE должны самостоятельно обнаружить и зафиксировать время простоя. Провайдер публикует статус-пейдж и отчёты об инцидентах, но доказательное бремя лежит на вас — нужны логи, метрики, таймстемпы.
2. Проверка порога SLA. Посчитайте, попал ли фактический простой в зону нарушения. Помните про «допустимые» 43 минуты: если сбой уложился в лимит, претензия не имеет смысла.
3. Подача заявки в поддержку. Создайте тикет в техническую поддержку провайдера, указав период простоя, затронутые ресурсы и расчёт нарушения. Каждый провайдер имеет регламентированную форму или канал для таких обращений — не отправляйте запрос в общий чат.
4. Соблюдение дедлайна. Здесь кроется вторая ловушка. Срок подачи претензии строго ограничен — обычно от 10 до 30 дней после окончания месяца, в котором произошёл нарушение. Пропустили окно — потеряли право на компенсацию, даже если инцидент был задокументирован идеально.
5. Рассмотрение и начисление. Провайдер проверяет вашу заявку, сверяет данные с собственными логами инфраструктуры и выносит решение. Сроки рассмотрения варьируются, но обычно укладываются в 30 дней.
Пропустили окно подачи претензии — потеряли право на компенсацию. Никакой автоматики: провайдер ждёт, что вы придёте с запросом сами.
Почему провайдеры не автоматизируют начисление? Причина прозаична: если бы компенсации отрабатывались без запроса, это превратилось бы в значительную статью расходов. Значительная часть клиентов просто не знает о своих правах по SLA или не считает нужным тратить время на оформление тикета ради 10% скидки на следующий счёт. В бизнес-модели провайдера это не баг, а фича.
Для вашей команды это означает необходимость выстроить внутренний процесс. Назначьте ответственного за мониторинг SLA-нарушений. Заведите шаблон претензии. Настройте автоматическое отслеживание инцидентов и расчёт допустимого простоя. Без этого механизма даже очевидное нарушение останется без компенсации.
Границы ответственности: что SLA не покрывает
SLA — документ с жёсткими рамками, и понимание того, что в эти рамки не входит, критически важно для формирования реалистичных ожиданий.
Плановые технические работы. Если провайдер предупредил о регламентных работах заранее (обычно за 3–5 рабочих дней), простой во время этих работ не считается нарушением SLA, даже если ваш сервис был недоступен. Проверяйте каналы уведомлений провайдера — статусные страницы, рассылки, RSS-ленты.
Действия клиента. Если сервис стал недоступен из-за вашей конфигурации, некорректного деплоя, исчерпания лимитов или DDoS-атаки на вашу инфраструктуру — SLA не срабатывает. Провайдер отвечает за свою платформу, а не за ваш код.
Форс-мажор. Стихийные бедствия, военные действия, массовые кибератаки на инфраструктуру провайдера — всё это выводится за рамки SLA.
Косвенные убытки. И это, пожалуй, самое болезненное ограничение. Максимальная компенсация по стандартному SLA — 100% ежемесячной платы за конкретный пострадавший ресурс. Если вы платите за инстансы 50 000 рублей в месяц, а из-за трёхчасового простоя потеряли контракт на миллион — провайдер компенсирует максимум 50 000 рублей в виде сервисных кредитов. Упущенную выручку, штрафы от ваших клиентов, репутационный ущерб — всё это лежит на вас.
Именно поэтому зрелые компании используют два подхода к управлению рисками:
- Мульти-клауд и резервирование. Критичные сервисы дублируются между двумя провайдерами, чтобы сбой одного не означал остановку бизнеса. Дороже, но убытки от простоя обычно окупают затраты на инфраструктуру.
- Бизнес-страхование перерывов в работе. Страховка от киберинцидентов и сбоев облачных сервисов покрывает те самые косвенные убытки, которые SLA игнорирует. Рынок таких полисов в России только формируется, но крупные компании уже используют эту опцию.
Разбор кейсов: от 10% до 100% компенсации
Посмотрим, как ступенчатая модель начисления сервисных кредитов работает на практических примерах. Возьмём три сценария с одним и тем же тарифом — виртуальные машины стоимостью 100 000 рублей в месяц в облаке с SLA 99,9%.
Сценарий 1: Минимальное нарушение. Доступность за месяц — 99,85%. Фактический простой — около 65 минут. Допустимый лимит — 43 минуты. Переборка — 22 минуты. Доступность осталась выше 99,0%, значит, компенсация — 10% от стоимости ресурса. На следующем счёте вы увидите скидку в 10 000 рублей сервисными кредитами.
Сценарий 2: Серьёзный инцидент. Доступность — 98,5%. Простой — около 645 минут (почти 11 часов). Лимит превышен значительно, доступность опустилась ниже 99,0%. Компенсация — 25%. Сервисные кредиты на сумму 25 000 рублей.
Сценарий 3: Катастрофический сбой. Доступность — 95,0%. Простой — более 2 000 минут, сервис фактически не работал больше суток. Провайдер начисляет максимальный уровень компенсации — 100% от стоимости ресурса. 100 000 рублей в сервисных кредитах. При этом ваши реальные потери, если речь о продакшене, могут быть на порядки больше.
| Сценарий | Доступность | Простой | Компенсация | Кредиты (при тарифе 100 000 ₽/мес) |
|---|---|---|---|---|
| Минимальное нарушение | 99,85% | ~65 мин | 10% | 10 000 ₽ |
| Серьёзный инцидент | 98,5% | ~645 мин | 25% | 25 000 ₽ |
| Катастрофический сбой | 95,0% | ~2 160 мин | 100% | 100 000 ₽ |
Три наблюдения из этих сценариев.
Первое: разрыв между масштабом проблемы и размером компенсации очевиден. Одиннадцать часов простоя — это катастрофа для любого онлайн-бизнеса, а компенсация покрывает лишь четверть месячного счёта за сервис.
Второе: даже 100% возврат — это возврат ресурсом, а не деньгами. Провайдер просто не выставит вам счёт за следующий месяц. Вы продолжаете зависеть от того же облака, и сервисные кредиты привязывают вас к нему ещё на один период.
Третье: во всех трёх случаях для получения компенсации вам нужно самостоятельно обнаружить нарушение, рассчитать переборку, собрать доказательную базу и отправить претензию в отведённое окно. Ни одна из этих ступеней не сработает, если в команде нет процесса отслеживания SLA.
Практический чеклист: как выстроить работу с SLA-претензиями
Компании, которые системно относятся к компенсациям за сбои, обычно делают четыре вещи.
Настройка алертов на доступность. Мониторинговые инструменты (Zabbix, Prometheus, сервисы вроде UptimeRobot) должны не только сообщать о даунтаймах в реальном времени, но и накапливать статистику за месяц для расчёта аптайма.
Шаблон претензии. Подготовьте стандартный текст обращения в поддержку провайдера с полями для даты, времени простоя, затронутых ресурсов и ссылок на ваши логи. Это экономит часы работы, когда инцидент уже произошёл и команда занята восстановлением.
Календарь дедлайнов. Для каждого провайдера, услугами которого вы пользуетесь, зафиксируйте срок подачи претензии (обычно 10–30 дней после окончания месяца). Поставьте напоминание на 5-е число каждого месяца — проверять, не было ли нарушений в предыдущем.
Фиксация потерь отдельно от SLA. Даже если компенсация по договору ограничена сервисными кредитами, документируйте реальные убытки от каждого простоя. Эта информация пригодится для переговоров об индивидуальных условиях Enterprise-контрактов, для страхования рисков и для принятия решения о смене провайдера.
Что в итоге
SLA облачного провайдера — это не страховка от простоя и не механизм полного возмещения ущерба. Это ограниченный инструмент, который компенсирует часть стоимости услуги при нарушении оговорённого уровня доступности — и только в виде кредитов на будущие счета.
Для небольших проектов, где простой в 40 минут не критичен, стандартных условий SLA обычно достаточно: они мотивируют провайдера поддерживать инфраструктуру, а в редких случаях сбоя вы получаете скромную, но справедливую скидку.
Для бизнеса, где каждая минута простоя конвертируется в реальные потери, SLA — лишь отправная точка. Нужна мульти-клауд-архитектура, собственный мониторинг, выстроенный процесс подачи претензий и, возможно, страховой полис. Компенсация от провайдера в виде 10% сервисных кредитов не закроет убытки от трёхчасового простоя вашего маркетплейса, но правильно оформленная претензия — минимум, который должна делать каждая команда, работающая с облаком. Не ради денег, ради дисциплины.