从被动救火到容量规划：Castrel 如何预测磁盘增长趋势

存储从不停止增长，但很少有团队能够回答一个比"现在的使用率是多少"更有价值的问题。

运维团队真正需要知道的是：当前增长趋势是否可持续、容量大概什么时候会达到风险阈值，以及某次突然变化究竟是正常的业务增长，还是一次运维操作。如果缺少这些答案，容量管理就只能停留在被动响应：盯着仪表盘，等待静态阈值告警，然后临时清理文件或申请扩容。

容量规划应该反过来进行。它应该从一条经过测量的增长基线开始，将基线转化为预测，再把预测结果连接到具体决策——继续观察、展开调查，还是开始扩容。而更关键的是，这个过程不应该依赖运维人员记得去检查，而是应该由 Agent 自主、持续地执行。这正是 Castrel 要解决的问题。

真正的问题：阈值告警往往来得太晚

多数团队依赖"周期性人工巡检 + 静态阈值告警"的模式管理磁盘容量。运维人员通过监控平台查询各主机或数据中心的磁盘使用情况。当某个分区越过预设阈值后，告警才会触发。随后有人登录主机、搜索大文件，并凭借经验判断这究竟是正常的业务增长，还是日志、备份堆积等其他问题。

如果判断结果是需要扩容，下一步通常是粗略估算所需容量，再提交预算和采购申请。如果问题看起来只是暂时性的，响应方式则是手动清理过期日志、无效备份或孤儿文件。当处置来得太晚，分区被占满，业务就会直接受到影响：写入失败、数据库挂起，甚至需要立即展开事故救火。

这种模式存在三个结构性短板：

• 它只能观测当前状态，却无法量化当前趋势会走向哪里。
• 它无法可靠地区分平稳增长和突然变化，因此很难判断告警优先级。
• 容量申请缺少可复核的时序证据，难以说明需要多少容量以及什么时候需要。

随着实例规模增长，人工巡检的工作量也会增加。团队很容易陷入"告警 → 临时清理 → 再次告警"的循环，而真正可能影响业务的中断风险始终存在。

因此，运维真正需要回答的问题不只是**"容量是否已经越过阈值？"，还包括"按照当前增长趋势，什么时候会越过阈值？如果趋势突然变化，又是什么原因导致的？"**

从原始指标到增长基线

在一个典型场景中，运维团队希望比较各数据中心的磁盘容量增长趋势，并确定哪些站点需要优先关注。Castrel Agent 可以直接读取 Prometheus 兼容的指标——例如 disk_capacity_bytes{datacenter="phx1"}——而不需要运维人员逐台主机手动拉取数据。

在本次运行中，Castrel 使用了 2025-07-01 至 2025-08-30 的约两个月每日采样数据，采样步长为 86,400 秒。系统采用 7 天季节性周期的 Holt-Winters 模型，对 2025-09-01 至 2025-09-30 生成 30 天预测，并给出 95% 预测区间。

在继续之前，需要明确几个关键概念的区别：

• 总容量（Capacity）：数据中心可用的磁盘总空间。
• 已使用容量（Usage）：实际被占用的磁盘空间。
• 使用率（Utilization）：已使用容量 / 总容量，表示磁盘填充程度。
• 预测区间（Prediction Interval）：预测值可能波动的范围，反映的是预测的不确定性，而不是预测的准确率。

本次实验的训练数据来自 disk_capacity_bytes，即各数据中心的磁盘总容量。这意味着模型预测的是容量基线的变化趋势。后文将进一步展示如何将容量预测与使用量数据结合，推导出完整的容量风险时间线。

输出结果不只是一个月末数字，而是包括：

• 每个数据中心的预测增长轨迹；
• 预测区间的上下界，表示预测的不确定性范围；
• 预测期内的实际值，以便验证预测结果，而不是默认预测一定正确。

预测效果验证

一个有意义的预测评估，需要把两种在图表上看起来相似、但在运维含义上不同的情况区分开：

1. **自然增长：**容量按照历史规律变化。在这种情况下，预测误差反映的是模型对增长趋势的捕捉能力。
2. **容量基线变化：**预测期间发生了人为扩容或下线。这类偏离不能简单归因于模型预测能力，因为预测期间被预测对象本身发生了结构性变化。

