# 02-技术评审与架构决策工作流

## 一、工作流总览

```
┌─────────────────────────────────────────────────────────────────────┐
│                    技术评审与架构决策工作流全景图                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │1.评审准备 │──>│2.架构评审 │──>│3.专项评审 │──>│4.决策会议 │        │
│  │ 材料收集/  │   │ 合规/行   │   │ 安全/性能/│   │ 形成决策/  │        │
│  │ 评审组组建 │   │ 业对标    │   │ 集成/运维  │   │ 记录ADR    │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│       │              │              │              │                │
│       v              v              v              v                │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐        │
│  │5.ADR归档 │──>│6.问题追踪 │──>│7.复审确认 │──>│8.评审关闭 │        │
│  │ 架构决策   │   │ 整改闭环   │   │ 通过/有条件│   │ 归档/移交  │        │
│  │ 记录存档   │   │ 限期整改   │   │ 通过/不通过│   │            │        │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘        │
│                                                                     │
│  核心产物: 架构评审报告 | ADR | 问题整改清单 | 评审决议                   │
└─────────────────────────────────────────────────────────────────────┘
```

## 二、适用场景

本工作流适用于交通技术方案在正式交付前的质量把关。涵盖：
- 内部方案的技术评审（方案设计→开发之间的质量门禁）
- 外部供应商方案的技术评估
- 重大架构变更的决策评审
- 技术选型的最终确认

## 三、评审组织

### 3.1 评审组构成

| 角色 | 人数 | 职责 | 必备技能 |
|------|:---:|------|------|
| **主评审人（架构师）** | 1人 | 主持评审/汇总意见/输出评审报告 | 交通+技术架构≥8年 |
| **交通业务专家** | 1人 | 评审业务理解/场景覆盖/功能匹配 | 交通行业≥5年 |
| **安全架构师** | 1人 | 评审安全设计/合规性 | 安全+交通≥3年 |
| **数据架构师** | 1人 | 评审数据架构/数据流/数据治理 | 大数据≥5年 |
| **基础设施专家** | 1人 | 评审部署/运维/灾备 | 云/IDC/边缘≥5年 |
| **交付负责人** | 1人 | 评审实施可行性/资源合理性 | 项目管理≥5年 |
| **记录员** | 1人 | 记录评审过程/整理意见 | — |

### 3.2 评审准入条件

方案必须满足以下条件方可进入技术评审：

- [ ] 方案文档完整（含逻辑/物理/数据/安全四架构）
- [ ] 关键技术选型有≥2个候选方案的对比论证
- [ ] 非功能需求（性能/安全/可用性/扩展性）有量化定义
- [ ] 实施计划有WBS和资源需求估算
- [ ] 方案已通过方案架构师自检（使用tools/10技术方案成熟度评估≥65分）

---

## 四、架构评审（Architecture Review）

### 4.1 评审维度与检查标准

| 评审维度 | 权重 | 检查要点 | 通过标准 |
|------|:---:|------|------|
| **架构合理性** | 30% | 分层清晰/职责明确/耦合度低/符合架构模式 | 无重大架构缺陷 |
| **业务匹配度** | 25% | 准确理解业务痛点/场景覆盖完整/需求可追溯 | 核心场景覆盖率≥90% |
| **技术可行性** | 20% | 技术选型合理/团队能力匹配/不存在"不可能实现"的设计 | 关键技术风险已识别且有缓解措施 |
| **性能与可用性** | 15% | 性能指标量化/有容量规划/高可用设计 | 核心场景满足性能SLA |
| **安全合规** | 10% | 安全四层覆盖/身份认证/数据安全/合规要求 | 满足对应等保/关基要求 |

### 4.2 常见架构问题及应对

| 问题类型 | 典型表现 | 严重程度 | 处理方式 |
|------|------|:---:|------|
| **架构层级混乱** | 应用层逻辑下沉到基础设施层 | 高 | 重新设计/评审不通过 |
| **单点故障未处理** | 核心服务/数据库无双活/无灾备 | 高 | 增加冗余设计后复审 |
| **不可扩展** | 性能天花板接近当前业务量 | 高 | 增加水平扩展设计 |
| **耦合过紧** | 修改一个模块需要联动改5个模块 | 中 | 解耦设计/增加接口抽象 |
| **数据流设计缺陷** | 实时数据进OLAP/历史数据进Redis | 中 | 纠正存储引擎选型 |
| **过度设计** | 小项目用了大规模架构（数据网格+事件溯源等） | 中 | 简化架构/按需裁剪 |

### 4.3 架构决策记录（ADR）

重大架构决策必须使用ADR格式记录：

