算出何时写满 — 自然增长、台阶与下单截止日

一句话总结

容量规划的答案不是“现在是百分之几”，而是“最晚什么时候之前必须下单什么”。这个日期由三个数字决定——平时增长的速度（自然增长）、不能越过的线（阈值）、从下单到安装所需的时间（交付周期）。如果把只发生一次的大幅增长（阶跃）混进趋势里，预测就会整个出错。

为什么需要它

等磁盘用到 95% 才申请扩容就已经晚了。服务器和存储从下采购单、发货、上架作业到确保作业窗口，要花上几周，云上的预留容量或预算审批也需要时间。所以容量负责人要回答的不是“现在还好吗”，而是“下单按钮最晚什么时候必须按下”。

Google SRE 书的前言提到，容量规划需要准确的自然增长需求预测、把新功能上线或客户迁移这样的非自然增长需求单独计入，以及预见超过采购交付周期的时间跨度。本模块通过一张磁盘使用量表，让这三点上手。

工作原理

趋势线。 把每天测一次的使用量，以 x = 从第一天起的天数、y = 使用量（GB）画出最小二乘直线。斜率由下式给出。

기울기 = Σ (x − x̄)(y − ȳ) / Σ (x − x̄)²        단위: GB/일

该代码块中的韩文内容说明：等号左边是斜率，行末标注的单位是 GB/天。

用 Excel 的 SLOPE，或 Python 的几行代码就够了。直线虽粗糙，但周末积累得少、工作日积累得多这样的波动，汇总几个月的数据后，对斜率几乎没有影响。

剥离阶跃。 画出表格会发现，有某一天出现了几百 GB 一次性增长的位置。那是迁移旧服务器的数据、接收了新客户或延长了日志保留期限的日子。这是不会再次发生的事。如果对整个时间段画直线，这个阶跃就会混进斜率，被翻译成“每天增长这么多”，预测就会比实际悲观得多。所以要找出单日增幅最大的那一天，只用那天之后的数据重新求斜率。如果有未来已经计划好的阶跃（下个月的迁移计划），不要混进趋势里，而是单独加上去。

剩余天数。 如果阈值是 80%，剩余天数是 올림((용량 × 0.8 − 지금 사용량) ÷ 기울기)（韩文，依次意为“向上取整”“容量”“当前使用量”“斜率”）。对 100% 也用同样的式子求出，就能说明“越过阈值之后还能撑多久”。向上取整是为了把“几天后”估得保守。

下单截止日。 임계 도달일 − 리드 타임（韩文，依次意为“阈值到达日”“交付周期”）就是最晚必须下单的日子。如果这个日期已经过去，或只剩几天，就应该成为报告的第一行。

阈值为什么不是 100%。 文件系统在写满之前很久就会变慢（碎片化、保留块），数据库整理作业需要空闲空间，而且预测永远可能出错。阈值与 100% 之间的间隔是吸收预测误差和突发增长的缓冲。所以计划按阈值制定，而到 100% 的剩余天数，用来说明“预测错了的话能撑多久”。

数字	来源	错了的后果
自然增长斜率	阶跃之后的趋势线	混入阶跃会造成过量订购，忽略增长会造成缺货
阈值	运维标准（余量、性能下降点）	定得太高就没有时间应对
交付周期	采购、运输、作业窗口	估得太短，下单就会晚

在现场相遇的样子

最常见的失误是原样相信监控画面上的“预测”。许多工具用最近几天甚至几小时的斜率画线。昨天备份文件一下子堆了上来，就会显示“3 天后写满”，第二天清理完了，又显示“400 天后”。没有确认是用哪个时间段画的线，这样的预测不是数字而是噪声。

第二种是不知道阶跃。迁移刚结束时的报告说“增长率变成了三倍”，有人就用这个数字编制一年的预算。反过来，如果漏掉下个月计划的迁移，趋势看起来一切正常，却在某一天突然不够用。所以容量报告要把趋势（自然增长）和计划内的事（非自然增长）分开写。

也要知道直线出错的情形。 如果是用户增加、增长速度本身也在加快的服务，直线总是警告得太晚。这时要把最近区间的斜率和整体斜率并排写出来，显示出加速，并给交付周期多留余量。反过来，像有保留期限策略的日志卷这样，旧数据被清除、逐渐趋于平衡的数据，直线会过分悲观。与其把预测模型做得精细，不如先在报告里用一行说明这条线是基于什么假设画的。

第三种是每个月都用手算同样的东西。如果做成即使表格变了也能给出相同答案的小脚本，下个月只要一条命令，别的卷也可以直接用。

下一项实验要做什么

拿到 120 天的磁盘使用量表和运维标准（容量、阈值、交付周期）。写下当前状态，求出整个时间段的斜率，再找到出现阶跃的那一天，重新求出其后的自然增长斜率。计算阈值和到 100% 的剩余天数以及下单截止日，最后把这套计算做成能对任意表格运行的脚本。评分器每次评分时，都会把该脚本也在新生成的表格上运行。