部门内部 RFC 模板

技术决策必须可追溯、可反驳。

这是我们部门写 RFC（Request for Comments）的格式。所有跨团队的技术决策、新系统上线、第三方依赖引入，必须走 RFC。

元信息（YAML 头部）

---
id: 0042            # 单调递增
title: 用 Doris 替换 BI 侧 ClickHouse
status: proposed    # proposed | accepted | rejected | superseded
authors: [tommy, alex]
date: 2026-07-22
deciders: [data-platform, infra]
---

正文结构

1. Context（为什么写这个）

2-3 段，说明触发这件事的原因。可能是：上游系统变了、性能不行了、某个库停止维护、新业务需求。

写背景，不是写历史。

2. Proposal（一句话能讲清）

一句话描述我们要做什么。读者应该读完这一句就知道你打算干什么。

3. Detailed design（看复杂度决定长短）

• 数据流图（必须）
• 接口变更（必须）
• 数据库 schema 变更（如果有）
• 第三方依赖（必须有理由）

4. Alternatives considered（我们想了哪几条路）

每条路都列出来 + 为什么没选。包括”维持现状”。

5. Risks & mitigations

• 性能 / 可用性影响
• 回滚成本
• 人员依赖

6. Rollout plan

分阶段。每阶段有明确验收标准。

评审流程

1. 作者提交 PR → 标签 rfc
2. 48h 内 deciders 必须给出意见（接受 / 拒绝 / 修订）
3. 反对意见必须留 comment + alternative
4. 接受 ≠ 一致同意。需要的是「无强反对 + 至少 2 个 decider 支持」

写 RFC 的反模式

• ❌ “我们之前讨论过……” → 这是口头决议，不是 RFC
• ❌ 把 RFC 写成方案文档 → RFC 是讲为什么，方案文档在 RFC 接受后写
• ❌ 写 30 页 → 没人会读完。3 页以内 是合理目标
• ❌ 没有 alternatives → 说明作者没认真想过

为什么一定要写

公司运转的主循环是 signal → selection → launch → optimize。RFC 是 selection 阶段的产出物。

没有 RFC 的决策是黑盒决策——下次新同事来问”为什么当时这么做”，没人答得上来。