Компенсация по SLA против реальных убытков: почему это несравнимые суммы

MAATRIX

Если вы дочитали до этой статьи серию про SLA и простои, у вас, скорее всего, уже сложилась картина: проценты доступности в договоре считаются криво в пользу провайдера, компенсация приходит не деньгами, а скидкой на будущее, а сам процесс её получения требует тикетов, логов и терпения. Осталось закрыть последний и, пожалуй, самый важный вопрос: даже если вы получите компенсацию по SLA честно и без проволочек — покроет ли она то, что вы реально потеряли во время простоя? Короткий ответ — почти никогда. И дело не в жадности конкретного провайдера, а в том, что это структурно разные по природе величины, которые нельзя сравнивать напрямую.

Что вообще такое компенсация по SLA

SLA (Service Level Agreement) — это обязательство провайдера инфраструктуры поддерживать определённый уровень доступности сервиса, обычно выраженный в процентах за расчётный период (месяц или год). Если уровень не достигнут, провайдер платит компенсацию — но не деньгами на счёт, а почти всегда скидкой на следующий период обслуживания, пропорциональной времени простоя относительно гарантированного уровня.

Механика примерно такая (у каждого провайдера свои конкретные проценты и пороги, здесь — только логика расчёта, без выдуманных цифр):

1. Берётся длительность простоя за расчётный период.
2. Сравнивается с допустимым простоем при заявленном уровне SLA.
3. Превышение переводится в проценты от стоимости аренды за этот период.
4. Клиент получает скидку на будущий счёт (иногда — кредит на баланс), причём часто с потолком по сумме и обязательным заявлением в определённый срок.

Ключевое здесь — «от стоимости аренды за этот период». Это база расчёта. Не выручка клиента, не его убытки, не что-либо, связанное с бизнесом клиента вообще — именно то, что клиент платит провайдеру за инфраструктуру. Мы подробно разбирали, как читать проценты доступности в конкретном договоре, в статье про SLA в договоре и что реально означают эти проценты — там же показано, почему заявленные 99,9% и реальный допустимый простой часто не совпадают с интуитивным ожиданием.

Реальный ущерб бизнеса — величина другого порядка

В предыдущих статьях серии мы разбирали, из чего складывается реальная стоимость минуты простоя: упущенная выручка от заказов, которые не оформились, отток клиентов, которые ушли к конкурентам и не вернулись, репутационные потери, которые бьют по будущим продажам, а иногда и штрафы по собственным SLA-обязательствам клиента перед его клиентами.

Эта величина считается от совсем другой базы — от оборота и экономики самого бизнеса клиента. У интернет-магазина с оборотом в несколько миллионов рублей в месяц час простоя в пиковый день может стоить заметную долю дневной выручки. У SaaS-сервиса с B2B-клиентами простой на несколько часов — это не только прямые потери, но и удар по доверию, который может стоить контракта на годы вперёд. У сервиса бронирования — это упущенные заказы, которые клиенты сделали у конкурента и, возможно, больше не вернутся.

Ничего из этого не имеет отношения к тому, сколько бизнес платит за аренду сервера. Это независимые друг от друга величины: одна — расход клиента на инфраструктуру, другая — экономика всего его бизнеса. Методику подсчёта стоимости минуты простоя для конкретного магазина мы разбирали отдельно в статье сколько стоит минута простоя магазина — там видно, насколько быстро эта сумма выходит за рамки любой разумной компенсации по аренде.

Почему провайдер физически не может обещать больше

Если довести мысль до конца, становится понятно, почему ни один инфраструктурный провайдер в здравом уме не станет предлагать компенсацию, привязанную к обороту клиента, а не к стоимости аренды.

Провайдер обслуживает одновременно множество клиентов с совершенно разной экономикой на одной и той же инфраструктуре — от блога на минимальном VPS до интернет-магазина с оборотом в десятки миллионов. Если бы компенсация считалась от выручки клиента, у провайдера не было бы способа заранее оценить свои потенциальные обязательства: клиент с крупным бизнесом на дешёвом тарифе создавал бы для провайдера риск, несопоставимый с суммой, которую он платит за аренду. Такая модель просто не выдержала бы никакого разумного ценообразования — либо аренда стала бы неподъёмно дорогой для всех, чтобы покрыть теоретические риски немногих, либо провайдер обанкротился бы на первой крупной претензии.