生成的报告保留了每个站点的每日预测值、预测区间和实际值，因此这两种情况可以被复核和区分。

预测准确性

需要特别说明的是：预测准确性和预测区间是两个不同的概念。95% 预测区间描述的是未来值可能落入的范围，它反映预测的不确定性；而预测准确性衡量的是预测值与实际值之间的偏差程度。

下表使用报告中已有的月末预测值和实际值来评估预测准确性。误差百分比按 (实际值 - 预测值) / 预测值 计算。

对于三个自然增长的站点——phx1、sac0 和 yyz1——月末值的平均绝对百分比误差（MAPE）约为 0.45%，最大绝对误差为 1.18%。在本次时间窗口和这组样本中，这表明模型较好地捕捉到了自然容量增长趋势。

另外三个站点的偏离主要源于预测期间容量基线发生了结构性变化——人为扩容或下线磁盘改变了被预测的对象本身。这类偏离不能简单归因于模型预测能力不足。它的价值在于：当 Agent 检测到实际值显著偏离预测趋势时，可以提示运维人员结合变更记录进一步调查原因，而不是直接将其视为模型预测失败。

需要说明的是，当前验证仅基于月末端点值。如果需要更全面的评估，可以扩展到整个预测周期的逐日误差分析。当前样本量限定了结论的适用范围，但已足以说明：预测结果是可以量化评估的，而且评估时需要将自然增长与容量基线变化区分开来。

从容量预测到容量风险倒计时

容量预测回答的是"未来 30 天增长趋势是什么"，但运维真正关心的问题是："按照当前趋势，什么时候会进入容量风险区间？我还有多少时间准备扩容？"

要回答这个问题，需要将容量预测与使用量数据结合，计算容量阈值到达时间。

以 phx1 数据中心为例。截至 2025 年 9 月 30 日，phx1 的容量与使用量状况如下：

运维团队通常会设置两级容量阈值：

• 80% 规划阈值——进入容量预警区间，应启动扩容评估和预算规划。
• 90% 风险阈值——进入紧急风险区间，必须立即执行扩容或清理操作。

基于当前使用率和近期增长趋势，Agent 可以计算出：

这意味着 phx1 当前并未进入紧急风险状态，而是拥有约 46 天进入规划阈值的准备窗口。运维团队可以在这段时间里完成扩容评估、预算审批和硬件采购。从 80% 规划阈值到 90% 风险阈值之间还有约 58 天的风险缓冲期——这是从"应该开始规划"到"必须完成扩容"之间的实际行动窗口。如果增长速度突然加快，这些窗口会相应缩短——这正是 Agent 需要持续监控并动态更新预测的原因。

Agent 最终给出的容量风险评估如下：

phx1 风险评级：中等

当前使用率 72.0%，预计 46 天后达到 80% 规划阈值（约 2025 年 11 月中旬）。建议在未来两周内启动扩容评估，确保在进入预警区间前完成容量规划。如果增长速度持续高于日均 2,700 TB，风险窗口将进一步收窄，Agent 将在下一次巡检中更新预测并调整风险等级。

预测算法负责回答"增长趋势是什么"，而 Agent 负责把趋势预测转化为**"还有多少天、需要做什么"**这个运维团队真正需要的答案。

Agent 相比预测算法多做了什么

一个预测算法主要回答一个问题：

给定这条时间序列，未来可能会呈现什么趋势？

一个独立的 Holt-Winters 实现可以接收一条时间序列，返回预测值和预测区间。但它不会自行决定查询哪些指标、对多个数据中心分别运行分析、将预测与实际值逐一比较、调查偏离原因，或者把这些发现转化为运维建议。

更重要的是，一个预测算法不会自己决定什么时候运行。它需要有人主动发起调用。

Agent 的核心差异不是把预测算法前后串联起来，而是能够围绕容量管理目标自主理解问题、获取信息、选择分析方式、解释结果并做出下一步决策。

自主分析与决策

在本次示例中，Agent 完成了以下工作——不是按照预定义的固定流程，而是根据当前问题和数据自主判断每一步该做什么：

