Production-мониторинг ML-модели с алертами и дашбордами

Разработай полную и реализуемую стратегию мониторинга для модели {model_type}, которая обрабатывает {data_source}, обслуживает {business_context} и отслеживается по метрике {performance_metric}.

Если placeholders не заменены, используй явную пометку "ЗАМЕНИТЕ_ЗДЕСЬ" вместо выдуманных значений.

Структура результата должна идти строго по разделам:
a. Краткое резюме.
b. Цели мониторинга и SLA/SLO с конкретными числами.
c. Ключевые метрики и их определения.
d. Проверки качества данных:
   - имя;
   - метрика;
   - метод вычисления SQL или Python;
   - частота;
   - пороги тревоги и допустимый темп изменения;
   - пример запроса или кода.
e. Мониторинг производительности модели:
   - {performance_metric};
   - окна расчёта;
   - методы детекции дрейфа и регрессии;
   - статистические тесты;
   - warning и critical thresholds;
   - пример кода расчёта и хранения метрик.
f. Инфраструктурный мониторинг:
   - CPU, memory, latency p50/p95/p99, error rate, request rate и другие обязательные метрики;
   - пример правил Prometheus или Grafana.
g. Бизнес-KPI и связь деградации модели с изменением KPI.
h. Оповещения и процедуры эскалации по уровням info, warn и critical.
i. Рекомендации по дашбордам, панелям и PromQL или SQL.
j. Минимальные готовые к вставке фрагменты кода:
   - отправка метрик в Prometheus через python/prometheus_client;
   - SQL-проверки качества данных;
   - правило Alertmanager или Prometheus YAML;
   - пример панели Grafana.

Ограничения:
- представь одну последовательную законченную стратегию;
- для ключевых проверок укажи baseline и допустимое отклонение;
- обязательно включи минимум 5 production-алертов и runbook на 5 шагов для критической деградации {performance_metric};
- не добавляй пояснений вне указанной структуры.