# Лабораторная 04: PRODUCTION-READY ИНФРАСТРУКТУРА

> Спринт 4 · Недели 7–10 · 28 дней · 20 баллов

**Вопрос спринта:** Production-ready?

Прототип становится системой, которой можно доверять: CI/CD деплоит сам, мониторинг видит всё, evals ловят регрессии, инъекции отбиты, а скоуп под контролем burndown.

## Формат сдачи

- Pull Request от каждой роли
- Ветка: `lab4-[role]-infrastructure`
- Заголовок PR: `Lab4: [Role] — Infrastructure Deliverables`

## Роли и шаги

### PRODUCT / VO — Скоуп под контролем: burndown и приёмка

Отвечает за то, что длинный спринт не расползся: скоуп зафиксирован, темп виден на burndown, инкременты принимаются по DoD.

#### Шаг 1. Burndown спринта (3–4 часа)

_Четыре недели без графика темпа — четыре недели самообмана._

- Задачи спринта оценены и разбиты
- Burndown обновляется минимум дважды в неделю
- Отклонение от линии — повод для решения, не для паники

**Сдаёшь:** Burndown chart спринта [документ] → `docs/burndown.md`

#### Шаг 2. Фиксация MVP-скоупа (2–3 часа)

_Скоуп, который не зафиксирован, растёт сам._

- Что входит в MVP к Demo Day — списком
- Что вырезано — тоже списком, с причинами

**Сдаёшь:** Зафиксированный скоуп MVP [документ] → `docs/mvp-scope.md`

#### Шаг 3. Приёмка инкрементов (3–4 часа)

_Принятое по DoD не возвращается на доработку в лабе 5._

- Еженедельная приёмка готового по DoD
- Отклонения — задачами, не устно

**Сдаёшь:** Протоколы приёмки [документ] → `docs/acceptance/`

#### Шаг 4. Требования v3 (2–3 часа)

_К тестированию требования должны догнать реальность._

- Обновление PRD/UC по итогам месяца
- Целевые значения North Star уточнены

**Сдаёшь:** Требования v3 [документ] → `docs/requirements-v3.md`

**Советы:** Burndown не врёт — врут оценки · Вырезать фичу — решение, а не поражение · Принимай еженедельно, не в конце · Длинный спринт любит короткие синхроны

### AI ENGINEER — Качество растёт по данным evals

Отвечает за рост качества модели — направленный отчётом «где врём», подтверждённый прогонами, оплаченный разумным числом токенов.

#### Шаг 1. Итерации по отчёту «где врём» (8–10 часов)

_Улучшать нужно то, что провалено, — а не то, что интересно._

- Промпты v2 по типам ошибок из отчёта
- Каждая итерация — прогон evals до и после
- Изменения без прироста откатываются

**Сдаёшь:** Промпты v2 + прогоны [код] → `ml/prompts_v2/`

#### Шаг 2. A/B эксперименты (5–6 часов)

_«Стало лучше» — это разница двух прогонов, а не ощущение._

- Сравнение вариантов промптов/параметров на датасете
- Выводы с цифрами в ноутбуке

**Сдаёшь:** A/B эксперименты [ноутбук] → `notebooks/ab_experiments.ipynb`

#### Шаг 3. Оптимизация стоимости (4–5 часов)

_Токен-бюджет — продуктовое ограничение, не мелочь._

- Кэширование повторяющихся запросов
- Сокращение контекста без потери качества
- Стоимость сценария до/после — в цифрах

**Сдаёшь:** Отчёт по стоимости [документ] → `docs/ml-cost.md`

#### Шаг 4. ADR по итогам месяца (2–3 часа)

_Большие изменения пайплайна — это решения с ценой._

- ADR на значимые изменения AI-части
- Поле «Цена решения» заполнено

**Сдаёшь:** ADR AI-изменений [документ] → `docs/adr/`

**Советы:** Оптимизируй по отчёту, не по интуиции · Прогон до и после — иначе это не итерация · Кэш — самый дешёвый прирост скорости · Дорогой пайплайн убьёт продукт после курса

### DELIVERY — Система, которая деплоит и наблюдает себя сама

Отвечает за производственный контур: автодеплой, staging как прод, наблюдаемость по трём столпам и лимиты, которые не дают сжечь бюджет.

#### Шаг 1. CI/CD до прода (6–8 часов)

_Деплой руками — это деплой, который однажды забудут._

- Пайплайн: тесты → сборка → деплой на прод
- Прод обновляется на каждый мёрж в main
- Откат — одной командой

**Сдаёшь:** CI/CD пайплайн [конфиг] → `.github/workflows/deploy.yml`

#### Шаг 2. Staging ≈ prod (4–5 часов)

_«На стейдже работало» имеет смысл, только если staging повторяет прод._

- Staging-окружение из тех же compose-файлов
- Различия окружений задокументированы

**Сдаёшь:** Staging-окружение [конфиг] → `compose.staging.yml + docs/environments.md`