1. 理解任务。 判断当前需要回答的是趋势问题、风险问题还是规划窗口问题，据此决定需要哪些数据和分析方式。
2. 获取数据。 根据问题需要，自主查询监控系统中的相关指标、时间范围和数据中心维度。
3. 逐站点分析。 对每个数据中心分别运行预测，而不是把整个集群当成一条无差别的时间序列。
4. 验证预测结果。 计算预测误差，并结合预测区间识别实际值是否出现显著偏离，区分自然增长和容量基线变化。
5. 计算容量风险。 将使用量趋势与总容量结合，推算各站点的阈值到达时间和剩余规划窗口。
6. 识别高风险站点。 按照风险窗口长短对站点排序，标记需要优先关注的数据中心。
7. 进一步调查。 当增长速度突然变化或实际值显著偏离预测趋势时，自主决定是否需要获取更多信息来分析原因。
8. 形成决策。 生成包含风险评级、阈值到达时间、规划窗口和行动建议的容量规划报告。

持续自主巡检

Agent 的另一个关键差异在于：它不需要等待人工触发，而是可以通过定时巡检机制自主启动容量分析。

定时巡检只负责触发 Agent，之后的分析过程完全由 Agent 自主决定：

flowchart TD
    A["定时巡检触发（每天/每周）"] --> B["Agent 理解当前容量状态"]
    B --> C["自主判断需要获取哪些监控数据"]
    C --> D["自主判断哪些站点需要进一步分析"]
    D --> E["必要时调用预测能力"]
    E --> F["结合预测结果和已有知识判断容量风险"]
    F --> G["自主决定是否需要进一步调查"]
    G --> H["形成容量规划建议"]
    H --> I{"风险等级"}
    I -->|"高风险"| J["主动通知运维团队"]
    I -->|"低风险"| K["记录并持续监控"]
    J --> L["下一周期再次触发"]
    K --> L
    L --> A

这意味着即使没有人主动询问"磁盘容量还够用吗"，Agent 也会定期发现问题、更新预测、判断风险，并在必要时主动推送通知。如果上一周期预计某站点 45 天后达到规划阈值，但本周期发现增长速度加快，预计缩短到 27 天，Agent 会自动上调该站点的风险等级，并建议提前启动扩容准备。

这改变了运维团队讨论容量问题的起点。团队不必等到"磁盘已满"后再追问发生了什么，而是可以围绕一条经过测量的增长轨迹、一个预计的规划日期、该日期的不确定性，以及支撑判断的证据展开讨论。并且这个过程不是一次性分析，而是一个持续运行、持续更新的闭环。

这才是 Agent 和预测算法之间的根本差异：

• 预测算法："给我一条时间序列，我告诉你未来趋势。"
• Agent："我会自己去理解当前状况、获取需要的数据、判断是否需要预测、解释预测结果、评估风险、给出建议，并且持续重复这个过程——不需要有人记得来问我。"

从一条预测曲线到一个容量规划决策

1. 从历史监控数据识别容量增长趋势。 Agent 可以直接读取 Prometheus 指标，获取多个数据中心的历史容量数据。
2. 对未来容量进行可量化的预测。 在自然增长的三个站点中，月末平均绝对百分比误差（MAPE）约为 0.45%，最大绝对误差为 1.18%。
3. 识别容量趋势中的异常偏离。 当实际增长明显偏离预测趋势时，Agent 可以结合预测区间和相关信息进一步分析，并为后续调查提供依据。
4. 计算容量阈值到达时间和剩余规划窗口。 将使用量趋势与总容量结合，推算出各站点达到 80% 和 90% 阈值的预计日期和剩余天数。
5. 识别高风险数据中心并给出容量规划建议。 包括风险评级、规划窗口和具体的行动建议。
6. Agent 自主完成数据获取、分析、预测、风险判断和报告生成。 不是按照固定流程执行，而是根据当前问题和数据自主决定下一步动作。
7. Agent 通过定时巡检持续运行。 每个周期自主更新预测、重新评估风险，而不是等待人工触发。

这套方法的价值，不只是预测图表中的一条曲线。它改变的是容量管理的工作方式：

从被动等待容量告警，转变为 Agent 主动发现容量风险，并提前给出可量化的容量规划窗口。

预测算法提供统计意义上的增长估计。Agent 将这种预测能力嵌入到一个能够自主理解、自主分析、自主决策和持续运行的容量管理场景中——从一次性的模型调用，变成了一个可以自主运行、自主更新、自主预警的容量规划系统。