面试官问'你怎么做技术方案评审'——写方案比写代码更重要

// 技术方案示例：EMR到Databricks迁移
 
// 一、背景与目标
// 背景：当前使用AWS EMR运行100+个Spark作业，存在三个痛点：
//   1. 集群不稳定，月均故障2次
//   2. 运维成本高，每周花半天处理集群问题
//   3. 性能优化受限，缺少AQE、Delta Lake等功能
// 目标：迁移到Databricks，实现零故障运行、
//   ETL执行时间减少30%以上、运维成本显著降低
// 成功标准：
//   - 100%作业迁移完成
//   - 数据一致性100%（对账通过）
//   - ETL执行时间减少30%+
 
// 二、现状分析
// 当前ETL链路：100+个Spark作业、分布在3个DAG中
// 日处理数据量：约50GB增量
// 月均故障：2次，每次恢复2-4小时
// 月成本：EMR集群 $X,XXX + 运维人力折算 $X,XXX

// 三、方案设计
 
// 方案A：原地升级EMR版本
// 优点：改动最小，不需要迁移
// 缺点：不能根本解决稳定性问题，没有Delta Lake
// 排除原因：治标不治本
 
// 方案B：迁移到Databricks
// 优点：托管服务稳定性好、有AQE/Delta Lake、运维成本低
// 缺点：软件费用比EMR高约20%、SQL有方言差异需要改写
// 推荐原因：综合成本更低（软件贵但省人力）、性能更好
 
// 方案C：迁移到阿里云MaxCompute
// 优点：成本更低、国内支持好
// 缺点：AWS生态切换成本大、团队不熟悉
// 排除原因：技术栈切换太大，风险高
 
// 推荐方案：B（Databricks）
// 迁移策略：双写双读灰度方案，分3批迁移

方案评审的流程和要点

方案写好后要组织评审。我在团队中建立的评审流程是这样的：

// 方案评审流程
 
// 评审前（提前2天）
// 1. 方案文档发给所有评审人提前阅读
// 2. 评审人在文档中标注问题和建议
// 3. 准备好方案的核心论点和数据
 
// 评审中（1小时）
// 前15分钟：方案负责人讲解核心设计
//   （不要逐字读文档，重点讲决策逻辑）
// 中间30分钟：开放讨论
//   重点讨论：方案选择的理由、风险是否充分评估、
//   排期是否合理、有没有遗漏的场景
// 后15分钟：形成决议
//   通过 / 有条件通过（需要修改XX后再Review）/ 打回重做
 
// 评审后
// 1. 整理评审纪要，记录关键决策和待办项
// 2. 修改方案文档，标注修改点
// 3. 如果是'有条件通过'，修改后再让关键评审人确认

评审中常被挑战的点和怎么应对

常见挑战	面试官想考什么	好的应对方式
为什么不选方案A？	你的方案对比是否充分	拿出具体的对比维度和数据，不是凭感觉
这个方案最大的风险是什么？	你是否考虑了风险	主动列出2-3个风险点和对应的缓解措施
排期为什么是X周？	你的估时能力	分解成子任务，每个子任务独立估时
如果XX情况发生怎么办？	你的应急预案	说清楚回滚方案和Plan B
有没有更简单的方案？	你是否过度设计	解释为什么简单方案不够用，但承认如果场景变简单可以简化

面试高频追问

追问一：你写的方案被否决过吗？

这是考你面对否定的态度。好的回答是：'被否决过。有一次我提了一个实时数据pipeline的方案，评审时技术负责人觉得投入太大，建议先用准实时（每小时跑一次增量ETL）验证业务需求，确认业务真的需要秒级实时后再上Flink。我当时觉得技术方案没问题，但后来想想他说的对——先验证需求的真实性，再决定投入的规模。这次经历让我学到了：好的方案不是技术最先进的方案，而是投入产出比最优的方案。'

追问二：你怎么评估一个方案的排期？

'我的排期方法是：先把方案拆成独立的子任务（开发、测试、联调、灰度、上线），每个子任务独立估时。然后在总时间上乘以1.3-1.5的buffer系数——因为实际执行中一定会遇到计划外的问题。比如EMR迁移，我拆成了环境搭建1周、SQL改写2周、灰度验证2-3周、切换收尾1周，加上buffer预估8周。实际花了8周多一点，比较准。关键是拆分要足够细——粒度越细估时越准。如果你说一个任务'大概3周'，那大概率不止3周。'

追问三：小团队需要方案评审吗？会不会太重了？

'小团队更需要方案评审，但形式可以简化。3-5人的团队不需要正式的评审会议，在钉钉或Slack里发方案文档让大家看，有问题直接评论，30分钟内讨论完就行。重要的不是形式，而是在动手前有人Review你的方案——因为小团队容错率更低，一个人做的决策如果有盲点，影响面可能更大。我在某出海硬件品牌3人团队时的做法是：大方案写文档评审（1页以上的），小方案在群里说一下思路让大家确认。'

实战踩坑

我写过一份让我印象深刻的'失败方案'。在某元宇宙社交应用时，我提了一个实时数据平台的方案——用Flink做全量实时处理，包括事实数据和维度数据。方案写得很详细，技术设计也没问题，评审时顺利通过了。

但上线后发现一个方案中没有考虑到的问题：维度数据用Flink处理非常浪费资源（第7篇讲过这个坑）。方案中只对比了'全部实时'和'全部离线'两个方案，没有考虑'混合方案'——事实数据走实时、维度数据走批量。

// 方案的盲点分析
 
// 我当时的方案只对比了：
// 方案A：全部数据走Flink实时处理
// 方案B：全部数据走Spark离线处理
// 结论：选A（因为业务要求实时）
 
// 遗漏的方案C：
// 事实数据（高频变化）→ Flink实时处理
// 维度数据（低频变化）→ 定时批量同步
// 如果当时考虑了方案C，就不会浪费资源
 
// 教训：方案对比不能非此即彼
// 真实世界的最优解往往是'混合方案'
// 评审时要主动问自己：有没有取中间值的方案？

教训：方案对比不要只列极端方案（全实时 vs 全离线），要考虑中间状态的混合方案。很多时候最优解不是非A即B，而是A+B的组合。面试时讲这个教训也是加分的——它展示了你从实践中总结出来的方案设计方法论。

总结

技术方案文档回答四个问题：为什么做、怎么做、有什么风险、效果怎么衡量。好的方案至少有2-3个候选方案和对比分析。方案评审的目的是发现盲点而不是走过场。面试时讲你写过什么方案、评审中被挑战过什么、怎么改进的，比讲你的方案多么完美更有说服力。最关键的能力是：在多个方案之间做权衡取舍，考虑混合方案而不是非此即彼。

下一篇是项目经验系列的终极篇：面试官问'如果让你从0搭建数据平台你怎么做'——这道架构题的满分答法

你写过技术方案文档吗？在评审中被挑战过什么印象深刻的问题？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长