#### Шаг 3. Наблюдаемость: три столпа (6–8 часов)

_Метрики, логи, трейсы — иначе прод это чёрный ящик._

- Grafana-стек: метрики и логи сервисов
- Langfuse — трейсы LLM в общем контуре
- Дашборд: главное о системе на одном экране

**Сдаёшь:** Мониторинг-контур [конфиг] → `monitoring/`

#### Шаг 4. Токен-лимиты в проде (3–4 часа)

_Бюджет сгорает за ночь, если прод не умеет говорить «хватит»._

- Лимиты запросов и токенов на пользователя/день
- Деградация на дешёвую модель по ADR
- Алерт при аномальном расходе

**Сдаёшь:** Лимиты и деградация [код] → `backend/limits/`

**Советы:** Автодеплой освобождает вечера · Откат репетируется до того, как понадобился · Дашборд, куда не смотрят, не существует · Лимит лучше извинений за сгоревший бюджет

### QUALITY & SAFETY — Регрессия и безопасность — на каждый PR

Отвечает за принцип «новое не ломает старое»: полные evals в CI, отбитые инъекции, покрытые критические пути.

#### Шаг 1. Полная регрессия в CI (5–6 часов)

_Заготовка из лабы 3 становится воротами качества._

- Полный golden dataset гоняется в CI
- Пороги по метрикам: ниже — мёрж запрещён
- Время прогона разумно (кэш, параллель)

**Сдаёшь:** Quality-gates в CI [конфиг] → `.github/workflows/quality-gates.yml`

#### Шаг 2. LLAMATOR и инъекции (6–8 часов)

_Threat model из лабы 2 пора проверить атакой._

- LLAMATOR-прогон по точкам входа из threat model
- Prompt injection: прямые и обходные варианты
- Найденные дыры — задачи с приоритетом

**Сдаёшь:** Отчёт безопасности v1 [документ] → `docs/quality/security-report-1.md`

#### Шаг 3. Тесты критических путей (5–6 часов)

_Evals меряют модель — тесты держат систему._

- Интеграционные тесты ключевых UC
- Тесты лимитов и деградации
- Покрытие критического — не «всего»

**Сдаёшь:** Тесты критических путей [код] → `tests/`

#### Шаг 4. Отчёт качества за месяц (3–4 часа)

_Середина курса — время честного среза._

- Динамика метрик от лабы 3
- Что улучшилось, что стоит на месте
- Риски к лабе 5

**Сдаёшь:** Quality-отчёт середины курса [документ] → `docs/quality/midpoint-report.md`

**Советы:** Порог, который никогда не краснеет, — не порог · Атакуй свой продукт раньше, чем это сделают на демо · Тестируй пути денег и данных в первую очередь · Динамика важнее абсолютных цифр

## Definition of Done

Те же критерии видит автопроверка. Лаба сдана, когда выполнены все группы.

### Инфраструктура

- [ ] Мёрж в main автоматически деплоит на прод
- [ ] Staging поднимается из тех же compose-файлов
- [ ] Дашборд показывает метрики, логи и трейсы системы
- [ ] Лимиты токенов работают: аномалия вызывает алерт

### Качество и безопасность

- [ ] Полный eval-набор гоняется в CI с порогами
- [ ] LLAMATOR-прогон выполнен, дыры оформлены задачами
- [ ] Критические UC покрыты интеграционными тестами
- [ ] Quality-отчёт середины курса с динамикой метрик

### Продукт

- [ ] Burndown вёлся весь спринт и лежит в репо
- [ ] MVP-скоуп зафиксирован, вырезанное — с причинами
- [ ] Еженедельные приёмки запротоколированы
- [ ] Требования v3 обновлены

## Чек-лист перед PR

### Система production-ready

- [ ] Деплой происходит без рук
- [ ] Откат отрепетирован
- [ ] Staging повторяет прод
- [ ] Дашборд открыт и понятен без объяснений
- [ ] Лимиты срабатывают на тестовой аномалии
- [ ] Compose-файлы поднимаются на чистой машине

### Качество под защитой

- [ ] Quality-gates краснеют при деградации
- [ ] Инъекции из threat model отбиты
- [ ] Критические пути покрыты тестами
- [ ] Burndown актуален
- [ ] Приёмки проведены по DoD
- [ ] Midpoint-отчёт готов

## Материалы к лабе

- [МОНИТОРИНГ](/materials/observability/three-pillars) — Метрики, логи, трейсы
- [DOCKER](/materials/docker/basics) — Образы и multi-stage
- [ОЦЕНИВАНИЕ](/materials/labs/grading-system) — Как считаются баллы
- [ВСЕ МАТЕРИАЛЫ](/materials) — База материалов курса

---

_Четыре недели, двадцать баллов, и на выходе — система, которая деплоит себя сама, наблюдает себя сама и не даёт себе врать. Production-ready — это здесь._

Человеческая версия: /labs/lab4