架构评审数据化：别让评审会只剩观点碰撞

架构评审数据化：别让评审会只剩观点碰撞

一、架构评审需要证据

架构评审经常变成观点碰撞：有人觉得拆服务更清晰，有人觉得单体更稳定；有人主张引入 MQ，有人担心复杂度。观点本身不坏，但如果没有数据，评审会很难收敛。

数据化评审不是让数字替代判断，而是让讨论建立在共同事实上。流量、延迟、错误率、发布频率、团队边界、成本和风险，都应进入评审材料。

二、评审材料要结构化

flowchart TD A[方案背景] --> B[现状数据] B --> C[候选方案] C --> D[成本收益] D --> E[风险与回滚] E --> F[评审结论]

现状数据回答为什么要改。候选方案回答怎么改。成本收益回答值不值得。风险与回滚回答出问题怎么办。缺任何一块，评审结论都会不稳。

架构图也要服务问题。不要为了好看画复杂图。每张图最好回答一个问题：调用链怎么变，数据流怎么走，故障怎么隔离，部署边界在哪里。

三、评审指标要提前定义

review_metrics: p95_latency_ms: 180 error_rate: 0.02 deploy_frequency_per_week: 6 rollback_time_min: 10

方案上线后，要用评审时定义的指标验证。比如目标是降低 p95 延迟，就不能上线后只说代码结构更优雅。架构治理必须形成闭环。

public record ArchitectureDecision( String decisionId, String option, List<String> metrics, List<String> rollbackSteps ) {}

把架构决策记录下来，后续才能复盘。当初为什么选这个方案，放弃了什么，预期指标是什么，回滚条件是什么，都应该有记录。

四、评审要允许小步验证

不是所有架构争议都能在会议上解决。可以用灰度、压测、影子流量或小范围试点来验证。评审会决定验证路径，而不是一次性决定全部未来。

还要关注组织成本。一个技术方案再漂亮，如果需要团队短期掌握大量新技术，或者运维能力跟不上，就有落地风险。架构评审要同时评估系统和团队。

评审材料还要包含不做的后果。很多方案之所以难评，是因为只描述改造收益，没有描述保持现状的风险。现状如果还能支撑一年，改造节奏可以慢；如果已经频繁事故，就要提高优先级。

成本估算要拆成开发成本、迁移成本、运维成本和学习成本。只估开发时间，会低估架构变更。新技术引入后，监控、告警、排障、培训和文档都要付出成本。

回滚方案也要具体。回滚触发条件是什么，数据如何恢复，配置如何切回，用户是否感知，都要写清楚。没有回滚路径的方案，不适合直接全量上线。

最后，架构评审结论要有 owner 和复盘日期。没人跟踪的决策，很快会变成文档里的历史。评审通过后，仍要看运行指标是否达到预期。

评审还要保留反对意见。某个方案被采纳，不代表其他担忧消失。把主要反对理由、触发风险和观察指标写下来，后续复盘会更客观。架构治理不是追求会议一致，而是让不同判断都有证据可查。

对跨团队方案，要明确接口契约和交付边界。谁提供 SDK，谁维护文档，谁处理告警，谁负责容量，这些都要写进评审结论。否则方案上线后，问题会在团队边界来回漂移。

还可以建立评审模板。固定包含背景、现状数据、方案对比、风险、回滚、指标和 owner。模板不是形式主义，它能减少遗漏，让每次评审都站在相同基线上讨论。

最后，评审应鼓励小步落地。先验证关键假设，再逐步扩大范围。一次性押注的大架构改造，最容易在真实运行中暴露意料之外的成本。

五、总结

架构评审数据化要准备现状数据、候选方案、成本收益、风险回滚和上线后验证指标。评审结论应能被后续运行数据验证。

好的架构评审不是谁声音更大，而是谁能把问题、证据、取舍和验证路径讲清楚。