2.2.3 · блок 2
ADR и RFC: фиксация архитектурных решений
ADR и RFC: фиксация архитектурных решений
Зачем это нужно
Через полгода никто не вспомнит, *почему* вы выбрали batch scoring вместо online API. Новый MLE предложит «переписать всё на realtime» — и команда потратит спринт на уже отвергнутую идею. ADR (Architecture Decision Record) — короткий документ: контекст, решение, последствия. Это память команды.
RFC (Request for Comments) — более ранний формат: предложение обсудить *до* принятия решения. В крупных компаниях RFC → review → ADR. В учебном проекте достаточно ADR.
Основные идеи
Шаблон ADR (по adr.github.io):
# ADR-003: Batch vs Online inference для fraud scoring
## Status
Accepted (2025-03-15)
## Context
- Требование PM: скоринг при каждом платеже (< 100 ms).
- DS обучил ensemble с latency ~400 ms на CPU.
- Бюджет на GPU inference ограничен.
## Decision
Используем гибрид:
- Online: LightGBM (< 50 ms) для authorize/decision.
- Batch: ensemble раз в 15 min обновляет risk score в профиле.
## Consequences
+ Укладываемся в SLA authorize.
+ Тяжёлая модель всё равно участвует в риск-профиле.
- Два пайплайна inference — больше кода и мониторинга.
- Batch score может отставать до 15 min (принимаем для non-real-time сценариев).
Статусы ADR: Proposed → Accepted → Deprecated / Superseded by ADR-007.
Где хранить: docs/adr/ в Git (версионируется вместе с кодом) + ссылка из Confluence Service Page. Нумерация последовательная: ADR-001, ADR-002.
RFC vs ADR:
| | RFC | ADR |
|---|-----|-----|
| Когда | До решения | После решения |
| Цель | Собрать feedback | Зафиксировать итог |
| Аудитория | Вся команда + stakeholders | Инженеры |
Batch vs Online — классический пример для ML:
- Online inference: запрос → модель → ответ в реальном времени. Нужен для fraud, search ranking, персонализации «здесь и сейчас».
- Batch inference: периодически прогоняем модель по всему датасету, результаты пишем в таблицу. Нужен для сегментации, churn prediction, offline enrichment.
ADR фиксирует не только «что выбрали», но и «что отвергли» — чтобы не возвращаться к тем же дебатам.
Как это выглядит на практике
Story в Jira ML-88: Implement batch risk score job:
- Description: «Согласно ADR-003, batch path использует ensemble_v2».
- AC: job завершается < 30 min; записывает в
user_risk_scores; алерт при failure.
RFC (до ADR) мог называться «RFC: Inference architecture for fraud» — в Confluence комментарии от Backend («нужен idempotency»), SRE («где алерт на job lag»), PM («15 min delay ok»).
После принятия RFC закрывается, создаётся ADR-003, RFC помечается Superseded.
Что сделать после занятия
- [ ] Напишите ADR для выбора batch или online inference в учебном проекте.
- [ ] Укажите минимум 2 positive и 1 negative consequence.
- [ ] Добавьте ссылку на ADR в описание воображаемой Jira-Story.