3. 医疗平台容量规划方法论

容量规划不是“买多少台服务器”的采购问题，而是一套把业务需求、服务水平、资源供给、成本与合规约束统一起来的决策方法。医疗平台的特殊性在于：它同时承载门诊挂号、住院医嘱、检验检查、影像调阅、互联网医院、医保结算等多类业务，既有明显的早高峰，也有 7×24 小时不可中断的急诊与重症场景。因此，容量规划必须回答四个问题：容量如何定义、服务水平如何量化、需求如何建模、在成本与合规约束下如何决策。

一、容量定义：从“资源量”转向“可承载业务量”

在医疗平台中，容量不能只定义为 CPU 核数或存储 TB 数，而应定义为“在满足 SLO 前提下，单位时间内可稳定完成的业务量”。常用三层定义：

• 业务容量：如“挂号并发 3000 笔/分钟”“影像调阅 800 次/分钟”“医嘱写入 500 TPS”。
• 服务容量：单个微服务或接口的 QPS、P95 延迟、错误率上限。
• 资源容量：CPU、内存、连接数、IOPS、带宽、存储容量等底层指标。

三层之间通过“单位业务消耗资源”建立换算关系。例如某三甲医院互联网医院示例（以下为合理假设的教学参数）：一次挂号请求平均消耗 12 ms CPU、约 3 KB 数据库写入；一次影像调阅消耗 80 ms CPU、约 25 MB 内网带宽。只有把业务量翻译成资源量，容量规划才可计算、可验证。

二、服务水平目标（SLO）：把“不能卡”变成可测量指标

SLO 是容量规划的目标函数。医疗平台通常按业务等级设定差异化 SLO，而不是全站统一。示例：

SLO 必须配套 SLI（指标）和错误预算。例如 P1 挂号接口月度错误预算 = (1 − 99.95%) × 30 天 ≈ 21.6 分钟不可用。容量规划的目标不是“永不超限”，而是让资源供给使错误预算消耗速率处于可控范围。

三、容量模型：从历史数据到可推演的需求曲线

容量模型的核心是把“业务量—资源量—SLO”三者关联起来。常用方法包括：

1. 基线测量：采集至少 4 周的历史数据，按 5 分钟粒度统计 QPS、P95 延迟、CPU、连接数。
2. 峰值识别：区分日高峰（如 8:00–10:00 挂号）、周高峰（周一门诊）、季节高峰（流感季、体检季）。
3. 单实例容量标定：通过压测确定单 Pod 在满足 SLO 下的最大 QPS。例如挂号服务单实例在 P95 ≤ 500 ms 时最大 180 QPS。
4. 需求预测：用“基线 × 增长系数 × 峰值系数”估算未来容量。示例：当前峰值 1200 QPS，年增长 25%，峰值系数 1.8，则次年峰值 ≈ 1200 × 1.25 × 1.8 = 2700 QPS。
5. 实例数计算：实例数 = 峰值 QPS ÷ 单实例容量 × (1 + 冗余)。上例中 2700 ÷ 180 × 1.3 ≈ 20 个实例。

模型必须定期回测：用实际峰值验证预测偏差，偏差超过 20% 时修正增长系数或单实例容量。

四、规划周期：短、中、长三层节奏

医疗平台容量规划通常采用三层周期：

• 短期（周/日）：基于实时监控做弹性扩缩容，应对当日门诊高峰或临时义诊。
• 中期（季度）：结合业务排期（新院区上线、互联网医院推广）做资源预留和压测验证。
• 长期（年度）：结合医院战略、医保政策、评级要求，做机房、专线、存储池的资本性规划。

三层周期通过“容量看板”联动：短期指标触发告警，中期指标触发扩容工单，长期指标触发预算立项。

五、成本与合规约束下的决策框架

医疗平台的容量决策受两类硬约束：成本约束（预算有限，资源不能无限冗余）和合规约束（等保、数据不出院、灾备 RTO/RPO、电子病历留存年限）。决策时可按以下优先级排序：

1. 先满足 P0 业务的 SLO 与合规要求，再考虑 P1、P2。
2. 优先用弹性扩缩容消化可预测峰值，用预留实例覆盖基线负载。
3. 对合规要求“数据不出院”的系统，容量必须按本地机房上限规划，不能依赖公有云弹性。
4. 对灾备容量，按 RTO/RPO 反推备用资源，而不是简单按生产 1:1 配置。

把上述框架落到日常工作中，容量规划的输出不是一份静态报告，而是一组可执行的决策：P0 业务保留多少冗余、P1 业务弹性策略如何配置、P2 业务在预算紧张时如何降级、合规约束下哪些资源必须本地预留。只有把容量定义、SLO、模型、周期和约束串成闭环，医疗平台才能在业务增长与资源有限之间保持稳定、可解释的平衡。