架构评审
概述
基于证据评估风险，输出含风险等级与修复建议的检查清单。除非要求，不做重构/重设计。
建议角色
- •🏗️ 解决方案架构师：主导系统拓扑、一致性与可扩展性评估。
- •🔒 安全专家：识别认证、授权与数据流风险。
- •🚀 DevOps 工程师：评估部署、回退、SLI/SLO 与可观测性。
必需输入（缺失则询问）
- •目标、SLO 与非功能性需求
- •流量、数据规模与增长曲线
- •拓扑图与数据流
- •关键用户路径与故障模式
- •约束：延迟、成本、合规、团队规模
- •事故历史或已知热点
输出格式
使用如下结构：
markdown
检查清单 - 领域: <边界/数据/规模/可靠性/安全/可观测性/部署/成本> 风险: 严重 (Critical) | 重要 (Important) | 建议 (Suggestion) 证据: <文件/指标/链路追踪/图示备注> 影响: <用户或系统影响> 修复: <具体改动> 摘要 - 阻断发布风险: <数量 + 简短清单> - 下一步: <前 1-3 个修复项>
评审流程
- •明确范围与约束
- •收集证据（文档、代码触点、指标）
- •分领域识别风险
- •提出范围清晰的修复方案
- •按影响与紧迫度排序
检查清单领域
- •边界与耦合
- •数据流与一致性
- •可扩展性与容量
- •可靠性与故障恢复
- •安全与访问控制
- •可观测性与可运维性
- •部署与回滚
- •成本与效率
快速参考
| 步骤 | 输出 |
|---|---|
| 范围 | 明确假设或缺失输入 |
| 证据 | 引用文档/指标/路径 |
| 风险 | 含严重度的检查清单 |
| 修复 | 具体、可界定的行动 |
| 优先级 | 前 1-3 个修复项 |
示例
markdown
检查清单 - 领域: 可扩展性 风险: 重要 (Important) 证据: API 读取全量数据，未做分页 影响: 峰值负载下 p95 延迟飙升 修复: 增加分页与索引；限制单页大小 摘要 - 阻断发布风险: 0 - 下一步: 增加分页，增加索引
常见错误
- •没有证据支撑的泛化建议
- •单项缺少风险等级或修复
- •把评审当成重构或重新设计
- •忽略运行时约束或 SLO
- •输入缺失时不写明假设
借口 vs 事实
| 借口 | 事实 |
|---|---|
| “没有文档，只能给泛化建议” | 询问缺失输入或明确假设。 |
| “只要一个快速 yes/no” | 给出含阻断发布风险的检查清单。 |
| “架构评审就是重构” | 先诊断，只修被要求的部分。 |
| “我熟悉系统，不需要证据” | 引用工件或指标，避免猜测。 |
红旗 - 立刻停止
- •没有范围或约束
- •检查清单缺少风险等级或修复
- •没有证据或假设说明
- •只有摘要，没有检查清单