Как проектировать SLA между агентом-менеджером и агентами-исполнителями?

Краткий тезис

SLA (Agreement) — это набор контрактов между агентом-менеджером (координатором) и агентами-исполнителями (специализированными микросервисами/моделями). Он фиксирует обязательства по времени ответа (latency), доступности (availability), качеству ответов (faithfulness) и частоте запросов (rate limits). Проектирование SLA включает выбор измеримых метрик (SLI), целевых порогов (SLO), механизмов мониторинга (Prometheus, health checks) и действий при нарушениях (breaker|circuit breaker, fallback, алерты). Правильный SLA балансирует между отказоустойчивостью системы и стоимостью ресурсов.

1. Термины: агент-менеджер и агент-исполнитель

• Агент-менеджер (Manager Agent) — центральный координатор, который принимает пользовательский запрос, планирует цепочку действий, распределяет подзадачи между исполнителями и собирает результат.
• Агент-исполнитель (Worker Agent) — легковесный агент, специализирующийся на одной функции: поиск (retrieval), вызов внешнего API, генерация текста, валидация фактов и т. д.

Взаимодействие между ними — это вызов по RPC/gRPC/HTTP. SLA регулирует этот вызов: что исполнитель обязан сделать и с каким качеством, а менеджер — как реагировать на сбои.

2. Зачем нужен SLA в агентной системе?

Без SLA:

• Исполнитель может отвечать бесконечно долго → весь пайплайн зависает.
• Качество ответа может быть низким → менеджер выдаёт пользователю галлюцинации.
• Перегрузка одного исполнителя убивает всю систему.

SLA даёт:

• Предсказуемость — знаем худшее время ответа.
• Возможность мониторинга — отслеживаем, когда SLO нарушается.
• Автоматическую реакцию — при нарушении включаем резервную стратегию.

3. Ключевые метрики SLA (SLI — Service Level Indicator)

Дополнительно можно учитывать:

• Error budget — допустимый процент нарушений в месяц.
• Concurrency — максимальное число одновременных вызовов.
• Freshness — как часто исполнитель обновляет свои кеши/модели.

4. Как задавать SLO и цели

SLO (Service Level Objective) — это целевое значение SLI, которое система обещает соблюдать.

Пример:

• SLI: latency (P99)
• SLO: 95% вызовов латентность < 500 ms

Советы по установке SLO

• Используйте исторические данные (если система уже работает) или baseline-тесты.
• Отталкивайтесь от пользовательских ожиданий: для чата latency P99 < 2 c, для батч-задач — минуты.
• Задавайте не один, а несколько SLO: жёсткие (must-have) и мягкие (nice-to-have).
• Включайте Error budget (например, 0.1% нарушений в месяц) — при его исчерпании система перестаёт принимать новый трафик или снижает качество (graceful degradation).

5. Мониторинг и health checks

Каждый исполнитель обязан предоставлять:

• Health check endpoint (например, /health), возвращающий 200 при работоспособности.
• Metrics endpoint (например, /metrics для Prometheus), где выставляются:
  • worker_request_duration_seconds (гистограмма)
  • worker_requests_total (счётчик, с метками status)
  • worker_uptime_seconds
  • worker_faithfulness_score (если есть компонент оценки)

Менеджер периодически опрашивает health check (каждые 10 с) и при падении исключает исполнителя из пула, запуская fallback.

Пример минимального health check на Flask:

from flask import Flask, jsonify
import time

app = Flask(__name__)
start_time = time.time()

@app.route('/health')
def health():
    return jsonify({"status": "ok", "uptime": time.time() - start_time}), 200

if __name__ == '__main__':
    app.run(port=5000)

6. Механизмы реакции на нарушение SLA

Когда менеджер обнаруживает, что исполнитель нарушил SLA (например, таймаут или низкий faithfulness), он:

1. Логирует и алертит — отправляет сигнал в PagerDuty / Telegram.
2. Исключает исполнителя из пула активных — перестаёт отправлять на него новые запросы.
3. Включает fallback:
   • Если исполнитель был RAG-ретвивером → временно использует более простой BM25.
   • Если генератор → возвращает ответ «извините, не могу обработать».
   • Если всё упало → переключается на кеш предыдущих ответов.
4. Использует circuit breaker — после N нарушений подряд перестаёт даже пробовать исполнителя в течение T секунд (паттерн из микросервисов).

Пример определения circuit breaker:

# config.yaml
workers:
  retrieval:
    endpoint: http://retrieval-service:5000
    circuit_breaker:
      failure_threshold: 5        # 5 ошибок подряд
      recovery_timeout: 30        # 30 секунд ожидания
      half_open_max_requests: 3   # после таймаута 3 пробных запроса

Менеджер при каждом вызове проверяет статус circuit breaker для исполнителя.

7. Проектирование SLA: компромиссы и trade-offs

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

8. Пример полного контракта (contract) в YAML

worker:
  id: generator-w1
  endpoint: http://generator:5000/generate
  sla:
    latency_ms:
      p99: 800
      error_quota_per_month: 0.001   # 0.1%
    availability:
      target: 0.999
      measurement_window: 1h
    quality:
      faithfulness_score_min: 0.9
      measure_every_n_requests: 100
    rate_limit:
      max_rps: 200
      burst: 20
    consequences:
      on_latency_breach: "circuit_breaker(5, 60s)"
      on_availability_breach: "remove_from_pool, alert"
      on_faithfulness_breach: "fallback_to_static_template, escalate"

Такой контракт хранится в файле или сервисе конфигурации и загружается менеджером при старте.

9. Как тестировать SLA до продакшена

• Load testing — с помощью Locust или k6 генерируем нагрузку, измеряем latency/availability.
• Chaos engineering — отключаем отдельные исполнители, проверяем, как система справляется.
• Quality testing — на размеченном датасете проверяем faithfulness, чтобы SLO не был слишком оптимистичным.

После тестов корректируем пороги.

Пет-проект для закрепления

Задача: построить мини‑agentic систему из менеджера и двух исполнителей (retrieval и sum‑up). Реализовать SLA, мониторинг и fallback.

Инструменты:

• Python + FastAPI (менеджер и исполнители)
• Prometheus + Micrometer (для метрик)
• Circuit breaker библиотека (например, pybreaker)

Шаги:

1. Создайте исполнителя retrieval с endpoint /search, который принимает query и возвращает документы. Добавьте health check и metrics endpoint.
2. Создайте исполнителя sum‑up с GPT‑запросом. Измеряйте faithfulness с помощью маленького классификатора (или заглушки с рандомным скором).
3. Менеджер получает запрос, сначала вызывает retrieval, потом sum‑up. Реализуйте таймаут в 500 ms на каждый вызов.
4. Интегрируйте Prometheus: в исполнителе регистрируйте гистограмму latency, счётчик success/fail.
5. Настройте circuit breaker: если исполнитель упал 3 раза за 10 секунд, отключать его на 30 секунд и использовать fallback (просто вернуть текст «временно недоступно»).
6. Напишите тест (например, с time.sleep(2) в sum‑up), чтобы искусственно нарушить SLA. Убедитесь, что менеджер отключает исполнителя.

Ожидаемый результат: менеджер корректно детектит нарушение, переключается на fallback, а через 30 секунд пробует снова (half‑open). Метрики в Prometheus отображают скачки latency и доступности.

Связь с другими вопросами

Навигация

• Предыдущий: 766
• Следующий: 768
• Индекс: 00. Индекс разборов