Arch Day 21

Arch Day 21: ATAM架构评审实战

ATAM(Architecture Tradeoff Analysis Method)是SEI提出的系统化架构评审方法，通过质量属性场景驱动，识别架构中的敏感点(Sensitivity Points)、权衡点(Tradeoff Points)和风险点(Risk Points)，最终输出可行动的评审报告。

2026-04-20

第一阶段 - 架构基础

ATAM架构评审敏感点权衡点风险点Week3总结

日期: 2026-04-20 (Day 21) 阶段: 第一阶段 - 架构基础标签: #ATAM #架构评审 #敏感点 #权衡点 #风险点 #Week3总结

核心概念

一句话定义

为什么资深架构师仍需关注

架构评审是架构师最高价值的活动之一。我在金融系统十年经验中，经历过两种极端：

没有评审的后果：一个核心支付系统，架构设计由一个人完成，没有评审。上线后发现数据库设计不支持多币种——返工成本3个月。如果做了评审，第一天就能发现这个问题。

糟糕评审的后果：评审变成了"高级别的code review"，纠结于技术细节(用Redis还是Memcached)，却忽略了架构层面的真正风险(单点故障/数据一致性)。评审开了4小时，什么有价值的结论都没得出。

好的架构评审有三个核心价值：

提前发现风险：在写代码之前发现架构缺陷，修复成本最低
强制深度思考：准备评审材料的过程本身就促进了架构设计的深入思考
建立共识：让所有利益相关方对架构的取舍有共同理解

常见误区与反模式

误区	表现	正确做法
评审=批判	评审变成挑错大会	评审目的是识别风险和改进，不是证明设计者错了
评审=审批	评审只是走流程，领导签字	评审应该有实质性的技术讨论和质量分析
关注细节	讨论变量命名/框架选择	ATAM关注架构级的质量属性和trade-off
没有输入	即兴评审，没有准备	评审前发送材料，reviewer提前准备
没有输出	讨论了很多，但没有结论	必须有结构化的评审报告(敏感点/权衡点/风险点)
只评审一次	设计完做一次评审就结束	关键节点多次评审(概念/详细/实施后)

知识点详解

知识点一：ATAM完整流程(9步)

ATAM 9个步骤:

Phase 0: 准备 (评审前1-2周)
┌─────────────────────────────────────────┐
│ Step 0: 会前准备                         │
│ • 确定参与者(架构师/开发/业务/管理)       │
│ • 发送架构文档+质量属性需求               │
│ • 分配reviewer预习时间                   │
└─────────────────────────────────────────┘

Phase 1: 评估(核心，4-6小时)
┌─────────────────────────────────────────┐
│ Step 1: 介绍ATAM方法 (15min)             │
│ • 向参与者解释评审流程                    │
│ • 设定期望和规则                          │
│                                         │
│ Step 2: 介绍业务驱动力 (30min)            │
│ • 业务背景和目标                          │
│ • 关键质量属性需求                        │
│ • 约束条件                               │
│                                         │
│ Step 3: 介绍架构 (45min)                 │
│ • 架构概览(C4图)                         │
│ • 核心决策(ADR摘要)                      │
│ • 技术选型和理由                          │
│                                         │
│ Step 4: 识别架构方法 (30min)              │
│ • 列出架构中使用的策略/模式              │
│ • 如: 微服务/事件驱动/CQRS/Saga等       │
│                                         │
│ Step 5: 生成质量属性树 (45min)            │
│ • 构建Utility Tree                      │
│ • 对每个质量属性打优先级                  │
│ • 识别Top 5场景                          │
│                                         │
│ Step 6: 分析架构方法 (90min) ← 核心!     │
│ • 对每个Top场景，分析架构如何应对         │
│ • 识别敏感点(Sensitivity Points)         │
│ • 识别权衡点(Tradeoff Points)           │
│ • 识别风险点(Risk Points)               │
│ • 识别非风险点(Non-Risk Points)          │
│                                         │
│ Step 7: 头脑风暴场景 (30min)              │
│ • 参与者提出额外的质量属性场景            │
│ • 与Utility Tree中的场景合并             │
│                                         │
│ Step 8: 分析新场景 (45min)               │
│ • 重复Step 6，分析新提出的场景           │
└─────────────────────────────────────────┘

