作为技术负责人，我会先把**“用户增长十倍”转换成预期使用量、服务目标和团队能交付的计划**。注册账户数量并不能直接说明最繁忙时有多少请求。
假设业务准备为订单平台开展推广。问题是：在现有时间和预算下，活动期间客户能否继续浏览、购买并收到确认。
向产品团队了解用户何时到来、会做什么。一年内逐步增长，与活动瞬间把所有人带上线，完全不同。
举例来说，十万个注册账户中有 1% 同时活跃，就是一千个并发用户；5% 则是五千个。这些只是示例假设，不是默认比例。请求频率和每个请求的工作量还需要估算。
列出活动产生的负载：
这样得到的是可以测试的负载，而不是简单要求服务器数量乘以十。
为关键流程定义可接受的响应时间、错误率和完成情况。必要时也要规定数据时效与恢复要求。报表稍晚可能可以接受，结账失败则不行。
[Campaign assumptions] -> [Expected workload] -> [Service targets]
|
[Acceptance tests]
这些目标把技术工作连接到客户结果，让团队判断改善是否足够，以及高压时哪些降级可以容忍。
结合生产观察和有代表性的负载测试，检查慢查询、数据库连接、CPU、内存、队列等待时间和外部服务配额。测试要包含热门商品的流量倾斜，而不只是随机请求。
如果数据库连接是瓶颈，增加应用节点可能加剧竞争。如果支付服务商配额是限制，应用提速也不会自动提高配额。
除了正常运行，还要测试冷缓存和实例丢失。需要的是活动期间能够恢复的容量，而不只是理想测试中勉强够用。
| 发现 | 候选措施 | 所需证据 |
|---|---|---|
| 重复的高成本读取 | 优化查询或缓存合适结果 | 数据足够新鲜，同时数据库工作减少。 |
| 后台任务争抢购买资源 | 限制或隔离后台容量 | 后台高负载时结账仍正常。 |
| 下游配额不足 | 申请增加或控制准入 | 已确认配额，并测试达到上限时的行为。 |
| 小改进后容量仍不足 | 评估扩容或更大的设计变更 | 实测收益、迁移计划与成本。 |
每项工作都要有负责人、预算、依赖、截止日期和验收测试。除实现外，还应包括部署、运维培训和轮值准备。
按客户影响和交付风险排序。大规模重写或分片项目需要明确证据，也需要足够的迁移和验证时间。
分批发布可控的改动，将预期用户流程一起测试。规定何时扩大流量、暂停扩大或回滚。数据格式变化可能需要向前修复，而非简单回滚。
准备可控降级：推迟可选导出、限制后台工作，或拒绝超额请求以保护关键操作。验证这些措施确实减轻负载，并向客户给出明确结果。
如果目标无法在期限或预算内完成，应向产品提出具体选择：分阶段引流、减少昂贵功能，或为实测瓶颈投入资源。解释每种选择的客户影响和不确定性。
**记住：**增长假设 → 服务目标 → 实测上限 → 明确负责人的路线图 → 演练后的发布。技术负责人交付的容量计划还应涵盖人员、资金和恢复。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