Почему uptime модели не равен надёжности ИИ-функции
Запрос может получить HTTP 200, но ответ окажется пустым, не по схеме, без нужной цитаты или с неверным tool action. С точки зрения инфраструктуры всё доступно; с точки зрения пользователя задача провалена.
SLO должен охватывать путь от намерения пользователя до принятого результата. Доступность провайдера остаётся важным dependency SLI, но не заменяет end-to-end показатель продукта.
SLI, SLO, SLA и error budget
SLI — измеренный показатель, например доля ответов быстрее 8 секунд. SLO — целевой уровень за окно: 99% eligible задач укладываются в 8 секунд за 28 дней. SLA — договорное обязательство с последствиями. Error budget — допустимая доля плохих событий, равная 1 − SLO.
Не превращайте внутренний SLO в маркетинговое обещание автоматически: измерение, исключения и ответственность у SLA могут отличаться.
Определите единицу пользовательского события
Для чата событием может быть завершённый turn, для агента — workflow, для извлечения — документ, для поддержки — обращение. Выбор request как знаменателя искажает картину, если один пользовательский результат требует пяти retries.
Запишите границы: когда событие начинается, чем заканчивается, какой ID устраняет дубли и что считается eligible. Отменённые пользователем запросы, тестовый трафик и злоупотребления должны иметь явную политику включения.
Хороший SLI имеет форму good / total
Google SRE рекомендует выражать многие индикаторы как отношение хороших событий ко всем допустимым. Для агента good workflow может одновременно означать: терминальный статус success, валидный output, отсутствие критического нарушения и latency ниже порога.
Храните числитель и знаменатель как counters, а не только готовый процент. Тогда агрегация по окнам и сегментам остаётся проверяемой.
Task success SLO
Главный вопрос — получил ли пользователь нужный результат. Автоматический label можно вывести из принятия результата, отсутствия повторного обращения, валидатора или подтверждённого business event. Для сложных ответов нужна выборочная разметка и delayed feedback.
Документируйте proxy bias: отсутствие жалобы не всегда означает успех, а ручная оценка может приходить через неделю. Публикуйте coverage — долю событий, для которых label вообще известен.
Quality SLO для недетерминированного ответа
Не превращайте средний score LLM-judge в единственный SLI. Используйте проверяемые критерии: schema validity, evidence coverage, citation correctness, обязательные факты и отсутствие критических ошибок. Judge полезен как один сигнал с зафиксированной версией и калибровкой.
Порог задавайте на уровне события: good, если пройдены обязательные проверки. Среднее 0,91 может скрывать небольшую группу катастрофических ответов.
Latency: TTFT, completion и workflow duration
Для streaming пользователь ощущает time to first token, но результат получает только после terminal event. Измеряйте оба показателя. Для агента добавьте длительность до approval, tool time и полный workflow age.
Latency SLI задаётся как доля событий ниже порога, а не среднее. Histogram позволяет рассчитывать распределение и агрегировать несколько instances; границы buckets выбирайте вокруг продуктовых порогов.
Freshness и completeness для RAG
RAG может отвечать быстро и грамотно по устаревшему индексу. Freshness SLI измеряет долю запросов, обслуженных corpus version не старше допустимого возраста, или задержку от изменения источника до searchable state.
Completeness отвечает, были ли проиндексированы все ожидаемые документы и ACL. Эти показатели лучше считать в ingestion pipeline и присоединять к trace ответа через version ID.
Стоимость как guardrail SLO
Цена одного API-вызова недостаточна: считайте tokens, tools, retries, fallback и ручную проверку на успешный результат. Полезный показатель — доля successful tasks дешевле установленного бюджета.
Cost guardrail не должен заставлять систему выдавать дешёвый неправильный ответ. Сначала действует quality floor, затем оптимизируется cost per accepted outcome.
Безопасность не покупается error budget
Обычная доступность допускает небольшое число ошибок. Утечку между tenants, необратимое действие без approval или раскрытие секрета нельзя легализовать формулой «99,9% безопасно». Для таких событий задайте hard limit и немедленную incident policy.
Error budget подходит для допустимых сбоев сервиса; критические safety invariants остаются release blockers независимо от общего результата.
Сегменты: среднее скрывает пострадавших
Разрезайте SLI по языку, tenant tier, типу задачи, model route, версии prompt, длине контекста и риску действия. Но не превращайте каждый user ID в metric label: OpenTelemetry предупреждает, что высокая cardinality увеличивает память на каждую уникальную комбинацию.
Низкокардинальные dimensions храните в metrics, детальный анализ — в traces или аналитическом хранилище. Для критичных когорт можно определить отдельные SLO.
Окно и error budget
Rolling 28 или 30 дней хорошо отражает текущее состояние; calendar month удобен для отчётности, но обнуляет историю на границе месяца. Для 99% SLO бюджет составляет 1% eligible событий. Один миллион задач даёт 10 000 допустимых bad events.
Не задавайте 99,99% по привычке. Цель должна отражать порог пользовательской ценности и быть достижимой без постоянного героизма команды.
Burn rate и раннее предупреждение
Burn rate показывает, во сколько раз текущая скорость ошибок превышает допустимую. Значение 1 означает расход бюджета ровно по плану, 10 — в десять раз быстрее. Сочетайте короткое и длинное окно: короткое быстро замечает аварию, длинное фильтрует шум.
Alert должен вести к действию: rollback версии, отключение capability, переключение fallback или остановка rollout. График без runbook не защищает SLO.
Политика error budget
До инцидента согласуйте действия. Например: при расходе 50% бюджета остановить расширение canary; при 80% разрешить только low-risk изменения; при исчерпании — freeze и приоритет reliability work. Critical safety event вызывает rollback независимо от бюджета.
Google SRE подчёркивает: без утверждённой политики error budget остаётся ещё одним KPI. Укажите владельца, исключения, путь эскалации и дату пересмотра.
SLO зависимости и end-to-end SLO
Провайдер модели, vector DB и CRM имеют собственные SLA, но пользователь видит композицию. Не складывайте проценты механически: retries, fallback и деградация меняют вероятность успешного результата.
Измеряйте end-to-end SLI на своей границе, а dependency metrics используйте для диагностики и планирования. Ошибка поставщика всё равно расходует пользовательский бюджет, даже если команда не виновата.
Как начать за две недели
- Выбрать один критичный workflow и owner.
- Определить eligible event и stable ID.
- Записать task success и latency thresholds.
- Добавить hard safety limits.
- Инструментировать good/total counters и histogram.
- Снять baseline без обещаний.
- Согласовать начальную цель и error budget policy.
- Настроить burn-rate alerts и runbook.
- Проверить rollback drill.
- Пересмотреть SLO через месяц.
Чек-лист SLO для ИИ-сервиса
- Определён пользовательский outcome, а не только HTTP request.
- Числитель, знаменатель и exclusions документированы.
- Есть task success, latency и quality SLI.
- Freshness добавлен для зависимых от данных функций.
- Cost считается на принятый результат.
- Критические safety events вынесены в hard limits.
- Метрики доступны по важным сегментам без высокой cardinality.
- Выбрано окно и рассчитан error budget.
- Burn-rate alerts связаны с runbook.
- Политика реально влияет на релизы.