RFC-процесс для инженерных команд: шаблон и реальные примеры
Команда из 40 инженеров за 8 месяцев приняла одно и то же архитектурное решение дважды — в июне и в феврале, оба раза откатила. После второго отката наконец внедрили RFC-процесс. Разбирая историю коммитов, они обнаружили: оригинальный контекст остался в Slack-треде, который автоматически архивировался через 90 дней, а инженер, который владел решением, уже уволился. RFC-документ стоил бы 4 часа на написание и сэкономил бы примерно 3 инженеро-недели переделок.
RFC-процессы существуют потому, что технические решения переживают людей, которые их приняли. Stripe, Cloudflare, Oxide Computer и проект Rust публично описывают свои RFC-форматы — и общая структура уже, чем кажется большинству команд. Эта статья — тот самый шаблон, к которому они сходятся, плюс реалистичный ревью-цикл для команд 10-80 человек, плюс честные цифры о том, когда RFC просто тратят время.
{/* truncate */}
Какую проблему RFC реально решают
RFC — это не документирование решений. Это структурированное несогласие до коммитмента. Документ заставляет автора записать: что я предлагаю, какие альтернативы отверг, что сломается, если я неправ.
Внутренний анализ Google по эффективности design doc (опубликован в Software Engineering at Google, 2020, Winters et al.) показал, что главная ценность — не сам документ, а вынужденная конкретика мышления автора. Команды отмечали на 40% меньше архитектурных споров постфактум при наличии design doc — не потому что документ читали, а потому что процесс написания выбивал расплывчатое мышление до того, как код ушёл в прод.
Исследование Microsoft Research (2023) по "decision debt" в больших инженерных организациях измерило цену недокументированных решений: инженеры в среднем тратят 3.2 часа в неделю на передумывание того, что уже было решено. Для команды 40 человек с нагруженной стоимостью $200k это примерно $1.3M/год на передумывание.
RFC-шаблон (6 секций)
Скопируйте. Отредактируйте. Структура важнее текста.
# RFC-042: [Короткий заголовок]
**Автор:** [имя]
**Статус:** Draft | Open for review | Accepted | Rejected | Superseded
**Дедлайн ревью:** [дата]
**Deciders:** [2-3 имени — те, чьё одобрение имеет значение]
## 1. Проблема
Что сломано, какова цена статус-кво, кого это затрагивает?
Конкретно, с цифрами. "Медленный CI" — не проблема; "CI занимает 47 минут P95
и блокирует 12 PR в день" — проблема.
## 2. Предложение
Что вы собираетесь делать? В одном абзаце. Потом детали.
## 3. Рассмотренные альтернативы
Минимум 2 альтернативы, на каждую — одна фраза причины отказа.
Если рассмотрели только своё предложение — вы не думали.
## 4. Trade-off и риски
Сколько это стоит? Что сломается, если вы неправ? Как откатить?
Если откатить нельзя — явно пометьте.
## 5. Критерии успеха
Как поймём, что сработало? Конкретные метрики с baseline-цифрами.
"Быстрее" — не критерий; "P95 CI меньше 15 минут за 4 недели" — критерий.
## 6. Открытые вопросы
То, на что хотите ответ от ревьюеров. Не риторика. Реальные дыры в мышлении.
Это весь шаблон. Секции 3 и 6 — те, которые команды пропускают, и те, которые делают работу.
Полный цикл RFC. Большинство команд нормально справляются с первыми тремя шагами и проваливают "Зафиксированное решение" — где лежит документ после принятия, определяет, найдёт ли его кто-то через 18 месяцев.
Ревью-цикл, который работает
Большинство команд пересчитывают на документ и недочитывают тайминг ревью. Из того, как Cloudflare, Stripe и Oxide гоняют свои RFC-процессы (все трое публикуют пост-мортемы своих процессных решений), три устойчивых паттерна работают.
| Размер команды | Ревью-окно | Кол-во deciders | Пропускная способность |
|---|---|---|---|
| 5-15 инженеров | 3-5 дней | 1-2 | 1-2 RFC/мес |
| 15-40 инженеров | 5-7 дней | 2-3 | 3-5 RFC/мес |
| 40-80 инженеров | 7-10 дней | 3-4 + domain expert | 6-10 RFC/мес |
| 80+ инженеров | 10-14 дней | RFC-совет (ротация) | 10-20 RFC/мес |
Короче 3 дней — и senior-инженеры аппрувят "по умолчанию", потому что не успели прочитать. Длиннее 14 — и momentum умирает: автор начинает строить, пока документ ещё "на ревью", и ревью превращается в театр.
Что заслуживает RFC
Не каждое решение достойно RFC. Тест: захочет ли другой инженер через 6 месяцев понять, почему выбрали так?
| Тип изменения | Нужен RFC? | Почему |
|---|---|---|
| Новый микросервис | Да | Формирует архитектуру надолго |
| Postgres → Redis для сессий | Да | Стоимость, failure modes, обратимость |
| Переименование внутреннего endpoint | Нет | Легко искать в git log |
| Feature-flag система | Да | Влияние на всю организацию |
| Minor-апгрейд библиотеки | Нет | Рутина |
| Blue-green → canary деплой | Да | Меняет release confidence и MTTR |
| Параллельный тестовый фреймворк | Да | Создаёт maintenance split надолго |
| Фикс бага | Нет | Достаточно commit message |
Процесс Rust RFC явно разделяет proposals на "minor", "major" и "language-altering". Для инженерных команд проще: если изменение запирает в направлении, откатывать которое больно — RFC. Иначе — ship и документируйте в описании PR.
Реальные примеры (очищенные)
Разбор публичного RFC-репозитория Oxide Computer и выборки RFC-процессов наших клиентов даёт три показательных кейса:
RFC, который нормально зашёл: "Переезд с Elasticsearch на Meilisearch для внутреннего поиска". Конкретная проблема (ES-кластер за $4k/мес при 40k запросов/мес), конкретное предложение (Meilisearch на имеющемся железе БД), три альтернативы (PostgreSQL FTS, Typesense, остаться на ES), явный revert-path (переключение DNS, данные хранятся 90 дней), критерий успеха (search latency P95 < 200ms, инфра < $500/мес за 6 недель). Доехал за 5 недель. Попал в таргеты.
RFC, который спас от ошибки: "GraphQL для всех новых API". Предложение было сильным. Ревью всплыло, что 3 существующих service-to-service вызова уже REST, а стоимость миграции проигнорирована. Секция альтернатив была пропущена. Автор переписал в "GraphQL только для customer-facing BFF, REST для внутреннего". Через два года — всё ещё правильное решение.
RFC, который потратил время: "Переезд на microfrontends". Проблема не сформулирована — у команды не было конкретной боли. Два месяца ревью, нет решения, в итоге отправили в архив. Урок: если секция 1 (Проблема) расплывчата — закрывайте RFC на первом же круге, не на третьем.
Типичные сбои
"Pocket veto" — RFC висит на ревью 3 недели, явного отказа нет, автор сдался. Самый частый сбой. Фикс: жёсткий дедлайн в шаблоне, decider отвечает за yes/no/revise к дате.
"Одобрение молчанием" — никто не комментирует, RFC автопринимается, потом никто не помнит, что его одобрял. Фикс: требовать явный LGTM от именованных deciders, не "нет возражений".
"Ретро-RFC" — код уже написан, RFC — театр. Видно по секции альтернатив — там по две строчки отбрасывания. Не бесполезно (документация есть), но это уже не процесс принятия решений. Не называйте это RFC — назовите ADR (Architecture Decision Record) и двигайтесь дальше.
"Размножение RFC" — команда из 40 человек пишет 15 RFC в месяц. Порог слишком низкий. Поднимите планку: RFC только если стоимость отката больше одной инженеро-недели.
Как измерить, что RFC работают
Здесь большинство команд останавливаются. Процесс внедрили — проверить, работает ли он, забыли. Три метрики:
| Метрика | Здоровый диапазон | Красный флаг |
|---|---|---|
| Принятые vs черновики | 60-80% | >95% (театр) или <40% (churn) |
| Медиана дней открыт | 5-10 дней | >21 (pocket-veto) |
| RFC цитируется в пост-мортемах | 20-40% инцидентов | 0% (никто не читает) |
| Откаты решений за квартал | 0-2 | 4+ (RFC не вытаскивают trade-offs) |
PanDev Metrics автоматически подсвечивает один релевантный сигнал: когда инженеры коммитятся в новый проект или паттерн, мы можем соотнести это с наличием RFC в этой зоне. Команды с корреляцией RFC-к-коммитам выше 60% обычно получают меньше production-инцидентов в 90-дневном окне после изменения — хотя выборка здесь маленькая (14 команд), и причинность мы не заявляем. Корреляция подсказывает, но не доказывает.
Контринтуитивный тезис
RFC переоценены для маленьких команд. До 10 инженеров ревью имеет тот же decider-пул, что и Slack-тред, ревью-окно имеет ту же латентность, что и async-чат, а результат (решение) тот же. RFC просто добавляет стоимость писанины. Где RFC отбивают себя: 15+ инженеров, кросс-командная координация, решения, переживающие автора в компании.
Честный лимит: по нашим данным мы не можем утверждать, что команды, пишущие RFC, шипят лучший софт, потому что качество напрямую мы не меряем. Что видим: у команд с документированными решениями меньше экстренных Slack-тредов в 11 вечера — и инженеры, с которыми мы общаемся, воспринимают это как "система работает".
Что почитать
- 10 инженерных метрик, которые должен трекать каждый менеджер
- Code Review Checklist: 11 правил, которые вдвое сокращают время ревью
- Как проводить data-driven 1:1 с разработчиками
Если ваша команда написала больше трёх RFC и не может ответить "помогли ли они?" цифрой — это и есть настоящая проблема, которую стоит решать.