容量规划

编制人：陈静

审核人：张伟

规划范围：六个办公点，合计 3,200 人

编制日期：0000-00-00

状态：已审核

一、峰值假设

平台当前只服务总部 420 人。10 月起按办公点分批开放：研发园 860 人、仓储园 640 人、华东办事处 480 人、华南办事处 450 人、成都办事处 350 人，加上总部共 3,200 人。总部 9 月预订峰值约 4 QPS，出现在 9:00 至 9:05。六地上班时间前后相差约 15 分钟，合并峰值按 25 QPS 估算，请假列表按 70 QPS 估算。各地行政在 9月10日汇总了办公点人数，张伟于 9月12日确认按该峰值备容。

二、容量目标

1. 预订创建在 40 QPS 下持续 15 分钟，P99 不超过 300 毫秒，错误率不超过 0.1%。
2. 请假列表在 70 QPS 下，P99 不超过 250 毫秒，查询落在只读副本。
3. 主库 CPU 在峰值小时不超过 65%，连接数不超过连接池上限的 70%。
4. 企业微信发送排队不超过 200 条，最老一条的等待不超过 1 分钟。

三、现状与缺口

主库本身有余量，压力主要来自请假列表和导出打在主库上。列表改走副本后，主库预估 CPU 可以从 78% 降到 55%。Redis 只保存会议室占用和限流计数，容量充足。通知若继续同步发送图片，线程会被占满，因此六地开放前要先改成异步。

四、扩容安排

1. 9月28日 22:00，周敏把生产实例从 2 台扩到 4 台，规格保持 4 核 8 GB，扩完后观察 20 分钟再离开。
2. 9月26日 21:40，李莉在低峰执行列表索引，并把请假查询切到只读副本。切换后抽 20 次列表，延迟目标低于 200 毫秒。
3. 9月30日前，刘洋把到达提醒和审批消息改为异步发送，队列长度超过 200 条时自动降速。
4. 10月7日 18:00，王芳在预发按 40 QPS 复测 15 分钟，陈静对照本文目标签字。

五、分工与费用

增加 2 台实例按 30 天估算，云资源费用约 2,400 元，张伟已在 9月14日邮件中确认。李莉负责数据库和副本切换，周敏负责实例，刘洋负责通知异步，王芳负责复测，陈静负责对照目标验收。费用计入产品研发中心本季度基础设施预算，不另立项目。

六、风险与应对

1. 只读副本延迟超过 1 秒时，请假列表自动改查主库。李莉把自动回切的连续时间限制在 10 分钟，超过后由值班人改为分页并通知她。
2. 实例扩容选在 9月28日 22:00，避开白天预订。若扩容后健康检查连续 3 次失败，周敏把新实例移出负载，旧的 2 台继续服务。
3. 若 10月7日复测达不到 40 QPS，张伟决定首批只开放研发园，其余办公点顺延一周，并提前通知各地行政。