Phase 2: 总结
┌─────────────────────────────────────────┐
│ Step 9: 呈现结果 (30min)                 │
│ • 汇总所有敏感点/权衡点/风险点           │
│ • 优先级排序                             │
│ • 下一步行动计划                         │
└─────────────────────────────────────────┘

知识点二：敏感点/权衡点/风险点

这是ATAM的核心输出，也是架构评审最有价值的产物。

定义与区分：

敏感点 (Sensitivity Point):
  "改变这个架构决策，会显著影响某个质量属性"
  例: 缓存TTL的设置是性能的敏感点
      TTL太短→缓存命中率低→性能差
      TTL太长→数据不一致

权衡点 (Tradeoff Point):
  "改变这个架构决策，会同时影响多个质量属性(此消彼长)"
  例: 同步vs异步AML筛查
      同步: 安全性↑ 延迟↑
      异步: 延迟↓ 合规风险↑

风险点 (Risk):
  "架构中存在潜在的问题/不确定性"
  例: 系统依赖单一支付渠道，该渠道无SLA保障

非风险点 (Non-Risk):
  "经过分析，确认某个看似有风险的决策实际是安全的"
  例: 虽然用了新技术X，但有3个月POC验证，性能满足要求

实际识别示例：

编号	类型	描述	影响的质量属性	严重程度
S-1	敏感点	数据库连接池大小	性能/可用性	高
S-2	敏感点	Kafka分区数	吞吐量/有序性	中
T-1	权衡点	同步vs异步风控	安全性vs延迟	高
T-2	权衡点	强一致vs最终一致	一致性vs可用性	高
R-1	风险点	单数据中心部署	可用性(灾备)	极高
R-2	风险点	第三方支付渠道无SLA	可用性	高
R-3	风险点	团队无Kubernetes经验	可维护性/可部署性	中
N-1	非风险	使用PostgreSQL而非Oracle	性能(已验证)	低

知识点三：如何准备和主持架构评审

评审前准备清单：

## 架构评审准备清单

### 架构师(被评审方)需要准备:
- [ ] 架构概览文档(C4 Context + Container图)
- [ ] 核心ADR列表(至少Top 5个决策)
- [ ] 质量属性需求列表(初版Utility Tree)
- [ ] 技术选型说明
- [ ] 已知风险和缓解措施
- [ ] 部署拓扑图
- [ ] 数据流图

### 评审主持人需要准备:
- [ ] 确认参与者名单和角色
- [ ] 提前1周发送所有材料
- [ ] 准备评审议程(含时间分配)
- [ ] 准备空白的敏感点/权衡点/风险点记录表
- [ ] 预订会议室/在线会议(4-6小时)

### Reviewer需要准备:
- [ ] 阅读架构文档(至少1小时)
- [ ] 准备3-5个架构层面的问题
- [ ] 从自己的领域角度思考质量属性
- [ ] 标注不理解/有疑问的部分

评审主持技巧：

技巧	说明
控制粒度	讨论偏向代码细节时拉回架构层面:"这个问题在代码review中讨论更合适"
确保参与	主动邀请沉默的人发言:"安全方面，Lisa有什么看法？"
记录一切	安排专人记录，不依赖记忆
区分问题和建议	"这是一个风险"vs"我建议用X替代Y"——先识别问题，后讨论方案
时间管理	为每个Step设定时间限制，到时间就推进
停车场(Parking Lot)	无法当场解决的问题放入"停车场"，会后跟进

知识点四：架构评审的政治学

架构评审不仅是技术活动，更是一个涉及人际关系和组织政治的活动。处理不好，评审会变成攻击和防御的战场。

如何给出负面反馈：

差的方式:
  "你这个设计有问题，单点故障很明显。"
  → 被评审者感觉被攻击，防御心态

好的方式:
  "在可用性方面，我注意到数据库是单节点部署。
   如果参照我们的QAS-AV-001场景(节点故障，30秒内恢复)，
   当前的架构可能是一个风险点。
   你当初是怎么考虑这个取舍的？"
  → 基于事实/场景/好奇心，而非判断

最好的方式:
  先承认优点: "CDC管道的设计很好，数据同步延迟控制在秒级。"
  然后提出关注: "我有一个关于灾备方面的问题想讨论..."
  → 先建立尊重，再提出问题

