电商开发
电商工程的成绩单，一年只由那么一两天来打分。一个三月份跑得飞快、却在黑五当天崩掉的平台，就是失败的，无论它的平均表现多好。我们构建和重构电商系统时，瞄准的是峰值而非均值，以及顾客最能察觉的那几个环节：结算、搜索，还有库存数字是不是真的。
电商系统通常痛在哪里
这些失效模式在不同企业间反复出现，而且很少出在商城前台本身。
- 结算流程在高负载下劣化，而那恰恰是流失代价最高的时刻。
- 库存与实际情况脱节，导致超卖与人工对账。
- 订单流程纠缠在商城平台、ERP 与仓储系统之间。
- 搜索与商品目录的性能问题，在无声无息中压低转化率。
为峰值而非均值做工程
以平均流量为依据做容量规划，等于保证峰值时出事。我们按贴近真实的峰值曲线做压测，找出系统实际会崩在哪里，然后修那里，而不是修那个看起来危险的地方。
- 在旺季之前、而不是之后，按真实的流量形态做压测。
- 在价格与库存变动时仍能保持正确的缓存策略。
- 优雅降级，让推荐服务出故障时也绝不阻断下单。
- 可观测性做得足够细，能在峰值当下诊断问题，而不是事后复盘。
换平台，但不赔上一整个旺季
把电商系统整体重写风险很高，因为截止日期是日历定的，不是你定的。我们更倾向渐进式替换——在稳定的接口背后，一次只迁移一项能力——这样在任何时刻都有一套能用的系统，也都有退路。
常见问题
- 你们能在现有电商平台上工作吗？
- 可以。大部分工作是扩展或对接已经在用的平台，而不是替换它们；而替换往往是对错误问题给出的、更昂贵的答案。
- 旺季之前你们能帮上忙吗？
- 能，而且越早越好。压测与整改需要时间；在峰值前几周开始的工作，价值远高于前几天才开始的工作。
- 你们如何保证库存准确？
- 先明确约定以哪套系统作为库存的权威来源，然后设计流程，让其他所有系统都向它对齐。大多数超卖问题的本质是归属权问题，而不是技术问题。