Именно поэтому компенсация по SLA — это инструмент, соразмерный тому, чем провайдер реально управляет: качеством и стабильностью своей инфраструктуры. А не тому, чем он не управляет и не может управлять, — экономикой бизнеса клиента, построенного поверх этой инфраструктуры.

Практический вывод: SLA — не страховка от бизнес-рисков

Из всего разобранного следует конкретный практический вывод, который стоит держать в голове при работе с любым провайдером инфраструктуры: SLA — это ориентир качества обслуживания, а не инструмент финансового страхования бизнес-рисков.

SLA полезен и важен — как сигнал о том, насколько провайдер уверен в своей инфраструктуре, как рычаг давления при систематических проблемах, как пункт договора, который можно использовать, если что-то пошло не так на стороне провайдера. Но он никогда не был спроектирован как замена страховке или резервированию, и относиться к нему как к финансовой защите бизнеса — ошибка, которая обнаруживается в самый неподходящий момент, когда простой уже случился, а компенсация оказывается несопоставимой с реальными потерями.

Если для бизнеса простой инфраструктуры — это ощутимый риск, для защиты от него нужны отдельные, специально предназначенные для этого меры:

• Техническое резервирование — резервный сервер в горячем или холодном режиме, автоматическое переключение при отказе, резервирование на уровне разных локаций и, в идеале, разных провайдеров. Разница между горячим и холодным режимом резервного сервера и как выбрать подходящий для своего бюджета разобрана в статье резервный сервер: горячий или холодный режим. Это снижает саму вероятность и длительность простоя, а не компенсирует его постфактум.
• Мониторинг и быстрое реагирование — раннее обнаружение проблем часто сокращает простой с часов до минут, а это снижает ущерб эффективнее, чем любая компенсация.
• Страхование бизнес-рисков — отдельный финансовый продукт (страхование киберрисков, страхование от перерыва в деятельности), который явно и осознанно принимает на себя риск, связанный с оборотом бизнеса, а не с фиксированной суммой аренды. Мы отдельно писали о том, как устроено страхование киберрисков для малого бизнеса — это принципиально другой договор с другим андеррайтингом, и именно он способен покрыть суммы, сопоставимые с реальным ущербом.
• Архитектурная отказоустойчивость — распределение нагрузки, отсутствие единой точки отказа, грамотное разделение критичных и некритичных компонентов системы.

SLA в этой картине — один из элементов, причём далеко не главный по способности защитить бизнес деньгами. Его роль — задавать ожидания по качеству и давать формальный механизм давления на провайдера, а не покрывать финансовые последствия простоя.

Как честно оценить свой риск

Прежде чем полагаться на SLA как на защиту, стоит трезво посчитать для своего проекта две вещи отдельно, не путая их друг с другом.

Первое — сколько реально стоит час или день простоя именно для вашего бизнеса: в упущенной выручке, в оттоке клиентов, в репутационных издержках, в возможных штрафах перед вашими собственными клиентами. Это число может сильно отличаться в будни и выходные, в пиковый сезон и в межсезонье, — и его стоит знать хотя бы приблизительно, а не гадать в момент, когда сервер уже недоступен.

Второе — сколько по факту способна вернуть SLA-компенсация в худшем реалистичном сценарии простоя. Это несложно прикинуть: возьмите стоимость аренды за период и умножьте на максимальный процент компенсации из вашего договора. Это и есть потолок того, что вернёт провайдер, — независимо от того, насколько серьёзным был простой для вашего бизнеса.

Разница между этими двумя числами — это и есть незакрытый риск, который лежит на бизнесе, а не на провайдере. Если разница велика, разумный шаг — не требовать от провайдера невозможного (переписать SLA под покрытие бизнес-ущерба ему всё равно экономически не позволят), а закрыть эту разницу собственными мерами: резервированием, страховкой, архитектурными решениями. Это дешевле и надёжнее, чем годами спорить с провайдером о справедливости процентов.

Частые вопросы