处理常见评审困境：

困境	应对策略
架构师过度防御	"我们不是在质疑你的能力，是在帮你找到盲点。"
高层插手技术细节	"这是架构层面评审，技术细节我们在后续design review中深入。"
讨论陷入僵局	"两个方案各有优劣，我们把它标记为权衡点，带着数据下次讨论。"
时间不够	"核心的5个场景我们已经覆盖了，剩余场景留给后续小范围讨论。"
评审变成方案设计会	"今天的目标是识别问题，不是设计解决方案。方案在下次会议讨论。"

知识点五：架构评审的层次和频率

架构评审金字塔:

         ┌───────────────┐
         │  战略评审       │  频率: 年度/重大决策
         │  (架构委员会)   │  参与: CTO/VP/首席架构师
         │  整体架构方向   │  时间: 1天
         └───────┬───────┘
                 │
         ┌───────┴───────┐
         │  ATAM评审      │  频率: 新系统/重大变更
         │  (跨团队)      │  参与: 架构师+Tech Lead+业务
         │  系统级架构    │  时间: 4-6小时
         └───────┬───────┘
                 │
         ┌───────┴───────┐
         │  设计评审      │  频率: 每个Sprint/迭代
         │  (团队内)      │  参与: Tech Lead+高级开发
         │  模块级设计    │  时间: 1-2小时
         └───────┬───────┘
                 │
         ┌───────┴───────┐
         │  代码评审      │  频率: 每个PR
         │  (同伴)        │  参与: 开发人员
         │  实现级代码    │  时间: 30分钟-1小时
         └───────────────┘

对比分析

架构评审方法对比

方法	核心特点	优势	劣势	适用场景
ATAM	质量属性+权衡分析	系统化/全面	耗时(4-6h)	关键系统的初始设计
CBAM	成本-收益分析	经济视角	量化困难	需要ROI论证
ARID	主动review/检视	聚焦/高效	范围窄	特定模块/组件
轻量评审	检查清单+讨论	快速/低成本	不够系统化	增量变更/小型系统
ADR Review	决策为中心	聚焦决策	不涉及全局	单个决策评审
Fitness函数	自动化验证	持续/客观	覆盖有限	CI/CD中持续检查

评审输出物对比

输出物	内容	受众	行动
风险清单	优先级排序的风险列表	技术+管理	创建mitigate计划
敏感点清单	需要特别关注的架构决策	架构师+开发	设定监控和阈值
权衡点清单	需要显式取舍的决策	架构师+业务	写ADR记录取舍
改进建议	具体的改进方向	开发团队	纳入技术债backlog
非风险确认	确认某些决策是安全的	全团队	增强信心/减少争论

架构设计实操

实操目标

对"跨境支付系统"架构方案做完整ATAM评审，生成评审报告。

被评审的架构(概要)

跨境支付系统架构概要:
(基于Week 3各天的设计)

技术栈:
- 微服务架构(15个核心服务)
- PostgreSQL Aurora(主数据库)
- Kafka(事件驱动)
- Redis(缓存)
- Istio Service Mesh(mTLS/流量管理)
- Kubernetes(容器编排)
- OpenTelemetry(可观测性)

关键ADR:
- ADR-S-001: PostgreSQL Aurora (Day 16)
- ADR-S-002: gRPC内部通信 (Day 16)
- ADR-T-003: Redis缓存策略 (Day 16)
- ADR-S-019: 零信任安全架构 (Day 19)

质量属性SLO:
- 可用性: 99.95%
- P99延迟: <500ms
- 正确性: 99.999%

ATAM评审过程

Step 5: Utility Tree(Top 5场景)

优先级标记: (业务重要性, 实现难度)

1. 可用性-故障转移 (H,H)
   "主数据中心故障时，60秒内自动切换，不丢失已提交交易"

2. 安全性-数据保护 (H,H)
   "攻击者获取数据库访问权限时，无法读取敏感数据(PII/卡号)"

3. 性能-交易延迟 (H,H)
   "高峰期2000 TPS，P99延迟<500ms"

4. 合规性-AML筛查 (H,M)
   "每笔交易实时筛查制裁名单，延迟<100ms，漏检率0"