```markdown
# ADR-XXX: [决策标题]

**状态**: [提议/已接受/已废弃/已取代]
**日期**: YYYY-MM-DD
**决策者**: [姓名/角色]

## 背景
[为什么需要做这个决策？上下文是什么？]

## 决策
[我们决定做什么？]

## 备选方案
1. [方案A] — [简述+优缺点]
2. [方案B] — [简述+优缺点]

## 影响
[这个决策会影响什么？哪些部分需要随之调整？]

## 后果
- 正面: [带来的好处]
- 负面: [带来的代价/限制/风险]
- 缓解: [如何缓解负面影响]
```

---

## 五、专项评审

### 5.1 安全专项评审

| 检查项 | 评审要点 | 通过标准 |
|------|------|------|
| 网络安全分层 | OT/IT/DMZ三层是否隔离？ | 有明确网络拓扑和防火墙策略 |
| 身份认证 | 是否有多因素认证？RBAC粒度？ | 核心系统支持MFA+细粒度RBAC |
| 数据安全 | 数据分类分级？脱敏策略？加密方案？ | 有数据分类分级的实施方案 |
| V2X安全（如适用） | SCMS/PKI证书体系？消息签名？ | 符合V2X SCMS标准 |
| 安全运营 | SOC/SIEM/威胁情报/应急响应？ | 有安全运营方案 |

### 5.2 性能专项评审

| 检查项 | 评审要点 | 参考基准 |
|------|------|:---:|
| 并发处理能力 | 设计吞吐量 vs 业务峰值（×3倍余量） | 信号系统>1000路并发 |
| 端到端延迟 | 各场景延迟预算分配是否合理？ | 感知→告警<500ms |
| 存储I/O | 读写混合场景下的IOPS预估？ | — |
| 容量规划 | 3年数据增长是否在扩容范围内？ | 存储容量预估×3年 |

### 5.3 集成专项评审

| 检查项 | 评审要点 |
|------|------|
| 外部系统集成清单 | 是否列出所有需要集成的外部系统？ |
| 接口标准 | 每个外部接口定义了协议/格式/频率/认证方式？ |
| 数据迁移 | 是否有存量系统数据迁移方案？ |
| 回退策略 | 如果集成失败，是否有回退方案？ |

---

## 六、评审决策

### 6.1 评审结论类型

| 结论 | 定义 | 后续行动 |
|:---:|------|------|
| **通过** | 方案符合质量标准，可直接进入下一阶段 | 评审报告归档/进入开发或实施 |
| **有条件通过** | 存在非关键问题，修正后无需复审 | 限期修正/架构师确认修正/归档 |
| **复审** | 存在关键问题，需修正后重新评审 | 修正→重新评审（1-2周后） |
| **不通过** | 存在根本性缺陷，需重新设计 | 返回方案设计阶段 |

### 6.2 问题分级与整改期限

| 问题等级 | 定义 | 示例 | 整改期限 |
|:---:|------|------|:---:|
| **阻断性** | 不解决则系统无法正常运行 | 无灾备方案/核心组件单点 | 不解决不予通过 |
| **严重** | 影响核心质量属性 | 性能指标无量化/安全设计缺失 | 复审前解决 |
| **一般** | 影响非核心功能或未来的可维护性 | 文档不完整/缺少部分接口定义 | 有条件通过后按期解决 |
| **建议** | 非必须，但推荐采纳 | 更优雅的实现方式/更好的工具选择 | 记录备查 |

---

## 七、ADR模板库（交通领域常见架构决策）

| ADR编号 | 决策主题 | 常见选项 | 推荐方向 |
|:---:|------|------|------|
| ADR-001 | 消息队列选型 | Kafka vs Pulsar vs Redis Streams | 大规模→Kafka；多租户→Pulsar |
| ADR-002 | API网关选型 | Kong vs APISIX vs Spring Cloud Gateway | 云原生→APISIX；生态集成→Kong |
| ADR-003 | OLAP引擎选型 | StarRocks vs ClickHouse vs Doris | 联邦查询→StarRocks；极致性能→ClickHouse |
| ADR-004 | 实时vs批处理架构 | Lambda vs Kappa | 复杂离线分析→Lambda；全实时→Kappa |
| ADR-005 | OT/IT安全隔离策略 | 物理隔离 vs 逻辑隔离(vLAN) vs 微隔离 | 安全攸关→物理隔离；一般→微隔离 |
| ADR-006 | 路侧计算架构 | 集中MEC vs 分布式工控机 vs 混合 | 高性能→MEC；低成本→工控机 |
| ADR-007 | 数据库主备策略 | 主从复制 vs 双活 vs 分布式 | 中等规模→主从；大规模→分布式 |

---

> **版本**: V1.0 | **撰写日期**: 2026-07 | **适用项目**: 所有交通技术方案的技术评审
