架构评审方法论
# 07.架构评审方法论
# 目录介绍
# 1. 案例引入
# 1.1 评审会上的悲剧
先看一个真实发生过的架构评审事故。某中型公司一支 25 人团队，准备上线一个全新的订单履约系统，替换跑了 6 年的祖传单体。架构师老李熬了两周画出 45 页 PPT，包含：领域模型、服务拆分、技术选型、部署拓扑、数据库设计——堪称尽善尽美。
评审会现场，8 个评委、2 小时，过程如下：
14:00 老李开讲,从业务背景讲到技术选型,40 页 PPT 飞速过
14:35 评委 A (CTO):"看起来挺合理的,我没什么问题"
14:38 评委 B (运维总监): "数据库用 PostgreSQL?以前没用过,行吗?"
老李: "性能没问题,我跑过 benchmark"
B: "哦那行"
14:42 评委 C (安全): "权限怎么做?"
老李: "RBAC,详见第 32 页"
C: 翻页看了看, "OK"
14:50 评委 D (业务方): "我们 618 大促能扛住吗?"
老李: "做了压测,5000 QPS 没问题"
D: "那挺好"
15:30 评委 E (技术委员会): 沉默
15:50 会议结论: 通过,可以开干
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
评审"顺利通过"——三个月后上线，结果：
| 时间 | 事故 |
|---|---|
| 上线第 3 天 | 一次小批量退款触发死锁——评审会没人问"事务边界设计" |
| 上线第 14 天 | 大促预热阶段 QPS 冲到 8000，Redis 缓存击穿导致 DB 雪崩——评审会"5000 QPS"是平峰估算 |
| 上线第 30 天 | 一份越权查询泄漏了 20 万用户订单——评审会"RBAC 详见第 32 页"那一页没人真看 |
| 上线第 60 天 | 团队发现需要回退,但数据库已不可逆地迁移——评审会从没讨论"回滚预案" |
复盘会上 CTO 一句话定性：
"这场评审通过了,但本质上是一场什么都没评的会。"
# 1.2 顺藤摸到根因
带着这条线往下挖：
- 假设 1：是不是评委不专业？——不是，CTO/安全/运维都是行业 10 年+ 老兵
- 假设 2：是不是 PPT 不够详细？——不是，45 页已经接近"过度详细"
- 假设 3：是不是时间太短？——2 小时对 45 页确实紧，但根因不在这
- 假设 4：那到底是什么？——评审没有任何方法论，全凭评委"凭感觉提问"
- 假设 5：什么叫"方法论"？——一套可重复、可执行、有产出物的评审框架，让"该问的问题一个都不漏"
- 假设 6：为什么大厂能避免？——他们用 ATAM、质量属性场景、风险风暴、ADR 等成熟工具
- 假设 7：这些工具是什么、怎么用？——本篇的主线
仔细分析这次评审的问题：
评审表象 真实问题
─────────────────────────────────────────────────────────
评委轮流提问 → 没有结构化议程,凭直觉问
"看起来挺合理" → 没有量化标准 (5000 QPS 算合理吗?对谁?)
"详见第 32 页" → 没有逐条核对,文档=演讲稿而非清单
"没什么问题" → 没有挖风险机制,沉默 = 通过
"压测没问题" → 没有极端场景假设,平峰 ≠ 峰值
会议结论"通过" → 没有量化的"未解决项",通过即埋雷
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
根因：把架构评审当成"汇报会"——架构师讲、评委听、点头通过——而不是当成一次系统性的风险挖掘工程。
这一段事故里至少藏着 7 个原理点：
① 架构评审到底要评什么? 评的是设计还是过程? → 第 2 章
② 业务方说\"扛住大促\",怎么量化才能不打哈哈? → 第 3 章
③ 怎么从一份架构里系统性挖出风险点而不是凭感觉? → 第 4 章 ATAM
④ 谁来挖?评委各说各话怎么收敛? → 第 5 章 风险风暴
⑤ 评审通过的决定靠什么落地?会议记录够吗? → 第 6 章 ADR
⑥ 有没有checklist能保证不漏掉关键维度? → 第 7 章
⑦ 评审常见的坑有哪些?怎么识别走过场? → 第 8 章
1
2
3
4
5
6
7
2
3
4
5
6
7
# 1.3 我们要回答什么
这个事故就是本篇的主线案例。我们带着上面 7 个问号往下走，每讲完一段方法就解开一两个；最后在第 10 章把案例彻底剖开，并给出三种改进方案。
本篇路线：
评审全景图 (第 2 章)
↓
质量属性场景 (第 3 章) ─→ 解开\"业务诉求如何变成可评审的需求\"
↓
ATAM 评审法 (第 4 章) ─→ 解开\"如何系统化挖风险\"
↓
风险风暴 (第 5 章) ─→ 解开\"如何让所有人都贡献风险\"
↓
ADR (第 6 章) ─→ 解开\"如何把决策沉淀下来\"
↓
检查清单 (第 7 章) ─→ 武器库
↓
反模式 (第 8 章) + 实战流程 (第 9 章)
↓
综合案例 (第 10 章) ─→ 案例彻底剖开
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
📌 本篇定位：这是整个系列的收口篇。前六篇讲"怎么设计架构"，本篇讲"怎么确认设计对不对"——没有评审的架构，等于裸奔的架构。读完本篇后，再做任何架构决策，都能立刻回答："这个设计经得起 ATAM 拷问吗"。
# 2. 评审全景图
# 2.1 五大要素总图
我们看一次完整的架构评审应该包含什么：
┌─────────────────────────────────────────────────────────┐
│ 架构评审五大要素 │
├─────────────────────────────────────────────────────────┤
│ │
│ ① 质量属性场景 (Quality Attribute Scenarios) │
│ 定义\"好\"的可量化标准 │
│ (性能/可用性/安全/可维护性/可扩展性...) │
│ │ │
│ ▼ │
│ ② 架构方案 (Architecture Design) │
│ 给出针对场景的设计方案 │
│ (六边形/CQRS/微服务/事件驱动/DDD...) │
│ │ │
│ ▼ │
│ ③ 评审方法 (Review Method) │
│ ATAM / 风险风暴 / 检查清单 │
│ │ │
│ ▼ │
│ ④ 决策记录 (Architecture Decision Record) │
│ 沉淀\"为什么这么选\"+\"代价是什么\" │
│ │ │
│ ▼ │
│ ⑤ 跟进闭环 (Follow-up Loop) │
│ 风险跟踪 + 后续验证 + 持续 review │
│ │
└─────────────────────────────────────────────────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
五要素的核心属性速查：
| 要素 | 输入 | 输出 | 关键工具 |
|---|---|---|---|
| 质量属性场景 | 业务需求 | 可测量的六元组 | 优先级九宫格 |
| 架构方案 | 场景 + 约束 | 设计文档/原型 | 视图模型（4+1） |
| 评审方法 | 场景 + 方案 | 风险清单 | ATAM / 风险风暴 |
| 决策记录 | 评审结论 | ADR 文档 | 模板化 ADR |
| 跟进闭环 | 风险清单 + ADR | 验证报告 | 季度 review |
# 2.2 为什么这么切
为什么把架构评审切成"五要素"，而不是"开个会过一遍 PPT"？
疑惑：第 1 章的评审不就是"会议 + PPT + 评委"吗？为什么不够？
论证：
没场景就没标准——"扛住大促"是诉求不是标准，必须先变成"双 11 零点峰值 QPS 50000，P99 延迟 < 300ms，可用性 99.95%"这种可测量的场景。没场景的评审只能问"差不多吧"——第 1 章 "5000 QPS" 就是没场景的恶果。
没方法就只能拍脑袋——"你觉得这个设计行不行"是凭感觉，"按 ATAM 找敏感点和权衡点"是凭方法。方法论的本质是把"经验依赖"变成"流程依赖"——让新评委也能挖出老评委才发现的风险。
没决策记录就等于没开会——会议结论只在脑子里、邮件里、聊天记录里 → 三个月后没人记得"为什么选 PostgreSQL"。ADR 是架构的"基因"——没 ADR 的系统，三年后没人敢动。
没闭环就是白评——评审找出 30 个风险，没人跟踪 → 上线时 28 个仍未解决。第 1 章"权限详见第 32 页"就是典型——评审没真看，上线也没人补查。
反向验证：没有这五要素会怎样？答案就是第 1 章——评审通过，事故连发，复盘时才发现"该问的问题一个都没问"。
结论：五要素的本质是把"架构评审"从一次会议升级为一个完整工程过程——场景定义边界、方案给出答案、方法挖出风险、决策沉淀知识、闭环验证落地。少一环都漏风。
下面我们从最基础的"质量属性场景"开始，看它如何决定后续的一切。
# 3. 质量属性场景
# 3.1 可测量的需求
疑惑：业务方说"系统要快、要稳、要安全"——这能直接评审吗？
论证：试试看实际后果：
业务说: 评审会上:
"系统要快" → "我们做了缓存,快得很" → 通过
"系统要稳" → "用了集群,挂不了" → 通过
"系统要安全" → "RBAC 详见第 32 页" → 通过
上线后:
"快" → 平均 100ms,但 P99 是 5 秒,大促时全堆积 → 业务方崩溃
"稳" → 集群挂不了,但单机故障切换要 30 秒 → 业务方崩溃
"安全" → RBAC 做了,但越权 SQL 注入没防 → 数据泄漏
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
模糊需求 = 无法评审的需求 = 必然踩坑的需求。
结论：架构评审的第一步，把模糊的业务诉求翻译成可量化、可测试、可验证的"质量属性场景"。
❌ 不可评审 ✅ 可评审
"系统要快" → "用户提交订单后,P99 延迟 < 300ms"
"系统要稳" → "全年可用性 99.95% (年停机 < 4.4 小时)"
"系统要安全" → "未授权用户访问敏感接口 100% 返回 403"
"系统要好维护" → "新增一个支付通道,代码改动 < 200 行"
"系统要能扩展" → "QPS 从 1k 涨到 10k,只需横向扩容不改架构"
1
2
3
4
5
6
2
3
4
5
6
# 3.2 六元组模板
ATAM 创始团队（CMU SEI）总结了质量属性场景的标准六元组：
┌──────────────────────────────────────────────────────────┐
│ 质量属性场景六元组 │
├──────────────────────────────────────────────────────────┤
│ 1. Source (刺激源) 谁/什么触发了这件事 │
│ 2. Stimulus (刺激) 具体发生了什么 │
│ 3. Environment (环境) 在什么条件下发生 │
│ 4. Artifact (制品) 作用在系统哪个部分 │
│ 5. Response (响应) 系统应该怎么反应 │
│ 6. Measure (度量) 响应必须满足什么指标 │
└──────────────────────────────────────────────────────────┘
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
举例 1 · 性能场景：
Source: 1000 个并发用户
Stimulus: 同时提交订单
Environment: 正常运行 (非大促)
Artifact: 订单服务
Response: 成功创建订单并返回订单号
Measure: P99 延迟 < 500ms,成功率 ≥ 99.9%
1
2
3
4
5
6
2
3
4
5
6
举例 2 · 可用性场景：
Source: 某个 MySQL 主库
Stimulus: 硬件故障宕机
Environment: 生产环境运行时
Artifact: 订单数据库
Response: 自动切换到从库,告警通知
Measure: 切换时间 < 30s,数据丢失 0 条 (RPO=0)
1
2
3
4
5
6
2
3
4
5
6
举例 3 · 安全场景：
Source: 未登录的攻击者
Stimulus: 发起越权请求 (篡改 userId 查询他人订单)
Environment: 生产环境,所有时间
Artifact: 订单查询接口
Response: 拦截请求,返回 403,记录审计日志
Measure: 拦截率 100%,审计延迟 < 5s
1
2
3
4
5
6
2
3
4
5
6
举例 4 · 可维护性场景：
Source: 新接入一个支付通道 (如 PayPal)
Stimulus: 业务方提出接入需求
Environment: 开发阶段
Artifact: 支付适配层
Response: 新增一个 Adapter,无需修改主流程
Measure: 开发工作量 < 3 人日,主流程代码 0 行改动
1
2
3
4
5
6
2
3
4
5
6
为什么必须六元组？少任何一元都会让场景失真：
| 漏掉 | 后果 |
|---|---|
| Source | 不知道谁触发，没法压测 |
| Stimulus | 不知道做什么，没法验证 |
| Environment | 大促 vs 平峰差 10 倍，评审打架 |
| Artifact | 不知道改哪个模块，落地无依据 |
| Response | 不知道目标，评审没标准 |
| Measure | 没量化，"差不多"地通过 |
# 3.3 优先级九宫格
疑惑：场景写出来 50 个，全部要满足吗？
论证：不可能——质量属性之间天然冲突：
- 高性能 vs 高安全（每次校验都是开销）
- 高可用 vs 强一致（CAP 定理）
- 高扩展 vs 低成本（冗余资源花钱）
- 易维护 vs 高性能（抽象层降低性能）
所以场景必须分优先级。重要性 × 难度的九宫格：
重要性
▲
│
高 │ 先做 重点攻关 战略投入
│ (易到手) (核心) (长期)
│
中 │ 顺手做 认真做 可考虑
│
低 │ 不做 不做 不做
│
└────────────────────────►难度
低 中 高
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
九宫格判定法：
- 重要性：业务方打分 1~5（这个场景做不到，业务方有多痛？）
- 难度：技术团队打分 1~5（实现成本、技术风险）
- 按重要性 × 难度的二维坐标放进九宫格
- 资源优先投入"高重要 + 低/中难度"格子
第 1 章案例的复盘：
场景 重要性 难度 应放位置 实际投入
─────────────────────────────────────────────────────────────────
大促峰值 8000 QPS 5 3 重点攻关 ❌ 没做场景
退款事务一致性 4 3 重点攻关 ❌ 没考虑
越权访问拦截 5 2 先做 ❌ 没核对
新支付通道接入工时 2 4 不做 ✅ 不需要
数据库回滚预案 5 4 战略投入 ❌ 完全没想
1
2
3
4
5
6
7
2
3
4
5
6
7
5 个核心场景没一个被严肃评审——这就是事故连发的本质。
# 3.4 场景的反模式
最常见的写场景反模式：
反模式 1 · 形容词式场景
❌ "系统要稳定可靠,响应迅速"
✅ "P99 < 300ms,可用性 99.95%"
1
2
2
反模式 2 · 漏 Environment
❌ "支持 10000 QPS"
(评审通过,大促时挂了——原来是平峰 QPS)
✅ "大促零点峰值 10000 QPS,持续 30 分钟不降级"
1
2
3
2
3
反模式 3 · Response 描述太抽象
❌ "系统应自动恢复"
✅ "主库故障 → 30s 内 VIP 漂移到从库 → 业务无感切换"
1
2
2
反模式 4 · 无 Measure 不可验证
❌ "切换要快"
✅ "切换时间 < 30s,可用性影响 < 0.001%"
1
2
2
反模式 5 · 一个场景塞多个属性
❌ "在 1000 QPS 下,P99 < 300ms 且 0 数据丢失且支持灰度"
(评审时无从下手,改一个伤一个)
✅ 拆成 3 个独立场景:性能/一致性/可灰度
1
2
3
2
3
红线：没量化的场景不算场景——评审前先质检场景，质检不通过的场景不允许进入评审。这是第一道质量关。
# 4. ATAM评审法
# 4.1 ATAM九步流程
ATAM（Architecture Tradeoff Analysis Method）= 架构权衡分析方法，CMU SEI 1998 年提出，全球公认最系统的架构评审框架。
核心思想：通过质量属性场景驱动评审，识别敏感点（Sensitivity Point）、权衡点（Tradeoff Point）、风险（Risk）、非风险（Non-risk）。
ATAM 标准九步：
┌─────────────────────────────────────────────────────────┐
│ ATAM 九步评审流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ Phase 1: 演示 │
│ ┌──────────────────────────────────────────┐ │
│ │ 1. 介绍 ATAM 方法 (评委统一认知) │ │
│ │ 2. 介绍业务驱动 (业务方讲) │ │
│ │ 3. 介绍架构方案 (架构师讲) │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ Phase 2: 调查与分析 │
│ ┌──────────────────────────────────────────┐ │
│ │ 4. 识别架构方法 (用了哪些架构模式) │ │
│ │ 5. 生成质量属性效用树 (Utility Tree) │ │
│ │ 6. 分析架构方法 vs 高优先级场景 │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ Phase 3: 测试 │
│ ┌──────────────────────────────────────────┐ │
│ │ 7. 头脑风暴补充场景 (干系人各抒己见) │ │
│ │ 8. 重新分析架构方法 │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ Phase 4: 报告 │
│ ┌──────────────────────────────────────────┐ │
│ │ 9. 输出评审结论 (风险/权衡/敏感点/非风险) │ │
│ └──────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
时长: 2~3 天 (大型系统), 1 天 (中型), 半天 (小型)
人员: 评审组 + 架构师 + 业务方 + 干系人代表
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
ATAM 与传统评审的差异：
| 维度 | 传统评审 | ATAM |
|---|---|---|
| 驱动 | 评委拍脑袋问 | 场景驱动 |
| 产出 | 通过/不通过 | 风险/权衡/敏感点清单 |
| 时长 | 1~2 小时 | 半天~3 天 |
| 参与方 | 评委 + 架构师 | + 业务方 + 干系人 |
| 重复性 | 每次靠人 | 流程化可复制 |
# 4.2 效用树构建
效用树（Utility Tree） 是 ATAM 第 5 步的核心产出——把"质量"层层分解为可评审的场景。
树形结构：
效用 (Utility)
│
┌───────────┼───────────┬─────────┐
▼ ▼ ▼ ▼
性能 可用性 安全 可维护性 ← 质量属性
│ │ │ │
┌───┴───┐ ┌───┴───┐ ┌──┴──┐ ┌──┴──┐
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
吞吐 延迟 故障 恢复 授权 审计 改 扩 ← 子属性
│ │ │ │
▼ ▼ ▼ ▼
场景A 场景B 场景C 场景D ← 具体场景 (六元组)
(H,H) (H,M) (M,H) (L,L) ← 重要性,难度
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
效用树构建步骤：
Step 1: 列出顶层质量属性 (5~7 个)
- 性能 / 可用性 / 安全 / 可维护性 / 可扩展性 / 易用性 / 成本
Step 2: 每个属性下分子属性 (2~4 个)
- 性能 → 吞吐量 / 延迟 / 资源利用率
- 可用性 → MTBF / MTTR / 故障切换
Step 3: 每个子属性下挂具体场景 (六元组)
Step 4: 给每个场景打标 (重要性, 难度)
- (High, High) ← ATAM 评审的重中之重
- (High, Medium)
- (Medium, High)
- 其他 → 低优先级
Step 5: 评审聚焦 (H, H) 和 (H, M) 的场景
(低优先级场景不展开评审,但仍记录)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
第 1 章案例的效用树（事后补做）：
订单履约系统效用
│
┌───────────┬───┴────┬──────────┐
▼ ▼ ▼ ▼
性能 可用性 安全 可维护性
│ │ │ │
▼ ▼ ▼ ▼
[大促峰值] [DB主备] [越权访问] [新支付接入]
8000 QPS 切换<30s 100%拦截 <3人日
(H,H) (H,H) (H,M) (M,L)
│ │ │
▼ ▼ ▼
重点评审 重点评审 重点评审
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
如果当初做了这棵树——会议自然会聚焦在这 3 个高优先级场景上，不会出现"5000 QPS 哦那行"这种轻飘飘的通过。
# 4.3 敏感点权衡点
ATAM 的核心产出是四种点：
┌──────────────────────────────────────────────────────────┐
│ 概念 定义 举例 │
├──────────────────────────────────────────────────────────┤
│ Sensitivity Point 改它会显著影响某个 Redis 连接池大小 │
│ (敏感点) 质量属性的设计决策 → 影响吞吐量 │
│ │
│ Tradeoff Point 改它同时影响多个质量 同步 RPC vs 异步事件│
│ (权衡点) 属性,需要权衡 → 性能 vs 一致性 │
│ │
│ Risk 不确定能否满足场景的 "听说能扛 8000 │
│ (风险) 设计决策 QPS,但没压测" │
│ │
│ Non-Risk 已确认能满足场景的 "Nginx 负载均衡, │
│ (非风险) 设计决策 业界成熟方案" │
└──────────────────────────────────────────────────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
举例分析——对"订单服务用 PostgreSQL"这个决策：
分析维度 识别结果
──────────────────────────────────────────────────
影响哪些属性? 性能 (TPS)、可用性 (故障切换)、可维护性 (运维)
↓
有几个敏感点? - 单库写 QPS 上限 (敏感点)
- 连接池大小 (敏感点)
- 主备切换时间 (敏感点)
↓
有权衡吗? 是 → 强一致 vs 高性能 (权衡点)
- 选 PostgreSQL + 强一致 → TPS 受限
- 选 MySQL + 异步复制 → 一致性弱
↓
有风险吗? 是 → 团队没用过 PostgreSQL (风险)
是 → 大促压测未做 (风险)
↓
有非风险吗? 是 → 备份恢复方案成熟 (非风险)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ATAM 评审记录表：
| ID | 决策 | 类型 | 影响场景 | 缓解措施 | Owner |
|---|---|---|---|---|---|
| R1 | 选用 PostgreSQL | Risk | 性能场景 P1 | 上线前压测 | 老李 |
| T1 | 同步 vs 异步退款 | Tradeoff | 一致性 vs 性能 | 走异步+对账 | 老王 |
| S1 | Redis 连接池=200 | Sensitivity | QPS、内存 | 监控+预警 | 运维组 |
| N1 | Nginx 负载均衡 | Non-Risk | 可用性 | 无需操作 | - |
# 4.4 风险与非风险
风险 vs 非风险的判定——这是 ATAM 最常被混淆的点：
判定流程:
某个设计决策
│
▼
"能保证场景 Measure 达标吗?"
│
┌──────┴──────┐
▼ ▼
能保证 不能保证
│ │
▼ ▼
非风险 是风险
│
▼
"为什么不能保证?"
│
┌──────┴──────┬──────┐
▼ ▼ ▼
未验证 未实现 有冲突
→ 验证后 → 实现后 → 必须权衡
可能转非风险 可能转非风险 → 权衡点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
风险的处置方式：
| 风险等级 | 定义 | 处置 |
|---|---|---|
| 高 | 极大概率影响核心场景 | 上线前必须解决 |
| 中 | 一定概率影响关键场景 | 上线前应有缓解措施 |
| 低 | 小概率影响一般场景 | 监控 + 应急预案 |
非风险也要记录——证明"评审思考过了，确实没问题"，避免未来回头质疑"当初为啥没考虑"。
评审报告的关键章节：
# XXX 系统架构评审报告
## 1. 评审场景清单
[按效用树罗列高优先级场景]
## 2. 风险清单 (Risks)
[按等级、Owner、Deadline 列表]
## 3. 权衡清单 (Tradeoffs)
[描述选择 A 牺牲 B、为什么、如何监控 B 不出问题]
## 4. 敏感点清单 (Sensitivity Points)
[改这里会影响什么、谁负责守护]
## 5. 非风险清单 (Non-Risks)
[确认评审过、不构成风险的决策]
## 6. 后续行动
[风险跟踪计划、复审计划]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ATAM 的核心红利：把"凭感觉评审"变成有清单、有 Owner、有 Deadline、有验证机制的工程过程。评审结果任何人在任何时候都能复现。
# 5. 风险风暴工作坊
# 5.1 风险风暴流程
疑惑：ATAM 太重了，2~3 天搞不动；有没有更轻的方法？
论证：风险风暴（Risk Storming） 是 Simon Brown（C4 模型作者）推广的轻量级架构评审法——半天到一天搞定，特别适合中小型团队。
核心思想：全员参与、便利贴投票、可视化风险地图——把"少数人评审"变成"集体智慧"。
风险风暴标准流程：
┌─────────────────────────────────────────────────────────┐
│ 风险风暴工作坊 (Risk Storming) │
├─────────────────────────────────────────────────────────┤
│ │
│ 准备 (评审前 1 周) │
│ ┌──────────────────────────────────────────┐ │
│ │ - 架构师准备架构图 (C4 model 三层) │ │
│ │ - 打印大图,贴墙上 (A1+ 大小) │ │
│ │ - 准备 4 色便利贴 │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ 风暴 Round 1 (15 分钟,独立思考) │
│ ┌──────────────────────────────────────────┐ │
│ │ - 每人发一叠便利贴 │ │
│ │ - 独立看图,在每个组件上贴风险便利贴 │ │
│ │ - 不讨论!不交流! │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ 汇总 (15 分钟) │
│ ┌──────────────────────────────────────────┐ │
│ │ - 每人轮流讲自己贴的风险 │ │
│ │ - 主持人合并重复风险 │ │
│ │ - 形成风险墙 │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ 风暴 Round 2 (15 分钟,二轮讨论) │
│ ┌──────────────────────────────────────────┐ │
│ │ - 听了第一轮后,看是否有新风险 │ │
│ │ - 补充贴上 │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ 打分 + 排序 (30 分钟) │
│ ┌──────────────────────────────────────────┐ │
│ │ - 每个风险打分 (概率 × 影响 = 严重度) │ │
│ │ - 排序进风险矩阵 │ │
│ │ - Top N 必须出缓解方案 │ │
│ └──────────────────────────────────────────┘ │
│ ↓ │
│ 缓解方案 (30 分钟) │
│ ┌──────────────────────────────────────────┐ │
│ │ - Top 风险逐个讨论缓解方案 │ │
│ │ - 指派 Owner + Deadline │ │
│ │ - 形成行动清单 │ │
│ └──────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
总时长: 2~3 小时
人员: 8~15 人 (太多会乱,太少不够多视角)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# 5.2 四色便利贴法
风险风暴推荐四色便利贴——颜色对应风险严重度：
┌─────────────────────────────────────────────────────────┐
│ 颜色 含义 判定 │
├─────────────────────────────────────────────────────────┤
│ 🔴 红色 高风险 极大概率发生 + 极大影响 │
│ (Critical) 例: 单点故障、数据丢失 │
│ │
│ 🟠 橙色 中高风险 较大概率发生 + 较大影响 │
│ (High) 例: 性能瓶颈、运维复杂 │
│ │
│ 🟡 黄色 中风险 小概率发生 / 中等影响 │
│ (Medium) 例: 监控告警延迟 │
│ │
│ 🟢 绿色 低风险/已识别 已有缓解措施 │
│ (Low/Mitigated) 例: Nginx 双活成熟方案 │
└─────────────────────────────────────────────────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
操作示例——对第 1 章的订单履约系统：
┌──────────────────────────────────────────────┐
│ 订单履约系统架构图 │
│ │
│ [Web] [API GW] [Order Svc] │
│ 🔴(攻击) 🟠(限流) 🔴(死锁) │
│ │
│ [Redis Cluster] [PostgreSQL Primary] │
│ 🔴(击穿) 🔴(故障切换 30s) │
│ │
│ [Payment Adapter] [MQ] │
│ 🟡(超时) 🟠(消息堆积) │
│ │
│ [PostgreSQL Slave x3] │
│ 🟢(已有备份方案) │
└──────────────────────────────────────────────┘
红色 4 个、橙色 3 个、黄色 1 个、绿色 1 个
→ 风险高度集中在数据层 + 订单服务核心
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
这种可视化的力量：评审完一眼就能看到风险分布——架构师再也不能说"看起来挺合理"，红色满墙就是事实。
# 5.3 风险矩阵打分
打分用概率 × 影响二维矩阵：
影响 (Impact)
▲
灾难性 │ H │ H │ C │ C │ C │
│ ───┼───┼───┼───┼───│
重 │ M │ H │ H │ C │ C │
│ ───┼───┼───┼───┼───│
中 │ L │ M │ H │ H │ C │
│ ───┼───┼───┼───┼───│
轻 │ L │ L │ M │ H │ H │
│ ───┼───┼───┼───┼───│
可忽略 │ L │ L │ L │ M │ H │
└────┴───┴───┴───┴───┘─►
很低 低 中 高 很高 概率 (Probability)
C = Critical (必须立即解决)
H = High (上线前必须解决)
M = Medium (上线后 1 个月内解决)
L = Low (持续监控)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
打分规则：
概率 (Probability) 1~5 分:
1 = 几乎不发生 (历史从未出现)
2 = 罕见 (年度可能 1 次)
3 = 偶发 (月度可能 1 次)
4 = 常见 (周度可能 1 次)
5 = 频繁 (日常发生)
影响 (Impact) 1~5 分:
1 = 可忽略 (用户无感)
2 = 轻微 (少数用户受影响)
3 = 中等 (业务部分中断 < 1 小时)
4 = 严重 (业务大面积中断 1~24 小时)
5 = 灾难 (业务完全中断 > 24 小时 / 数据丢失 / 法律风险)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
第 1 章案例的打分：
| 风险 | 概率 | 影响 | 严重度 |
|---|---|---|---|
| 大促 QPS 超 5000 | 5 (一定发生) | 5 (业务中断) | Critical |
| 退款死锁 | 4 (常见) | 4 (订单错乱) | Critical |
| Redis 击穿 | 4 | 5 | Critical |
| 越权访问 | 3 | 5 (数据泄漏+法律) | Critical |
| 主备切换慢 | 3 | 3 | High |
| DB 不可回滚 | 2 (大改才有) | 5 (灾难) | High |
6 个 Critical/High 风险——评审会不可能"通过"——但当初的评审 0 个被识别。
# 5.4 缓解方案产出
每个 Critical/High 风险必须出缓解方案，三要素：
缓解方案三要素:
1. 措施 (What): 做什么
2. Owner (Who): 谁负责
3. Deadline (When): 什么时候完成
可选第四要素:
4. 验证方式 (How to verify): 怎么知道做到了
1
2
3
4
5
6
7
2
3
4
5
6
7
举例——大促 QPS 风险的缓解：
风险 R1: 大促零点 QPS 可能冲到 10000+,当前压测仅 5000
严重度: Critical
缓解方案:
┌────┬──────────────────────────────┬────────┬────────────┐
│ # │ 措施 │ Owner │ Deadline │
├────┼──────────────────────────────┼────────┼────────────┤
│ 1 │ 双 11 全链路压测,目标 15000 │ 性能组 │ 大促前 4 周 │
│ 2 │ 读多写少接口加 Redis 缓存 │ 老王 │ 大促前 3 周 │
│ 3 │ DB 连接池调到 500 │ DBA │ 大促前 2 周 │
│ 4 │ 限流降级方案 (Sentinel) │ 老李 │ 大促前 2 周 │
│ 5 │ 大促 War Room 24h 值班 │ 整组 │ 大促当天 │
└────┴──────────────────────────────┴────────┴────────────┘
验证方式: 压测报告 + 灰度数据 + 大促当晚监控
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
风险跟踪表——评审结束第一时间录入项目管理系统（Jira/Tapd/Asana），每周复盘：
评审日期: 2025-06-01
系统名称: 订单履约系统 v2.0
评审方法: 风险风暴
| ID | 风险描述 | 严重度 | Owner | Deadline | 状态 |
|-----|-------------------|----------|--------|------------|-----------|
| R1 | 大促 QPS 超限 | Critical | 老王 | 2025-10-15 | 进行中 |
| R2 | 退款死锁 | Critical | 老李 | 2025-07-01 | 已解决 |
| R3 | Redis 击穿 | Critical | 老张 | 2025-07-15 | 待开始 |
| R4 | 越权访问 | Critical | 安全组 | 2025-06-30 | 待开始 |
| R5 | 主备切换慢 | High | DBA | 2025-08-01 | 待开始 |
| R6 | DB 不可回滚 | High | 老李 | 2025-09-01 | 设计中 |
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
红线：风险跟踪表必须每周更新、必须有 owner、必须有 deadline——只有清单没人跟进 = 第 1 章悲剧重演。
# 6. 架构决策记录
# 6.1 ADR的本质
疑惑：评审通过了——三个月后新人加入，问"为啥用 PostgreSQL 不用 MySQL"——谁还记得？
论证：架构决策的最大成本不在做决策本身，而在维护决策。
项目时间线
T0 评审通过,选 PostgreSQL ← 当时讨论了 8 个原因,决策很扎实
T3 老李离职 ← 决策知识只在他脑子里
T6 新架构师小王上任 ← 不知道当初为啥选 PG
T9 小王想换 MySQL ← 重新评审又花 2 周
T12 换成 MySQL ← 发现 PG 的某个特性是核心依赖,踩了大坑
T15 又想换回 PG ← 浪费 9 个月
1
2
3
4
5
6
7
2
3
4
5
6
7
根因：决策只在脑子里 → 决策无法传承 → 每次新人来都要重新评审。
结论：所有架构决策必须沉淀为 ADR（Architecture Decision Record）。
ADR 不是文档,是架构的基因。
没 ADR 的系统三年后没人敢动。
有 ADR 的系统五年后还能演进。
1
2
3
2
3
ADR 解决三个问题：
- 保留 Why——不只记录"用了 X"，而是"为什么用 X、当时考虑了什么备选、为什么不选 Y"
- 保留 Context——当时的业务背景、约束、技术成熟度
- 保留 Consequences——这个决策的代价、潜在风险、何时需要重新评估
# 6.2 ADR模板与示例
标准 ADR 模板（Michael Nygard 2011 版，业界事实标准）：
# ADR-0001: 选用 PostgreSQL 作为订单数据库
## 状态 (Status)
已接受 (Accepted) / 已废弃 (Deprecated) / 已被取代 (Superseded by ADR-XXXX)
## 日期
2025-06-01
## 决策者
- 架构师: 老李
- 评审者: CTO、DBA、运维总监
## 背景 (Context)
- 业务: 新订单系统替换祖传单体
- 业务量: 当前 1000 QPS, 预计 1 年内 10000 QPS
- 数据规模: 单表 1 亿行
- 关键需求: 强一致性 (订单不能错乱)、复杂查询 (报表)
- 团队背景: 有 1 名 DBA 熟悉 PostgreSQL,3 人用过 MySQL
## 决策 (Decision)
选用 PostgreSQL 14 作为订单服务的主数据库
## 备选方案 (Alternatives Considered)
1. MySQL 8.0
+ 团队更熟悉
+ 生态丰富
- JSON 支持不如 PG
- 复杂查询优化器较弱
2. TiDB
+ 天然分布式
+ MySQL 协议兼容
- 团队从未用过,运维风险高
- 资源成本是 PG 的 3 倍
3. MongoDB
+ 灵活 schema
- 强一致性弱 (订单场景不合适)
## 决策理由 (Rationale)
- 强一致性场景 PG 比 MySQL InnoDB 更可靠 (MVCC 设计)
- 复杂报表查询 PG 的优化器明显优于 MySQL
- 有现成 DBA 支持,运维风险可控
- 业界成熟方案,生态完整
## 后果 (Consequences)
正面:
- 强一致性、复杂查询能力满足
- 未来扩展性好 (Citus 分片可选)
负面:
- 多数开发不熟悉 PG,学习成本高
- 部分 MySQL 工具链不可用 (如 binlog 同步工具)
- 缓解: 内部 PG 培训 + 工具替代方案
需要监控:
- 单库 QPS 上限 (敏感点 S1)
- 主备切换时间 (风险 R5)
## 何时重新评估
- 业务量超过 50000 QPS 时
- 团队 PG 经验不足导致事故 3 次以上时
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
ADR 命名规范：
ADR-0001-选用-postgresql.md
ADR-0002-采用-cqrs-读写分离.md
ADR-0003-使用-kafka-作为事件总线.md
...
1
2
3
4
2
3
4
按编号递增，永不删除——已废弃的 ADR 标记 Status，新 ADR 在"被取代"字段引用旧 ADR。
# 6.3 决策的演化
ADR 是活的文档——决策会随业务/技术演化。
状态机：
┌─────────┐
│ Proposed│ ← 提议中(评审前)
└────┬────┘
│ 评审通过
▼
┌─────────┐
│ Accepted│ ← 已接受(生效中)
└────┬────┘
│
├─→ 业务变化 → ┌────────────┐
│ │ Superseded │ ← 已被 ADR-XXXX 取代
│ └────────────┘
│
└─→ 技术淘汰 → ┌────────────┐
│ Deprecated │ ← 已废弃(不再适用)
└────────────┘
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
取代关系示例：
# ADR-0015: 用 Kafka 替换 RabbitMQ 作为事件总线
## 状态
已接受 (Accepted)
## 取代
ADR-0003 (使用 RabbitMQ) → 状态变更为 Superseded by ADR-0015
## 背景
...业务量从 1000 EPS 涨到 50000 EPS,RabbitMQ 集群吃力...
## 决策
迁移到 Kafka
## 代价
- 12 周迁移工作量
- 双写过渡期 4 周
- 部分 ADR-0003 中的设计假设需要重新评估
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
关键纪律：老 ADR 不删除——保留历史决策的全部上下文，是团队最珍贵的知识资产。
# 6.4 ADR与代码联动
ADR 不进代码 = 贫血文档——再好的 ADR 不与代码联动也会过期。
联动机制：
机制 1 · ADR 放进代码仓库
project-root/
├── docs/
│ └── adr/
│ ├── 0001-选用-postgresql.md
│ ├── 0002-采用-cqrs.md
│ └── 0003-使用-kafka.md
├── src/
└── README.md
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
机制 2 · 代码引用 ADR
/**
* 订单服务核心实现
*
* 设计依据:
* - ADR-0001: 数据库选型 (PostgreSQL)
* - ADR-0002: CQRS 读写分离
* - ADR-0008: 订单聚合根边界
*/
@Service
public class OrderService {
...
}
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
机制 3 · PR 模板引用 ADR
## PR 描述
新增退款流程
## 影响的 ADR
- 涉及 ADR-0002 (CQRS): 退款走异步投影,符合现有 ADR
- 涉及 ADR-0005 (Saga): 跨服务事务用 Saga 编排
## 是否引入新决策
- [ ] 否
- [x] 是 → 已新增 ADR-0016 (退款冲正策略)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
机制 4 · ADR review 进入季度复盘
每季度 ADR review 会议:
- 哪些 Accepted ADR 仍然有效?
- 哪些假设已不成立(业务变化/技术变化)?
- 是否需要新建 ADR 替代旧的?
- 是否需要将 ADR 状态改为 Deprecated?
1
2
3
4
5
2
3
4
5
ADR 工具推荐：
| 工具 | 特点 |
|---|---|
adr-tools (bash) | 极简 CLI，命令式创建 ADR |
| Log4brains | 静态站点生成，可视化 ADR 关系 |
| Markdown + Git | 最简单，进代码仓库 |
| Confluence/Wiki | 适合非技术人员协作 |
红线：ADR 不在代码仓库的、不能链接到代码的、半年不 review 的 → 等同于不存在。
# 7. 评审检查清单
# 7.1 可用性清单
疑惑：ATAM 和风险风暴都需要专业评委——有没有"小白也能上手"的工具？
论证：检查清单（Checklist） 是评审工程化的最后一公里——把"老专家的隐性知识"显性化为可逐条核对的清单。
可用性检查清单（Availability Checklist）：
□ 单点故障识别
□ 是否识别出所有 SPOF (单点故障)?
□ 每个 SPOF 是否有冗余方案?
□ 数据库主备?LB 双活?Cache 集群?
□ 故障切换
□ 主备切换时间 ≤ ? 秒
□ 切换是否自动 (无人工干预)?
□ 切换是否有数据丢失 (RPO)?
□ 是否定期演练?(混沌工程)
□ 容灾设计
□ 同城双机房?异地灾备?
□ RTO (恢复时间目标) = ?
□ RPO (恢复点目标) = ?
□ 灾备切换演练频率 = ?
□ 限流降级
□ 关键接口是否有限流?
□ 限流策略 (QPS/并发/令牌桶)?
□ 降级方案 (熔断/默认值/排队)?
□ 是否压测过限流生效?
□ 监控告警
□ 核心指标是否监控? (QPS/延迟/错误率)
□ 告警是否分级? (P0/P1/P2)
□ 告警是否值班响应?
□ 告警噪音是否可控? (< 10 条/天)
□ 灾难预案
□ 是否有应急手册?
□ 是否有回滚预案?
□ 是否有数据恢复预案?
□ 关键人是否 24h 可联系?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 7.2 性能与扩展清单
□ 性能基线
□ 是否做了压测?
□ 压测覆盖了所有关键接口?
□ 压测场景包含峰值场景? (平峰/大促/双 11)
□ 压测数据量与生产一致?
□ 性能指标
□ P50/P95/P99 延迟分别 ≤ ?
□ 吞吐量 (QPS/TPS) ≥ ?
□ 资源利用率 (CPU/MEM/IO) ≤ ?
□ 数据库连接池利用率 ≤ ?
□ 缓存设计
□ 哪些数据缓存?
□ 缓存击穿防护? (互斥锁/逻辑过期)
□ 缓存雪崩防护? (过期时间打散)
□ 缓存穿透防护? (布隆过滤器/空值缓存)
□ 缓存一致性策略? (Cache Aside/Write Through)
□ 数据库性能
□ 关键 SQL 是否走索引?
□ 慢查询监控?
□ 分库分表方案?
□ 读写分离方案?
□ 大事务避免?
□ 水平扩展
□ 服务是否无状态?
□ Session 怎么处理?
□ 文件存储是否分布式?
□ 是否支持动态扩容?
□ 扩容是否需要重启?
□ 异步与解耦
□ 是否识别可异步处理的逻辑?
□ MQ 选型与可靠性?
□ MQ 消息堆积应对?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# 7.3 安全与合规清单
□ 身份认证
□ 认证机制? (OAuth2/JWT/Session)
□ 密码存储? (bcrypt/argon2 + salt)
□ 多因素认证? (短信/邮件/TOTP)
□ 第三方登录?
□ 权限控制
□ 权限模型? (RBAC/ABAC)
□ 接口级权限校验?
□ 数据级权限 (行级)?
□ 越权防护? (横向越权/纵向越权)
□ 数据安全
□ 敏感数据加密存储?
□ 传输加密 (HTTPS/TLS 1.3)?
□ 密钥管理 (KMS/HSM)?
□ 数据脱敏 (日志/接口返回)?
□ 输入验证
□ SQL 注入防护? (参数化查询)
□ XSS 防护? (输出转义)
□ CSRF 防护? (Token)
□ 文件上传校验? (类型/大小/内容)
□ 审计日志
□ 关键操作日志?
□ 日志不可篡改 (WORM)?
□ 日志保留时长 (≥ 6 个月)?
□ 日志接入 SIEM?
□ 合规要求
□ GDPR / CCPA 等地区合规?
□ 等保 2.0 / ISO 27001?
□ 数据出境合规?
□ 用户数据删除权 (Right to be Forgotten)?
□ 安全攻防
□ DDoS 防护?
□ WAF 接入?
□ 漏洞扫描频率?
□ 红蓝对抗?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# 7.4 可维护性清单
□ 代码质量
□ 单元测试覆盖率 ≥ ?
□ 集成测试覆盖率?
□ 代码静态分析 (SonarQube)?
□ 代码评审流程?
□ 文档完整性
□ README 完整?
□ API 文档 (OpenAPI/Swagger)?
□ ADR 完整?
□ 部署手册?
□ 运维手册?
□ 可观测性
□ 日志结构化?
□ 分布式追踪 (Tracing)?
□ Metrics 上报?
□ APM 工具接入?
□ DevOps
□ CI/CD 流水线?
□ 自动化测试?
□ 自动化部署?
□ 灰度发布?
□ 蓝绿部署?
□ 配置管理
□ 配置外置 (12 Factor)?
□ 配置中心 (Apollo/Nacos)?
□ 密钥外置 (Vault)?
□ 环境隔离 (dev/test/prod)?
□ 技术债务
□ 技术债务清单?
□ 偿还节奏 (每迭代 20%)?
□ 高风险债务优先?
□ 团队赋能
□ 新人 onboarding 文档?
□ 关键模块有 2+ 人熟悉 (避免知识孤岛)?
□ 定期技术分享?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Checklist 使用纪律：
1. 不漏项: 每项都要明确回答 (是/否/N/A)
2. 不打哈哈: "是"必须有证据 (压测报告/代码链接)
3. 不通过 N/A 逃避: "N/A"必须给出理由
4. 评审记录归档: 每次评审存档,可追溯
1
2
3
4
2
3
4
Checklist 不是教条——根据业务特点裁剪：
- 金融业务：安全清单加倍
- 实时业务：性能清单加倍
- 创业项目：可维护性清单可放宽（先活下来再说）
# 8. 评审反模式
# 8.1 走过场评审
症状：
14:00 开会, 14:05 PPT 翻完, 14:10 "我没问题",
14:15 "通过, 散会" — 全程 15 分钟。
或者:
评委: "看起来挺合理的"
评委: "我没什么问题"
评委: "+1 通过"
1
2
3
4
5
6
7
2
3
4
5
6
7
根因：
- 没有结构化议程 → 评委不知道该问什么
- 没有量化标准 → "看起来合理"就过
- 没有压力机制 → 评审错了没人担责
- 评委缺乏专业能力 → 没能力提问
修复：
强制约束:
1. 评审前 1 周必须发出材料 (评委有时间预习)
2. 评审会上必须按 ATAM/风险风暴流程
3. 必须产出风险清单 (≥ 5 条,否则视为评审不充分)
4. 必须有评委签字 + 错误时担责机制
1
2
3
4
5
2
3
4
5
红线：评审记录 0 条风险 = 评审无效——架构不可能完美，0 风险只能说明"评审没做"。
# 8.2 一言堂评审
症状：
CTO: "我觉得用 Kafka"
其他人: 沉默
CTO: "那就 Kafka 了"
或:
评审会上 5 个评委,只有 CTO 说话,
其他人只是陪坐,会议变成 CTO 一对一辅导架构师。
1
2
3
4
5
6
7
2
3
4
5
6
7
根因：
- 权威效应 → 资历低的不敢挑战
- 评委组成不平衡 → 缺乏多视角
- 主持人不专业 → 没引导其他人发言
修复：
治理措施:
1. CTO/最高决策者 最后发言 (避免锚定)
2. 评委必须包含 业务/技术/安全/运维 多角色
3. 主持人 (非架构师) 强制轮流发言
4. 匿名风险提交渠道 (会前/会后)
5. 反对意见必须记录 (即使没采纳)
1
2
3
4
5
6
2
3
4
5
6
关键工具：罗伯特议事规则——保证少数派意见也能被听到。
# 8.3 完美主义评审
症状：
评委 A: "这里应该用六边形架构"
评委 B: "应该用 DDD 战略设计"
评委 C: "应该上 Service Mesh"
评委 D: "应该用 Event Sourcing"
...
评审 4 小时,提出 50 个"应该",架构师崩溃,3 个月推不进度。
1
2
3
4
5
6
2
3
4
5
6
根因：
- 评委没有"业务紧迫性"概念
- 评委不区分 must-have / nice-to-have
- 评委想秀技术储备
修复：
治理措施:
1. 每个建议必须标注 必须/应该/可选 三级
2. 总改动量超过 30% → 视为否决方案 (重新设计)
3. 评委提建议必须给"为什么现在做"的论证
4. 业务方一票否决 (业务等不起的不做)
5. 区分"评审版本一"和"未来演进":
- 一期: 满足 must-have
- 二期: nice-to-have
- 长期: 演进方向
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
铁律：完美架构 = 没上线的架构。架构是演进出来的，不是评审出来的。
# 8.4 评审不闭环
症状：
评审会上识别了 20 个风险
3 个月后上线
事故复盘时发现:
- 17 个风险根本没人跟进
- 2 个风险记错了 owner
- 1 个风险标注"已解决",实际没解决
1
2
3
4
5
6
2
3
4
5
6
根因：
- 评审记录没进项目管理系统
- 没有定期 review 风险跟踪表
- Owner 不明确或被借调
- Deadline 没人卡
修复：
闭环机制:
1. 评审结束当天,风险清单导入 Jira (每条 = 一个 ticket)
2. 每周项目周会必须 review 风险跟踪表
3. 每个风险有明确 Owner + Deadline
4. 风险解决必须有"验证证据" (压测/代码/ADR)
5. 风险未解决前禁止上线 (Critical/High 风险)
6. 上线后 30/60/90 天复盘风险是否真的解决
1
2
3
4
5
6
7
2
3
4
5
6
7
度量指标：
评审有效性 = 已闭环风险数 / 总识别风险数
评审及时性 = 按时解决的风险数 / 总风险数
评审准确性 = (识别风险数 - 漏掉的事故数) / 识别风险数
健康水平:
评审有效性 ≥ 80%
评审及时性 ≥ 70%
评审准确性 ≥ 90% (漏掉的事故 < 10%)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
评审反模式集锦：
| 反模式 | 症状 | 修复 |
|---|---|---|
| 走过场 | 15 分钟通过 | 强制流程 + 担责机制 |
| 一言堂 | CTO 独白 | 多角色评委 + 主持人引导 |
| 完美主义 | 提 50 个改进 | must/should/may 分级 |
| 不闭环 | 风险没人跟 | 入项管 + 周 review |
| 形式主义 | 模板填满即过 | 必须给证据 |
| 滞后评审 | 上线后才评审 | 设计阶段就评审 |
# 9. 评审实战流程
# 9.1 评审前准备
疑惑：理论都懂，到底一次评审从准备到收尾完整怎么做？
论证：评审 ≠ 一个会议——是一个前-中-后的完整流程。
评审前准备清单（评审日前 1~2 周）：
□ 1. 确定评审类型
□ 立项评审 (要不要做)
□ 方案评审 (怎么做)
□ 上线前评审 (能不能上)
□ 复盘评审 (做的怎么样)
□ 2. 准备材料 (架构师)
□ 业务背景文档
□ 架构方案 (C4 model 4 层视图)
□ 关键决策 (草拟 ADR)
□ 已识别风险清单
□ 压测/POC 数据
□ 3. 确定评委 (评审组织者)
□ 必须包含: 技术/业务/安全/运维
□ 必须包含: 1 名熟悉本领域的资深架构师
□ 必须包含: 1 名业务方代表
□ 评委人数: 5~10 (太多决策慢,太少视角缺)
□ 4. 发送材料 (评审日前 1 周)
□ 材料 + 议程 + 评审方法
□ 要求评委提前阅读 + 提交初步问题
□ 5. 准备物料
□ 大会议室 + 投影 + 白板
□ 便利贴 (若用风险风暴)
□ 录音/录像设备 (可选)
□ 评审报告模板
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# 9.2 评审中流程
典型评审议程（2~3 小时版）：
00:00 - 00:10 开场 (主持人)
- 介绍评审目的、议程、规则
- 强调"挖风险 > 通过"的目标
00:10 - 00:40 方案介绍 (架构师)
- 业务背景 (5 分钟)
- 架构方案 (15 分钟)
- 关键决策 (5 分钟)
- 已识别风险 (5 分钟)
00:40 - 01:10 质量属性场景 review (评委 + 架构师)
- 关键场景是否覆盖?
- Measure 是否合理?
- 优先级是否合理?
01:10 - 02:10 风险风暴 / ATAM 分析 (全员)
- 按 Checklist 逐项核对
- 全员贴风险便利贴 (15 分钟)
- 汇总 + 讨论 (45 分钟)
02:10 - 02:40 缓解方案 (全员)
- Critical/High 风险逐个出方案
- 指派 Owner + Deadline
02:40 - 03:00 结论 + 行动项 (主持人)
- 通过 / 有条件通过 / 不通过
- 行动项清单
- 下次复审日期
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
评审中纪律：
1. 主持人控场 (非架构师)
2. 时间盒严格 (每段超时强制截断)
3. 离题讨论记到 parking lot
4. 反对意见必须记录
5. 决策必须当场达成共识 (实在不行投票)
6. 所有产出物当场拍照/录入
1
2
3
4
5
6
2
3
4
5
6
# 9.3 评审后跟进
□ 评审当天 (D+0)
□ 评审报告初稿出炉
□ 风险清单导入项目管理系统
□ ADR 草稿入仓
□ 评审后 1 天 (D+1)
□ 评审报告发出 (评委确认)
□ 风险 Owner 确认接收
□ 评审后 1 周 (D+7)
□ 风险跟踪首次 review
□ 阻塞性风险升级
□ 评审后每周 (D+7,14,21,...)
□ 风险跟踪 review
□ 状态更新 + 升级
□ 上线前 (D+M)
□ Critical/High 风险闭环确认
□ 上线前架构 review (轻量)
□ 上线后 30 天 (D+M+30)
□ 评审有效性复盘
□ 漏掉的事故 → 加入下次 Checklist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 9.4 不同阶段的评审
不同项目阶段的评审侧重不同：
| 阶段 | 评审重点 | 方法 | 时长 |
|---|---|---|---|
| 立项阶段 | 要不要做、ROI | ROI 分析 + 备选方案 | 1~2 小时 |
| 方案阶段 | 怎么做、技术选型 | ATAM + 风险风暴 | 半天~3 天 |
| 详细设计 | 关键接口、数据模型 | Checklist + ADR | 2~3 小时 |
| 编码阶段 | Code Review | PR Review + Checklist | 持续 |
| 上线前 | 应急预案、回滚 | 风险风暴 + 演练 | 2~3 小时 |
| 上线后 | 复盘 | 事后分析 (Postmortem) | 1~2 小时 |
| 季度 review | 架构演进 | ADR 复盘 + 现状评估 | 半天 |
关键纪律：评审越早成本越低——立项阶段一句话能改的方向，上线后可能要重做半年。
评审成本 vs 修复成本 曲线:
成本 (¥)
│
高 │ ╱
│ ╱
│ ╱
中 │ ╱
│ ╱
│ ╱
低 │ ╱
│ ╱
│ ╱
└────────────────────────────────────► 阶段
立项 方案 设计 编码 测试 上线 生产
修复成本: 立项时 1¥ → 生产时 1000¥
评审收益: 立项评审 = 投入产出比最高
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 10. 综合案例串讲
# 10.1 案例真相揭晓
回到第 1 章的 25 人团队"评审 2 小时通过、上线 60 天事故连发"事故，七个疑问现在能逐条作答：
| 疑问 | 答案 |
|---|---|
| ① 架构评审到底要评什么? | 第 2：五要素——场景、方案、方法、决策、闭环——缺一不可 |
| ② 业务方诉求如何量化? | 第 3：质量属性场景六元组 + 优先级九宫格 |
| ③ 如何系统化挖风险? | 第 4：ATAM 九步流程 + 效用树 + 敏感点/权衡点 |
| ④ 如何让所有人贡献风险? | 第 5：风险风暴 + 四色便利贴 + 风险矩阵 |
| ⑤ 决策如何沉淀? | 第 6：ADR 模板 + 与代码联动 |
| ⑥ 不漏关键维度怎么办? | 第 7：四大 Checklist（可用性/性能/安全/可维护性） |
| ⑦ 评审反模式怎么识别? | 第 8：走过场/一言堂/完美主义/不闭环四大病 |
修复方案（按代价从小到大）：
方案 A · 引入 Checklist（最轻、立即可做）
立刻动作:
- 把可用性/性能/安全/可维护性四大 Checklist 制度化
- 每次评审必须逐项核对
- 评审记录归档,可追溯
代价: 1 周准备模板,0 额外成本
收益: 评审完整性提升 80%,基础风险 100% 覆盖
适用: 团队 < 30 人,无专业架构组
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
方案 B · 引入风险风暴（中等代价）
立刻动作:
- 中等及以上项目强制风险风暴 (2~3 小时)
- 全员参与,四色便利贴 + 风险矩阵
- 风险跟踪表入项管,周复盘
代价: 每次评审多 2~3 小时,需要培训主持人
收益: 风险识别量提升 5~10 倍,集体智慧落地
适用: 团队 30~100 人,有项目管理流程
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
方案 C · 全面引入 ATAM + ADR（最重、最系统）
立刻动作:
- 核心系统强制 ATAM 评审 (2~3 天)
- 所有关键决策强制 ADR (放入代码仓库)
- 季度 ADR review + 风险 review
- 建立架构评审委员会 (ARB)
代价: 需要专业架构师 1~2 人主导,前期 3~6 个月磨合
收益: 评审有效性 ≥ 90%,事故率下降 70%+
适用: 团队 > 100 人,有专业架构组,业务复杂度高
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
生产建议：方案 A 立刻做（成本低收益快），方案 B 排到下季度（系统性升级），方案 C 视团队规模（最规范但需要专人）。三方案叠加 = 真正解决问题。
第 1 章案例修复后：
原评审:
- 2 小时, 8 评委, 0 风险记录, 60 天事故 4 起
修复后评审 (引入方案 A + B):
- Day 1 (上午): 方案介绍 + Checklist 自查 (3 小时)
- Day 1 (下午): 风险风暴 + 缓解方案 (3 小时)
- 产出: 32 个风险,其中 8 个 Critical/High
- 上线前 30 天: 8 个 Critical/High 全部闭环
- 上线后 90 天: 0 起 P0 事故,2 起 P1 事故 (已识别风险)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
# 10.2 一次完整评审全过程
把"从立项到复盘"的全过程串成一棵知识树：
决策"启动 XXX 系统建设"
│
├─ 立项评审 (D-90)
│ ├─ ROI 分析 — 业务价值 vs 投入
│ ├─ 高层 sponsor 确认
│ ├─ 备选方案对比 (新建/改造/采购)
│ └─ ADR-0000 立项决策
│
├─ 方案评审 (D-60)
│ ├─ 质量属性场景 (第 3 章)
│ │ ├─ 业务方写诉求
│ │ ├─ 架构师转六元组
│ │ ├─ 九宫格定优先级
│ │ └─ 评委质检场景
│ │
│ ├─ 架构方案设计 (引用 02~06 系列)
│ │ ├─ 六边形架构 (02 篇)
│ │ ├─ CQRS 读写分离 (03 篇)
│ │ ├─ 事件驱动 (04 篇)
│ │ ├─ 微服务拆分 (05 篇)
│ │ └─ DDD 战略 (06 篇)
│ │
│ ├─ ATAM 评审 (第 4 章)
│ │ ├─ 效用树构建
│ │ ├─ 高优场景分析
│ │ ├─ 敏感点/权衡点识别
│ │ └─ 风险/非风险清单
│ │
│ ├─ 风险风暴 (第 5 章)
│ │ ├─ 全员便利贴
│ │ ├─ 风险矩阵打分
│ │ └─ 缓解方案
│ │
│ └─ ADR 沉淀 (第 6 章)
│ ├─ 关键决策 → ADR-0001~N
│ ├─ 备选方案 + 理由
│ └─ 进入代码仓库
│
├─ 详细设计评审 (D-30)
│ ├─ 接口设计 review
│ ├─ 数据模型 review
│ └─ Checklist 核对 (第 7 章)
│
├─ 编码阶段 (D-30 ~ D-7)
│ ├─ Code Review (PR 引用 ADR)
│ ├─ 持续 Checklist 自查
│ └─ 风险周 review
│
├─ 上线前评审 (D-7)
│ ├─ Critical/High 风险闭环确认
│ ├─ 应急预案 review
│ ├─ 回滚方案演练
│ └─ 上线决策 (Go/No-Go)
│
├─ 上线 (D-Day)
│ ├─ 灰度发布
│ ├─ 监控密集观察
│ └─ War Room 值班
│
└─ 复盘评审 (D+30, D+90)
├─ 风险有效性复盘
├─ 漏掉的事故 → 加入 Checklist
├─ ADR 是否仍有效
└─ 下一次架构 review 计划
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
理解一次完整评审的全过程，就是理解为什么架构评审是一种长期实践，不是一次性会议。每次评审都应该让团队的架构能力更强一分。
# 10.3 设计哲学回扣
整理本篇的四条跨方法论适用的设计哲学：
哲学 1：场景即标准——没量化的需求不算需求
最深刻的认知："系统要快、要稳、要安全"不是需求，是诉求。真正的需求必须是可测量、可验证、可证伪的——"P99 < 300ms"才是需求。架构评审的第一关，是把模糊诉求逼成清晰场景。这条哲学不止用于架构——延伸到任何工程实践：需求评审、产品设计、绩效考核，没量化标准的事情都是耍流氓。
哲学 2：方法即纪律——把经验依赖变成流程依赖
ATAM、风险风暴、Checklist 这些方法的本质不是"更聪明"，而是让普通人也能挖出专家级风险。专家凭经验问"你考虑过 Redis 击穿吗"，方法论让新评委也会按 Checklist 逐条核对"缓存击穿防护是什么"。方法论是团队能力的杠杆——一份 Checklist 比十个老专家更可持续。这条哲学是"工程化"的灵魂：把隐性知识显性化、把个人能力组织化。
哲学 3：决策即资产——ADR 是架构的基因
代码会改、人会走、技术会换——只有决策的 Why 不会过期。一份好的 ADR 让 3 年后的新人能立刻理解"为什么当初选 PostgreSQL"，从而避免重复评审、避免错误推翻。没 ADR 的系统三年后没人敢动——所有人都怕踩到"不知道为啥这么写"的坑，最终系统僵化等死。这条哲学的延伸：任何团队的核心资产都不是代码，是决策记录。
哲学 4：闭环即生命——没跟进的评审等于没评审
识别 30 个风险却只解决 2 个——剩下 28 个一定会变成事故。评审不是终点，是起点——风险跟踪、ADR review、季度复盘构成完整闭环。评审的价值 = 闭环率 × 识别量——闭环率 = 0 时，识别再多风险也是 0 价值。这条哲学的本质：任何工程实践的成功，都靠最后那 10% 的执行力。架构师的最高境界不是设计好图，是推动团队真的把图落地。
# 10.4 评审方法论速查
一张图保存以备查：
| 方法 | 适用场景 | 时长 | 产出物 | 难度 |
|---|---|---|---|---|
| 质量属性场景 | 所有评审第一步 | 1~2 小时 | 场景六元组清单 | ⭐⭐ |
| ATAM | 核心系统、复杂业务 | 2~3 天 | 效用树 + 风险/权衡/敏感点 | ⭐⭐⭐⭐⭐ |
| 风险风暴 | 中型系统、快速评审 | 2~3 小时 | 风险矩阵 + 缓解方案 | ⭐⭐⭐ |
| ADR | 所有关键决策 | 持续 | 决策记录文档 | ⭐⭐ |
| Checklist | 所有评审兜底 | 1~2 小时 | 核对报告 | ⭐ |
评审方法选择决策树：
开始架构评审
│
▼
项目复杂度?
/ \
低 中/高
↓ ↓
Checklist 系统是否核心?
↓ / \
产出报告 否 是
↓ ↓
风险风暴 ATAM 全流程
(半天) (2~3 天)
↓ ↓
风险清单 效用树+风险/权衡
│ │
└──────┬─────┘
↓
所有决策入 ADR
↓
入项管跟踪
↓
每周 review 闭环
↓
上线前 Critical/High 必清
↓
上线后 30/90 天复盘
↓
漏掉的事故 → 加入 Checklist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
四大 Checklist 速查：
| 维度 | 核心项 |
|---|---|
| 可用性 | SPOF、故障切换、容灾、限流降级、监控告警、应急预案 |
| 性能 | 压测、P99 延迟、缓存设计、DB 性能、水平扩展、异步解耦 |
| 安全 | 认证、授权、数据加密、输入验证、审计日志、合规 |
| 可维护性 | 测试覆盖率、文档、可观测性、DevOps、配置管理、技术债 |
60 秒诊断命令清单（用于判断评审现状）：
# 看是否有"走过场"症状
ls docs/review/ | wc -l # 评审报告数量
find docs/review -name "*.md" -mtime +90 | wc -l # 90 天没更新的报告
# 看是否有"贫血 ADR"症状
ls docs/adr/ | wc -l # ADR 数量
grep -l "Status: Accepted" docs/adr/*.md | wc -l # 有效 ADR 数量
git log --follow docs/adr/ --since="6 months" # 半年内 ADR 更新
# 看是否有"不闭环"症状
# 在项目管理系统 (Jira/Tapd) 中查询:
# - 标签 = "架构评审风险"
# - 状态 = "未关闭"
# - 超期 = "是"
# 如果数量 > 总风险 30% → 严重不闭环
# 看是否有"代码与 ADR 脱节"症状
grep -r "ADR-" src/ | wc -l # 代码中引用 ADR 的次数
# 一般核心模块应有 5+ 处引用,否则 ADR 沦为摆设
# 看 Checklist 使用情况
find docs/review -name "checklist*.md" | head # Checklist 是否归档
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
架构评审黄金法则：
场景驱动: 先有可量化场景,后有评审 (没场景拒绝评审)
方法选型: 小项目 Checklist、中项目风险风暴、大项目 ATAM
全员参与: 评委多角色(技术/业务/安全/运维),CTO 最后发言
决策沉淀: 所有关键决策入 ADR,进代码仓库
风险闭环: 评审日入项管,每周 review,Critical 必清
反模式警惕: 走过场/一言堂/完美主义/不闭环 四大病
持续演进: 季度 ADR review,事故反哺 Checklist
评审越早越好: 立项 > 方案 > 设计 > 编码 (成本指数递增)
工具协同: ATAM 找风险,风险风暴汇集体智慧,ADR 沉淀,Checklist 兜底
红线纪律: 0 风险 = 评审无效;Critical 未闭环禁止上线
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
第 1 章案例：25 人 SaaS 团队 2 小时通过 60 天事故 4 起 → 引入 Checklist + 风险风暴 + ADR → 评审产出风险 32 项，上线前 Critical/High 全部闭环，上线后 P0 事故归零，复盘效率提升 5 倍。这就是"场景 + 方法 + 决策 + 闭环"四位一体给团队的核心红利。
下一篇：我们已经知道了"如何评审架构是否合格"，下一步进入 08.架构演进实战指南——把"架构设计"从一次性决策升级为"单体 → 模块化 → 微服务"逐步演进的工程实践，并给出代码级演示。
上次更新: 2026/06/17, 11:43:57
