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

架构评审数据化别让评审会只剩观点碰撞一、架构评审需要证据架构评审经常变成观点碰撞有人觉得拆服务更清晰有人觉得单体更稳定有人主张引入 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, ListString metrics, ListString rollbackSteps ) {}把架构决策记录下来后续才能复盘。当初为什么选这个方案放弃了什么预期指标是什么回滚条件是什么都应该有记录。四、评审要允许小步验证不是所有架构争议都能在会议上解决。可以用灰度、压测、影子流量或小范围试点来验证。评审会决定验证路径而不是一次性决定全部未来。还要关注组织成本。一个技术方案再漂亮如果需要团队短期掌握大量新技术或者运维能力跟不上就有落地风险。架构评审要同时评估系统和团队。评审材料还要包含不做的后果。很多方案之所以难评是因为只描述改造收益没有描述保持现状的风险。现状如果还能支撑一年改造节奏可以慢如果已经频繁事故就要提高优先级。成本估算要拆成开发成本、迁移成本、运维成本和学习成本。只估开发时间会低估架构变更。新技术引入后监控、告警、排障、培训和文档都要付出成本。回滚方案也要具体。回滚触发条件是什么数据如何恢复配置如何切回用户是否感知都要写清楚。没有回滚路径的方案不适合直接全量上线。最后架构评审结论要有 owner 和复盘日期。没人跟踪的决策很快会变成文档里的历史。评审通过后仍要看运行指标是否达到预期。评审还要保留反对意见。某个方案被采纳不代表其他担忧消失。把主要反对理由、触发风险和观察指标写下来后续复盘会更客观。架构治理不是追求会议一致而是让不同判断都有证据可查。对跨团队方案要明确接口契约和交付边界。谁提供 SDK谁维护文档谁处理告警谁负责容量这些都要写进评审结论。否则方案上线后问题会在团队边界来回漂移。还可以建立评审模板。固定包含背景、现状数据、方案对比、风险、回滚、指标和 owner。模板不是形式主义它能减少遗漏让每次评审都站在相同基线上讨论。最后评审应鼓励小步落地。先验证关键假设再逐步扩大范围。一次性押注的大架构改造最容易在真实运行中暴露意料之外的成本。五、总结架构评审数据化要准备现状数据、候选方案、成本收益、风险回滚和上线后验证指标。评审结论应能被后续运行数据验证。好的架构评审不是谁声音更大而是谁能把问题、证据、取舍和验证路径讲清楚。