Почему мы встроили правила компенсации в продукт, а не спрятали их в скриптах поддержки

Статус запуска (обновлено 2026-07-09): в статье описана полная архитектура системы компенсаций. Правила и алгоритм применяются как описано; сейчас компенсация оформляется по заявке — обратитесь в поддержку, расчёт по опубликованному алгоритму выполняется вручную, затем сумма зачисляется на баланс (как подать заявку). Автоматический мониторинг уже работает; автоматические расчёт, зачисление и ежемесячные письма внедряются поэтапно — до этого описания полностью автоматического зачисления и ежемесячных писем относятся к целевому состоянию.

Как обычно выглядит SLA

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

• Обязательство по доступности (обычно 99,9% / 99,95%)
• Таблица соответствия времени простоя проценту компенсации (5%–50% месячной платы)
• Пункт «пользователь должен сам подать претензию с доказательствами»
• Пункт «форс-мажор исключается»

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

Причина проста: стоимость процесса претензии превышает возможную компенсацию. Войти, открыть тикет, загрузить скриншоты, ждать 7 рабочих дней проверки и в итоге получить, может, ваучер на 15% месячной платы — с учётом времени это убыток.

Что сделали мы

Мы превратили компенсацию из «документа, в который лезешь, когда что-то сломалось» в автоматическую логику внутри продукта — правила, расчёт и зачисление не требуют от вас никаких действий.

1. Календарный месяц + группа SKU + три уровня компенсации

После закрытия каждого календарного месяца (UTC+8) мы считаем компенсацию независимо по каждой группе SKU за месяц (Claude / Claude Code / GPT / Gemini / Qwen / группа китайских моделей со скидкой 50% / Doubao) по доступности:

• ≥ 99% — без компенсации
• 98% – 99% — 2% от суммы заказов по этому SKU за месяц
• 95% – 98% — 5%
• < 95% — 10% (месячный потолок тоже 10%)

Независимый расчёт уровней означает: если в этом месяце Claude 96% / GPT 99,5% / Gemini 100%, компенсируется только часть по Claude по 5%; остальные SKU не трогаются. Почему не непрерывная формула и не более дробные промежуточные уровни? Потому что и клиенты, и BD должны уметь посчитать в уме. Каждый раз объяснять клиенту «ваши 96,3% дают 5 п.п. + 0,3 × X» — пустая трата времени. Три ступенчатых перехода ещё и усиливают целевую линию «держать 95%» — oncall сам знает, что это нижняя граница.

2. Автоматический расчёт в конце месяца — вам не нужно замечать проблему

После месячного расчёта в 9:00 3-го числа следующего месяца все затронутые клиенты получают письмо: месячная доступность по каждой группе SKU, сумма компенсации, детали расчёта. Сумма сначала попадает на резервный счёт — вы видите её в письме и в дашборде, но пока не можете использовать. В течение 7-дневного окна апелляций (3–10 число следующего месяца) вы или мы можем оспорить расчёт; когда окно закрывается без удовлетворённой апелляции, сумма автоматически становится доступным балансом. По истечении окна — принято по умолчанию. Любая отдельная компенсация ≥ ¥5 000 сначала замораживается на 24 часа для проверки операционной командой (защита от переплаты из-за бага дашборда), и после проверки попадает на резервный счёт.

Слишком малые выборки не запускают компенсацию: меньше 100 вызовов в месяц по одному SKU, или меньше 1 000 общеплатформенных выборок по SKU в месяц — компенсация в этом месяце не запускается: «94%», посчитанные на 50 вызовах, слишком шумны как основание. Покрытие SLA не меняется, просто в этом случае нет вычислимой выплаты.

3. В числитель попадают только жёсткие ошибки, за которые отвечаем мы, — и здесь есть напряжение

В числитель «недоступности» попадают только три класса запросов:

• Сервер вышестоящего вернул 5xx (500/502/503/504)
• Вышестоящий не вернул первый байт за 60 секунд (таймаут)
• 5xx нашего шлюза (крах слоя маршрутизации / биллинга)

Активное ограничение скорости, 401 / 429 вышестоящего, клиентские 4xx и исчерпание баланса не учитываются. Это спорный выбор, и мы обязаны проговорить напряжение:

Клиент может столкнуться с «явно не работает, а число SLA всё равно 99%» — например, ваш один ключ сработал по лимиту QPS (мы возвращаем 429, прося повторить), или у вышестоящего истёк токен аккаунта и мы переключаемся. Вы ощущаете «нестабильность сервиса», но число SLA не двигается.

Мы выбрали это определение не ради числа, а потому что только жёсткие ошибки нашего шлюза + сервера вышестоящего — это то, за что семантика SLA может отвечать. Ограничение скорости — продуктовая политика (описана в документации по интеграции); клиентские 4xx — ошибки слоя запроса; впихнуть это в доступность значило бы сделать SLA числом, которое и мы не сможем истолковать. Для проблем с ограничением / 401 / 429, которые действительно мешают вашему коду, наша стратегия — oncall активно смотрит алерты + переключение канала за 30 секунд, а не ждать вашего тикета.

4. Вычет окна обслуживания ограничен и не может использоваться для приукрашивания числа

Плановое обслуживание можно вычесть из знаменателя, но только при одновременном выполнении трёх условий: уведомление ≥ 7 дней + ≤ 4ч за раз + ≤ 8ч суммарно в месяц. Всё сверх 8ч возвращается в знаменатель как сбой; обслуживание по инициативе вышестоящего (даже с предварительным уведомлением) не вычитается — это его проблема, а не наша. Это правило намеренно написано жёстко, чтобы операционная команда не превращала окна обслуживания в украшатель SLA.

Чего это стоит нам

• Финансовое прогнозирование пришлось перемоделировать — компенсация теперь реальная статья расходов, а не «обещание, которое не исполнят». Мы построили норму резерва под компенсации по историческим данным о сбоях — около 0,4% выручки.
• Поднялась планка точности мониторинга — ошибётесь в оценке сбоя — и раздаёте пользователям деньги. Наш алгоритм определения сбоев прошёл код-ревью в две пары глаз и месяц shadow-режима до запуска.
• Нарратив о сбоях не подкрутить — раньше можно было сказать «единичные колебания»; теперь в счёте чёрным по белому стоит сумма компенсации, и любая нечестность бьёт по тебе же.

Почему пишем это сейчас

Недавно общаясь с несколькими командами, мы обнаружили, что ожидания от SLA API-сервисов уже очень низкие — «написано, но всё равно бесполезно». Мы хотим сказать: SLA не обязан быть юридическим текстом; он может быть самим продуктом. Это не мы умны — просто планка индустрии слишком низка.

Если эта статья заставит вас подумать «о, так тоже можно», этого достаточно.