5. 可扩展性-水平扩展 (H,M)
   "交易量增长5x时，系统可水平扩展，不需要架构重构"

Step 6: 架构方法分析

场景1分析: 可用性-故障转移

架构方法: Aurora Multi-AZ + Kubernetes多副本 + Istio流量管理

分析:
┌─────────────────────────────────────────────────────────┐
│ 敏感点(S):                                               │
│                                                         │
│ S-1: Aurora故障转移时间                                   │
│   Aurora Multi-AZ自动故障转移通常需要30-60秒              │
│   在此期间，所有写入操作会失败                              │
│   影响: 这30-60秒的不可用直接消耗Error Budget              │
│   建议: 应用层需要实现重试机制(指数退避)                   │
│                                                         │
│ S-2: Kafka消费者的rebalance时间                          │
│   Kubernetes Pod重启时，Kafka消费者组会rebalance           │
│   rebalance期间该分区的消息不会被消费                      │
│   影响: 事件驱动的后续处理可能延迟                         │
│   建议: 优化consumer配置(session.timeout/heartbeat)       │
│                                                         │
│ 权衡点(T):                                               │
│                                                         │
│ T-1: 单写 vs 多写数据库                                   │
│   当前: Aurora单写节点 → 故障切换有延迟                    │
│   替代: CockroachDB多写 → 无切换延迟，但引入分布式事务开销 │
│   取舍: 简单性/团队经验 vs 更高可用性                      │
│   决策: 当前规模下Aurora足够，标记为未来演进方向            │
│                                                         │
│ 风险点(R):                                               │
│                                                         │
│ R-1: ⚠️ 单数据中心部署(最高风险)                          │
│   当前架构似乎只部署在单个AWS Region                      │
│   如果整个Region不可用(极端但可能)，系统完全停止           │
│   缓解: 规划跨Region灾备方案(即使是冷备)                  │
│   优先级: 必须在Phase 2解决                               │
│                                                         │
│ R-2: 外部支付渠道(SWIFT)的可用性不受我们控制               │
│   SWIFT有自己的维护窗口和偶发故障                         │
│   缓解: 多渠道冗余 + 异步排队机制 + 渠道降级策略          │
│                                                         │
│ 非风险(N):                                               │
│                                                         │
│ N-1: Kubernetes本身的可用性                               │
│   使用AWS EKS托管，控制面由AWS保障                        │
│   已做过故障注入测试，Pod恢复时间<30秒                    │
└─────────────────────────────────────────────────────────┘

场景3分析: 性能-交易延迟

架构方法: gRPC服务调用 + Redis缓存 + 读写分离

分析:
┌─────────────────────────────────────────────────────────┐
│ 敏感点(S):                                               │
│                                                         │
│ S-3: 缓存命中率                                          │
│   汇率数据缓存TTL=5秒                                    │
│   如果缓存miss，需要查数据库(增加约10ms)                  │
│   影响: 缓存命中率每下降10%，P99延迟增加约15ms            │
│   建议: 监控缓存命中率，设定>95%的SLI                     │
│                                                         │
│ S-4: 数据库连接池大小                                     │
│   连接池太小: 请求排队等待，延迟飙升                       │
│   连接池太大: 数据库连接数超限                             │
│   建议: 基于负载测试确定最优值，并设置监控告警              │
│                                                         │
│ 权衡点(T):                                               │
│                                                         │
│ T-2: mTLS带来的延迟 vs 安全性                             │
│   mTLS增加约2-5ms延迟(TLS握手)                          │
│   在500ms的SLO预算内占比1%(可接受)                       │
│   但如果调用链很长(10个服务)，累积影响20-50ms            │
│   取舍: 安全性优先，通过连接复用减少TLS握手次数           │
│                                                         │
│ T-3: 同步风控 vs 异步风控                                 │
│   同步: AML筛查增加~80ms(在500ms预算内)                  │
│   异步: 减少80ms但有合规窗口期                            │
│   取舍: 合规不可妥协，选择同步                            │
│                                                         │
│ 风险点(R):                                               │
│                                                         │
│ R-3: ⚠️ 外部银行核心系统响应时间不可控                     │
│   核心系统可能在某些时段响应变慢(>1s)                      │
│   这直接导致我们的P99 SLO无法满足                         │
│   缓解: 设置核心系统调用超时(800ms) + 熔断器               │
│         超时后走异步确认流程                                │
│                                                         │
│ R-4: N+1查询风险                                         │
│   编排层调用多个下游服务，如果没有并行化                    │
│   串行调用5个服务 × 100ms/个 = 500ms(刚好在SLO边界)      │
│   缓解: 确保无依赖关系的调用并行执行                       │
└─────────────────────────────────────────────────────────┘

