悠悠楠杉
网站页面
虚拟化与云计算硬核技术内幕(32)——产品经理与潘金莲
07/23
当产品经理遇上"潘金莲式需求"
某互联网大厂的会议室里，空气凝固得像过了期的虚拟机快照。
"这个需求必须用Kubernetes集群实现！" 业务部门代表拍着桌子，像极了《水浒传》里逼武大郎喝药的潘金莲，"客户说了要弹性伸缩，你们用传统虚拟机就是糊弄！"
云计算架构师老王推了推眼镜，心里暗骂："这特么和西门庆非要穿防弹衣逛青楼有啥区别？"
一、需求背后的"砒霜馅饼"
所有不合理的技术需求，往往披着华丽的外衣：
- 伪场景绑架："抖音都在用Serverless"（但没说人家日活千万）
- 参数竞赛："AWS的实例类型有487种"（虽然客户只用得起t3.micro）
- 未来幻想："我们要做第二个淘宝"（当前日订单量23单）
就像潘金莲给武大郎喂药时说的"大郎该吃药了"，产品经理常听到的潜台词是："这个需求很简单"（但我要的是ChatGPT的能力）。
二、技术决策的"武松式破局"
真正的架构师应该像武松那样直击要害：
- 需求脱敏
- 用5W2H分析法拆解：Who: 真实用户是谁？（不是领导的领导）
Why: 核心要解决什么？（不是PPT第42页的饼状图）
How much: 愿意付出多少成本？（包括技术债）
技术选型四象限
| 用户价值\实现成本 | 高成本 | 低成本 |
|----------------|-------|-------|
| 高价值 | 自研云原生方案 | 采用托管服务 |
| 低价值 | 直接拒绝需求 | 用Shell脚本应付 |反杀话术模板
- "您说的对，不过...（引用Gartner报告第7章）"
- "这个功能需要（3个SRE+每年$200k云账单）"
- "我们建议先做（实际可落地的MVP方案）"
三、从《水浒传》看云原生架构
潘金莲的故事本质是资源错配引发的系统崩溃：
- 武大郎 = 传统单体架构（卖炊饼的垂直业务）
- 西门庆 = 过度设计的微服务（绸缎庄连锁业务）
- 砒霜 = 技术负债（强上K8s的运维代价）
而武松的解决方案堪称经典架构设计：
1. 取证（日志分析）
2. 锁定关键节点（景阳冈数据库事务）
3. 一击必杀（kill -9西门庆进程）
四、产品经理的自我修养
避免成为"技术潘金莲"的三条军规：
需求分层
- 表面需求："要能自动扩容"
- 真实需求："别在促销时宕机"
- 本质需求："保住我的年终奖"
成本意识
- 每次说"云原生"前先计算：
技术复杂度成本 = 团队学习曲线 × 故障恢复时间 机会成本 = 本可做的其他功能 × 业务价值
- 每次说"云原生"前先计算：
反脆弱设计
- 像武松打虎那样留后手：
- 部署方案必须有
Rollback Plan - 关键组件保持
Degrade Mode - 监控系统要比县衙的鼓更灵敏
- 部署方案必须有
- 像武松打虎那样留后手：
后记：
最近某车企云平台崩溃事故，本质就是产品经理听了"潘金莲式需求"——为展示技术实力强上Service Mesh，结果链路追踪直接把控制平面压垮。这告诉我们：
技术选型如大郎喝药，
看似大补实则穿肠，
唯有实事求是，
方得架构安康。
