AI 存储异常检测：先定义指标拓扑，再谈智能告警
一、异常检测不是把指标丢给模型
存储系统指标非常多：QPS、延迟、IOPS、队列深度、锁等待、缓存命中率、compaction、复制延迟、磁盘利用率。把这些指标全部丢给模型，让它判断是否异常，通常只会得到含糊结论。AI 异常检测要想有效，必须先定义指标之间的拓扑关系。
例如写延迟升高可能来自磁盘队列深度，也可能来自锁等待、网络复制、后台 compaction 或上游突增。单个指标异常没有足够解释力，指标之间的因果链才有排障价值。模型适合做候选归因，但输入必须是结构化指标和系统拓扑。
二、指标拓扑：异常要能沿链路追踪
flowchart TD A[业务写入延迟] --> B[存储引擎写入] B --> C[WAL fsync] B --> D[锁等待] B --> E[后台 compaction] C --> F[磁盘队列深度] E --> F D --> G[事务冲突]建立拓扑后，异常检测可以分层。入口层关注业务延迟和错误率；引擎层关注锁、缓存、事务和后台任务；资源层关注 CPU、内存、磁盘和网络。只有当这些层级串起来，AI 才能给出“可能是 compaction 抢占磁盘带宽”这种可验证假设。
还要区分周期性波动和异常。日常备份、报表任务、冷热数据切换和业务高峰都会造成指标变化。如果模型不知道周期和变更记录，就可能把正常波动判成故障。异常检测系统应纳入发布、迁移、备份和容量变更事件。
三、输入结构：让模型看到证据而不是噪声
下面是一个简化的异常事件输入结构。它比原始指标更适合模型分析。
{ "window": "2026-07-02T10:00:00+08:00/2026-07-02T10:10:00+08:00", "symptom": "write_p99_latency_increase", "metrics": { "write_p99_ms": [42, 48, 310], "disk_queue_depth": [3, 4, 38], "lock_wait_ms": [2, 3, 4], "compaction_bytes_per_sec": [120, 130, 980] }, "changes": ["no deploy", "daily backup finished"] }模型输出也要结构化，至少包括根因候选、证据字段、置信度和下一步验证命令。没有证据引用的判断不应进入告警页面。存储故障里最讨厌的不是没有结论，而是一个看似自信但无法验证的结论。
指标采样粒度也要谨慎。粒度太粗会掩盖尖刺，粒度太细会引入噪声。可以对入口延迟保留更细粒度，对资源指标做窗口聚合，再结合异常时间点前后对比。数据预处理比模型选择更影响效果。
四、落地边界：AI 负责排序，人负责动作
AI 异常检测适合做告警归并和候选排序，不适合直接执行高风险动作。比如自动限流、自动切主、自动暂停 compaction，都可能引入二次事故。可以先让模型生成建议，再由规则系统或人工确认执行。
评估时不要只看召回率。误报率、根因排序准确率、平均定位时间、建议采纳率和误导性建议比例都要记录。存储值班人员不需要更多噪声，他们需要更少但更准的线索。AI 如果把告警页面变得更吵，就是失败。
最后，异常样本要持续回流。每次真实故障复盘后，把最终根因、有效指标和误导指标写入案例库。模型下次遇到类似波形时，才能基于历史证据给出更稳定的建议。
五、总结
AI 存储异常检测的前提是指标拓扑和结构化证据。先把业务症状、引擎指标、资源指标和变更事件串起来，再让模型做归因候选。智能告警的目标不是替人操作系统，而是更快给出可验证线索。