ATAM评审报告

# 跨境支付系统 ATAM架构评审报告

## 评审信息
- 日期: 2026-04-20
- 参与者: 首席架构师/DBA Lead/安全工程师/业务分析师/SRE Lead
- 评审范围: 系统整体架构
- 方法: ATAM

## 评审结论摘要

### 总体评价
架构整体设计合理，技术选型成熟。核心交易链路的设计充分考虑了
性能和安全性需求。主要风险集中在可用性(灾备)和外部依赖管理。

### 风险点(按优先级排序)

| 编号 | 风险 | 严重程度 | 影响的QAS | 建议行动 | 时间 |
|------|------|---------|----------|---------|------|
| R-1 | 单Region部署，无跨Region灾备 | 极高 | QAS-AV-002 | 制定跨Region灾备方案 | Phase 2 |
| R-3 | 银行核心响应时间不可控 | 高 | QAS-PF-001 | 超时+熔断+异步确认 | 立即 |
| R-2 | SWIFT渠道无SLA保障 | 高 | QAS-AV-001 | 多渠道冗余+降级策略 | Phase 1 |
| R-4 | 串行调用导致延迟累积 | 中 | QAS-PF-001 | 并行化无依赖调用 | Sprint 2 |

### 敏感点(需持续监控)

| 编号 | 敏感点 | 监控指标 | 阈值 |
|------|--------|---------|------|
| S-1 | Aurora故障转移时间 | failover_duration | <60s |
| S-2 | Kafka rebalance时间 | consumer_lag | <30s |
| S-3 | Redis缓存命中率 | cache_hit_rate | >95% |
| S-4 | DB连接池使用率 | pool_active/pool_max | <85% |

### 权衡点(已决策)

| 编号 | 权衡 | 决策 | ADR |
|------|------|------|-----|
| T-1 | 单写Aurora vs 多写CockroachDB | 当前Aurora，未来评估 | ADR-S-001 |
| T-2 | mTLS延迟 vs 安全性 | 安全优先，连接复用缓解 | ADR-S-019 |
| T-3 | 同步AML vs 异步AML | 同步(合规不妥协) | 新建ADR |

### 非风险确认

| 编号 | 关注点 | 确认结论 |
|------|--------|---------|
| N-1 | EKS可用性 | 托管服务+故障注入验证，可接受 |
| N-2 | PostgreSQL性能 | 基准测试满足2000TPS要求 |

### 下一步行动计划

1. [立即] 实现银行核心调用的超时+熔断机制
2. [Sprint 2] 并行化编排层的无依赖调用
3. [Phase 1] 设计SWIFT渠道降级策略
4. [Phase 2] 制定跨Region灾备方案(RTO<4h, RPO<1min)
5. [持续] 建立上述敏感点的监控告警

AI增强实践

AI辅助架构评审

AI作为Pre-reviewer：

Prompt模板:

你是一位资深金融系统架构师，请作为架构评审的pre-reviewer，
分析以下架构设计:

[粘贴架构文档]

请从以下维度进行分析:
1. 可用性: 识别单点故障/故障域/恢复机制
2. 安全性: 检查认证/授权/加密/审计的完整性
3. 性能: 分析调用链长度/缓存策略/数据库瓶颈
4. 可扩展性: 评估水平扩展能力和瓶颈
5. 可维护性: 服务粒度/耦合度/部署独立性

对每个发现，标注为:
- 风险点(R): 可能导致问题
- 敏感点(S): 需要特别关注
- 权衡点(T): 存在取舍关系

输出格式: 表格(编号/类型/描述/影响的质量属性/建议)

AI辅助评审报告生成：

在评审会议中，将讨论记录输入AI:

请将以下架构评审会议记录整理成结构化的评审报告:

[粘贴会议记录]

