架构评审机制是什么
架构评审按场景分级：重大变更、例外申请、新技术引入走评审，日常小改动由团队自决。评审输入包括影响分析、成本、安全与合规、替代方案，输出结论与放行条件。机制设计的关键是既不让团队绕开评审，也不让评审成为交付瓶颈：分级标准与响应时限必须公开。
基本信息
| 分级标准 | 重大变更、例外申请、新技术引入走评审；常规变动团队自决 |
|---|---|
| 评审输入 | 影响分析、成本、合规、替代方案与取舍 |
| 输出结论 | 通过、有条件通过、需补充材料 |
| 时效要求 | 明确响应时限，避免排队数周 |
| 记录载体 | 评审记录、决策人与条件项责任 |
典型使用场景
- 引入新的中间件或数据库，需要评估运维成本与团队能力
- 跨系统依赖关系变化，需要评估上下游影响与切换方案
- 技术方案超出既定架构原则，需要走例外审批
- 成本影响超过阈值的方案，需要结合预算与采购评估
- 存量架构债治理方案需要跨团队协同与优先级确认
评审触发条件示例
评审触发条件示例
# 触发条件要可判定，避免凭感觉判断是否需要评审
跨系统依赖关系变化（新增或变更上下游调用）
引入新的中间件 / 数据库 / 第三方服务
超出架构原则的例外申请
成本影响超过阈值（例如年化超过约定金额）
# 不触发的情况要写清，给团队明确的自决空间评审材料清单
| 材料 | 要点 |
|---|---|
| 方案对比 | 至少两案并写取舍，说明为何放弃另一案 |
| 影响分析 | 上下游依赖与数据流，含失败场景 |
| 回退预案 | 切换与回滚步骤，含不可回退操作 |
| 成本与合规 | 三年成本估算与合规要求对应关系 |
评审要有时效约束：明确受理后多久给出结论，超时默认视为通过或升级，否则团队会倾向于绕开机制直接实施。