报告格式要求:
1. 评审结论摘要(100字)
2. 风险点清单(表格，含优先级)
3. 敏感点清单(表格，含监控建议)
4. 权衡点清单(表格，含决策记录)
5. 行动计划(时间表)

AI驱动的架构适应度函数(Fitness Function)

# 概念：AI驱动的持续架构评审
class ArchitectureFitnessFunction:
    """
    ATAM是人工的、周期性的评审
    Fitness Function是自动化的、持续的评审

    例：
    - 服务间循环依赖检测(代码分析)
    - 分层架构违规检测(依赖方向检查)
    - 性能回归检测(SLO自动验证)
    - 安全合规检查(mTLS覆盖率)
    """

    def check_dependency_cycles(self):
        """检测服务间循环依赖"""
        # AI分析代码import和调用关系
        # 发现循环时自动创建ticket
        pass

    def check_slo_compliance(self):
        """持续检查SLO是否达标"""
        # 从Prometheus获取SLI数据
        # 自动计算Error Budget消耗
        pass

    def detect_architecture_drift(self):
        """检测实际架构与设计的偏离"""
        # AI对比架构文档和实际部署
        # 发现偏离时告警
        pass

与Web3/DeFi的关联

DeFi协议的"架构评审"

DeFi协议没有传统的ATAM评审，但有类似的质量保障机制：

传统ATAM评审             DeFi对应机制
┌──────────────┐      ┌─────────────────────┐
│ 架构评审      │  →   │ 智能合约审计          │
│ (人工, 周期性)│      │ (审计公司, 上线前)    │
├──────────────┤      ├─────────────────────┤
│ 敏感点识别    │  →   │ Gas优化分析          │
│              │      │ 存储布局分析          │
├──────────────┤      ├─────────────────────┤
│ 风险点识别    │  →   │ 重入漏洞/闪电贷攻击  │
│              │      │ 预言机操纵风险        │
├──────────────┤      ├─────────────────────┤
│ 权衡点记录    │  →   │ 治理提案讨论          │
│              │      │ (社区讨论取舍)        │
├──────────────┤      ├─────────────────────┤
│ Fitness函数   │  →   │ 自动化安全监控        │
│ (持续验证)    │      │ (OpenZeppelin Defender)│
└──────────────┘      └─────────────────────┘

对PM的启示：无论是传统系统还是DeFi协议，"上线前系统化地识别风险"都是核心需求。形式可以不同(ATAM vs 合约审计)，但目标相同——在问题发生前发现和缓解风险。

Week 3 总结

本周知识图谱

Week 3: 架构治理与横切关注点

Day 15: 质量属性量化
  └── QAS/Utility Tree → 定义问题

Day 16: ADR体系建设
  └── 决策追踪/生命周期 → 记录答案

Day 17: 企业级集成架构
  └── CDC/Event Mesh/ACL → 系统间协作

Day 18: 数据架构(高级)
  └── Data Mesh/合规/混合处理 → 数据治理

Day 19: 安全架构(金融级)
  └── 零信任/加密/审计 → 数据保护

Day 20: 可观测性工程
  └── SLO/告警/追踪/AIOps → 系统观察

Day 21: ATAM架构评审
  └── 综合评审/风险识别 → 质量保障
         ↑
    整合前6天的所有知识

本周核心收获

天数	核心能力	一句话总结
Day 15	量化能力	把"高可用"变成"99.95%/P99<500ms"
Day 16	决策治理	让每个架构决策可追溯/可审计
Day 17	集成设计	在异构系统间建立可靠的数据桥梁
Day 18	数据治理	在数据湖/Mesh/合规之间做正确选择
Day 19	安全体系	端到端的零信任防护(不只是加密)
Day 20	可观测性	SLO驱动的告警设计(不是越多越好)
Day 21	质量评审	ATAM系统化识别风险/敏感点/权衡点

本周产出物清单

跨境支付系统Utility Tree + Top 5 QAS
5个高质量ADR + ADR分类体系
四方集成架构设计(银行核心↔支付↔风控↔外部渠道)
跨国零售银行数据架构(OLTP/OLAP/合规)
金融平台端到端安全架构(网络→应用→数据→审计)
交易系统SLO体系(SLI→SLO→Error Budget→告警→升级)
ATAM评审报告(敏感点/权衡点/风险点)

今日思考

问题一：ATAM的投入产出比

一次完整的ATAM评审需要至少4-6小时的集中时间，加上准备时间可能是2-3天。对于一个两周一个Sprint的敏捷团队，这个投入是否合理？是否存在"轻量级ATAM"的可能——保留核心价值但减少时间投入？

问题二：评审质量如何评估？

我们评审架构的质量，但如何评审"评审本身"的质量？一次评审发现了5个风险点，是说明架构差还是评审好？如何建立评审有效性的度量标准？

问题三：架构评审的自动化边界

AI和Fitness Function可以自动化一部分架构检查，但哪些方面必须保留人工评审？人类在架构评审中不可替代的价值是什么？随着AI能力提升，这个边界会如何移动？

面试题准备

面试题1: 如何评估一个架构方案的质量？

30秒回答：

我用ATAM方法。首先建立Utility Tree明确质量属性优先级，然后对Top 5质量场景逐一分析架构的应对方式，识别三类关键发现：敏感点(需要重点关注的参数)、权衡点(质量属性之间的取舍)、风险点(可能导致问题的缺陷)。最终输出优先级排序的风险清单和行动计划。

2分钟回答：

评估架构质量我采用三层方法：

第一层，方向正确性。架构是否支持业务目标？技术选型是否匹配团队能力？这通过Utility Tree分析——如果架构设计的质量属性优先级与业务需求不匹配，方向就是错的。

第二层，风险识别。对Top 5质量属性场景逐一分析。比如可用性场景——我会问"如果数据库主节点挂了，系统怎么办？恢复需要多长时间？数据会丢吗？"通过这种场景驱动的分析，可以系统性地发现风险点。

第三层，取舍合理性。每个架构都有trade-off，关键是trade-off是否被明确识别和合理处理。比如选择最终一致性，是否清楚知道在什么场景下数据可能短暂不一致？这些不一致的业务影响是什么？有没有记录在ADR中？

在金融系统中，我特别关注三个"杀手级"风险：数据丢失(不可逆)、单点故障(尤其是"隐性单点")、安全漏洞(合规风险)。

追问准备：

Q: 架构评审中最常发现的问题是什么？ A: 三个最常见的问题：1)"隐性单点故障"——看起来有冗余，但某个组件(如配置中心/DNS)实际上是单点；2)"忽略外部依赖的不可靠性"——假设第三方系统总是可用的；3)"缺乏灾备考虑"——团队说"AWS不会挂"，但Region级别的故障是真实发生过的。
Q: 评审发现问题后，如何推动修复？ A: 分优先级处理。P0风险(如单点故障)必须在上线前解决；P1风险写入下个Sprint；P2风险写入tech debt backlog。关键是每个风险都有owner和deadline。

面试题2: 架构评审中最常发现的问题是什么？

30秒回答：

三大类：一是"隐性单点故障"——看似有冗余但某个共享组件是单点；二是"乐观假设"——假设外部依赖总是可用、网络总是通的；三是"缺失的边缘场景"——正常流程没问题但没考虑失败/超时/并发竞态。

2分钟回答：

（结合具体的金融系统案例展开说明每类问题的典型表现和影响。）

学习资源

资源	类型	推荐理由
《Software Architecture in Practice (4th)》Ch21	书籍	ATAM方法的原始来源
《Evaluating Software Architectures》(SEI)	书籍	架构评估的权威指南
《Fundamentals of Software Architecture》Ch20	书籍	架构适应度函数
SEI ATAM论文	论文	学术严谨的方法论描述
《The Software Architect Elevator》	书籍	架构评审中的沟通技巧
Neal Ford: Architecture Fitness Functions	演讲	自动化架构验证

下周预告

Week 4: 分布式系统核心模式 —— 从治理层面下沉到技术层面。我们将深入分布式系统最硬核的主题：分布式一致性(Raft/Paxos)、分布式事务(Saga/TCC/2PC)、分布式锁与幂等、CQRS/Event Sourcing、弹性模式(熔断/限流/重试/舱壁)等。这些是架构师的"内功"——理解这些模式，才能在复杂场景下做出正确的架构决策。Week 3给了你"如何评审和治理架构"，Week 4给你"如何设计出值得评审的好架构"。