最近看到一个消息Sequoia 孵化的 Empirik 出来独立运营拿到 2100 万美元种子轮融资方向是预测系统故障。这类公司不是第一家也不会是最后一家但它让我想到一个更实际的问题预测系统故障在工程里到底怎么落地单纯看融资新闻很容易把“预测故障”当成一个黑盒魔法但真正做基础设施和运维的人更关心的是需要哪些数据用什么模型提前多久报警误报率怎么控制以及模型跑起来之后团队能不能接得住。这篇文章不谈 Empirik 内部技术细节目前公开信息有限只从一线稳定性和 AIOps 实践出发把一套可验证的故障预测流程拆开讲。1. 先搞清楚“预测系统故障”预测的是什么预测系统故障听起来很吸引人但落到工程里第一步不是选模型而是定义清楚到底要预测什么。定义不清晰后面所有工作都会变成做实验而不是做系统。1.1 故障预测不等于“告警阈值 异常检测”传统告警是“当前值超过阈值就报警”比如 CPU 超过 90%、内存使用率超过 85%、错误率超过 5%。这些规则有价值但本质是检测“已经发生或正在恶化的状态”。异常检测往前走了一步它会根据历史分布判断当前数据是否偏离正常模式比如延迟从 200ms 变成 350ms虽然没超过硬阈值但已经偏离常态。故障预测再往前一步它试图在故障真正发生之前根据趋势、周期、事件和上下文推断未来一段时间会不会出问题。举个例子磁盘使用率当前是 75%按过去几小时的增速预计 12 小时后会写满。传统告警可能在 90% 才触发留给你 1 小时故障预测则可能在 75% 的时候就告诉你“还有 12 小时窗口可以清理日志或扩容数据盘”。所以故障预测的核心不是“发现异常”而是“拿到一个可干预的时间窗口”。这个窗口是预测模型最有价值的产品形态。不过也要强调一下预测系统故障不是一个单独模型能完成的事。它通常要组合多条数据链路比如指标趋势、日志错误频率、部署事件、变更记录甚至业务流量周期。单看某一个指标很容易误判。1.2 哪些故障值得预测哪些故障预测不了不是所有故障都能预测。我把常见故障分成两类一类是渐进式、有前兆的一类是突发式、几乎没前兆的。前一类适合做预测后一类更适合做防护和快速恢复。适合预测的故障类型通常有几个特征有连续的时间序列比如 CPU、内存、磁盘、inode、JVM GC 暂停时间、连接池占用。有明确的增长或衰退趋势比如错误率持续上升、队列长度不断积压、慢查询数量线性增加。有周期性可参考比如每天固定时间流量上涨提前扩容能避开过载。典型的例子包括磁盘写满、内存泄漏、连接池耗尽、削峰场景下响应时间飙升、批量任务导致资源竞争。这些场景里故障发生前往往有数分钟到数小时的渐变过程预测的价值就很明显。不适合预测的故障包括代码逻辑突然变更引发的空指针、配置中心误推送、人为误操作、突发的网络分区以及瞬时流量超过容量上限导致的全局限流。这些事件通常没有可学习的渐进信号依赖的是变更管理、混沌工程、快速回滚和冗余设计。很多团队一开始就想用机器学习预测“所有故障”这是不现实的。我建议第一批试点只选 1 到 2 个具有明显趋势的故障类型比如磁盘耗尽或服务错误率持续上涨。把这一类跑通之后再评估是否扩展到其他场景。2. 主流做法与数据形态从指标到时间线要让模型学会预测故障数据形态比模型算法更关键。现实情况是大多数团队并不缺数据缺的是“对齐后的时间线”。2.1 指标、日志、事件、调用链先统一时间线故障很少是单一指标造成的。比如一个服务从正常到不可用往往伴随着 QPS 下降、P99 延迟升高、线程池活跃线程数增加、错误日志增多、节点重启时间点前后有部署事件。单独看任何一个指标都可能漏掉前兆。所以第一步就是把数据放到同一个时间轴上。需要注意的数据类型大致有四种数据类型例子典型用途指标CPU、内存、磁盘、网络、QPS、错误率、GC 耗时刻画系统负载和资源状态日志error 日志、warn 日志、超时日志、慢查询日志定位异常事件和异常频率事件部署、配置变更、扩缩容、重启、开关切换解释指标变化的原因调用链服务间延迟、依赖调用成功率、数据库耗时判断故障是本地还是依赖引起在构造训练数据之前我一般会先做一次数据盘点。确认这些数据是否都有时间戳时间格式是否统一指标的采集周期是否稳定日志能否按请求 ID 或节点 ID 关联到指标上。如果数据是断断续续的模型很难学到稳定规律。事件数据经常被忽略但它非常重要。一次故障前可能有过一次发布发布后错误率开始上升。如果在训练特征里没有“距上次部署时间”“最近是否有变更”这些上下文模型就只能靠指标趋势猜准确率会低很多。2.2 模型选型从规则到树模型再到深度学习的取舍很多文章一上来就讲 LSTM、Transformer但真实工程里模型复杂度应该跟数据量和故障样本数匹配。我建议按下面的梯度来选型。第一层是规则和统计方法。比如固定阈值、滑动窗口均值、EWMA、CUSUM。这类方法适合快速验证也能作为后续机器学习模型的基线。如果一个场景连简单规则都做不出稳定结果直接上深度模型大概率也不行。第二层是树模型。XGBoost、LightGBM、随机森林非常适合同一批特征的表格数据尤其适合几千到几万条样本的故障数据。树模型对特征尺度不敏感能处理缺失值训练速度快也能输出特征重要性方便跟业务解释为什么报这个预警。第三层才是深度时序模型。LSTM、Transformer 这类模型适合有大量历史序列、且模式非常复杂的场景比如从长时间序列里自动抽取周期性模式。但它们的训练成本更高超参数更多调参更复杂对数据质量和样本量要求也更高。从我的经验看大多数基础设施团队可以先从树模型入手把结果做成规则和模型混合的决策流程。比如规则负责捕捉极端情况模型负责预测趋势变化两者投票决定是否输出告警。这样可以避免深度学习带来的部署复杂性和解释性问题。3. 从零搭一套可验证的故障预测流程这一部分我会按一套最小可运行流程来写。你不需要有大规模数据也可以用历史监控数据先做一轮小样本实验验证预测思路是否成立。3.1 先定义目标预测什么、提前多久、误报率多少一开始不要写“预测系统异常”这种宽泛目标。我建议用一句话定义清楚像这样“预测未来 10 分钟某服务错误率是否会超过 5%。”这句话里有三个关键要素预测对象是“错误率”还是“磁盘使用率”。预测时间窗口是“未来 10 分钟”还是“未来 30 分钟”。故障阈值是“超过 5%”还是“超过 80%”。这三个要素决定了训练标签怎么打也决定了模型输出的实际价值。假设预测窗口是 10 分钟但监控数据采集延迟 5 分钟那么真正留给处理的时间只有 5 分钟。这个约束非常现实我建议在定义目标时就把数据延迟算进去。接下来是打标签。从历史数据中找到“错误率超过 5%”的时间点然后把这个时间点往前推 10 分钟标记这些正样本为“即将发生故障”。如果故障持续了很长时间要把整个故障窗口都考虑进去避免把故障中重复打标签。构造特征时要避免未来数据泄漏。比如用过去 5 分钟的错误率均值去预测未来 10 分钟是否超阈值滚动窗口只能基于当前时刻之前的数据不能包含未来值。很多新手实验跑出来准确率很高结果一上线就废就是因为特征里混进了未来数据。3.2 最小可运行实现滚动特征 分类模型下面这段代码展示的是一个最小流程。它用 pandas 做滚动窗口特征用随机森林做分类器输出预测结果。数据格式假设是每 1 分钟一条监控记录包含 cpu、mem、qps、error_rate、latency_p99 这几个字段。import pandas as pd import numpy as np from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report # 假设 df 包含列ts, cpu, mem, qps, error_rate, latency_p99 # ts 是时间戳已经按升序排列 # 先按时间排序避免乱序影响滚动窗口 df df.sort_values(ts).reset_index(dropTrue) feature_cols [cpu, mem, qps, error_rate, latency_p99] # 1) 构造过去 5 分钟的滚动窗口统计量 for col in feature_cols: df[f{col}_mean_5m] df[col].rolling(5, min_periods1).mean() df[f{col}_max_5m] df[col].rolling(5, min_periods1).max() df[f{col}_slope_5m] df[col].diff().rolling(5, min_periods1).mean() # 2) 构造标签未来 10 分钟 error_rate 最大值是否超过 0.05 # shift(-10) 表示把未来 10 分钟的结果移到当前行作为当前时刻的标签 df[future_max_error] df[error_rate].rolling(10, min_periods1).max().shift(-10) df[label] (df[future_max_error] 0.05).astype(int) # 3) 按时间切分训练集和测试集不能随机切分 # 假设前 70% 作为训练集后 30% 作为测试集 split_idx int(len(df) * 0.7) train_df df.iloc[:split_idx] test_df df.iloc[split_idx:] features [c for c in df.columns if c.endswith(_5m)] model RandomForestClassifier( n_estimators100, max_depth5, random_state42, class_weightbalanced ) model.fit(train_df[features], train_df[label]) print(classification_report(test_df[label], model.predict(test_df[features])))这段代码只是为了说明流程不是生产方案。真实场景里你还需要处理窗口中的数据缺失、时间间隔不均匀、异常值清洗、训练集和测试集之间的故障事件不重叠等问题。跑通之后可以看几个输出结果哪些特征最重要、预测错误集中在哪些时间段、误报都来自哪些场景。不要急着调参先关注“预测逻辑是否符合业务直觉”。如果模型给出的重要特征完全是某个不相关指标多半是数据预处理有问题。3.3 验证指标不要只看准确率要看“提前时间”对于故障预测准确率并不是最重要的指标。因为故障样本通常远少于正常样本模型只要一直输出“无故障”准确率可能也很高但没有实际价值。我更关注下面几个指标指标含义怎么判断精确率预测为故障的样本中有多少是真正故障太低会导致告警疲劳召回率真正故障中有多少被预测出来了太低会漏报失去预测价值提前时间预测发出到故障实际发生的时间差越长越方便处理但过长可能伴随误报误报率单位时间内的误报次数每天误报几十次值班团队不会再看这个系统还有一个容易被忽略的问题样本不均衡。故障时间段占历史数据 1%正样本可能只有几百条。不能用默认的准确率做评估要结合精确率、召回率和 PR 曲线。如果召回率要求很高误报就会增多所以先定义业务能接受的误报阈值。我一般会先把测试集里的预测结果按时间画出来肉眼看一下预警是否出现在故障发生前提前量大概是多少。如果模型输出比故障晚了几分钟说明特征窗口和标签窗口设置不合理。这个时候不要急着调模型参数先回到标签定义和特征窗口设计上。4. 稳定性、成本和团队协作落地的边界条件预测模型在测试集上表现不错只是第一步。真正上线会碰到各种工程问题比如数据链路延迟、模型漂移、告警去重、值班团队是否信任这个系统。这些问题往往比模型算法花的时间更多。4.1 单机 POC 和生产系统不是一回事用 Jupyter Notebook 跑 pandas 和 sklearn和在生产环境跑一个实时预测任务差别很大。POC 阶段你不用考虑多台机器数据汇聚、特征计算延迟、模型服务高可用、告警推送幂等性。但生产环境每一步都可能成为瓶颈。举一个实际例子模型能提前 15 分钟预测错误率超标但监控系统指标采集到大数据平台需要 5 分钟特征计算需要 2 分钟模型推理再花 1 分钟那么实际留给值班人员的窗口只有 7 分钟。如果这个窗口小于故障响应预案的执行时间预测就形同虚设。因此设计整个系统时要把“端到端延迟”当成一个核心指标。我建议在模型服务前面加一个延迟监控判断每一条预测结果从数据入口到告警输出花了多少时间。一旦延迟超标宁可暂时降级到固定阈值告警也不要让模型在过期的数据上推理。4.2 模型漂移、重训和人工反馈闭环系统不是静态的。一次架构调整、一次数据库版本升级、一次业务流量结构变化都会让历史分布失效。上个月训练好的模型这个月可能精确率大幅下降。这叫做模型漂移。要处理漂移不能只靠定期重训还要建立反馈闭环。值班人员收到预警后应该能标记“确认故障”“误报”“漏报”。这些标记会回流到样本集成为下一轮训练数据的一部分。没有这个环节模型只能靠工程师手动调参长期下去会越来越不准。我见过一些团队把模型重训设成每周一次但样本集没有人工反馈只是把新数据无脑加进去效果并不好。更合理的做法是每次故障结束后由值班人员补充一段结构化复盘包括故障时间点、根因、影响范围、当时哪些系统有异常。这些结构化记录才是模型持续学习的养分。4.3 多数瓶颈不在模型而在数据质量和响应预案最后想聊一个容易被忽略的点预测系统故障的最终目的是“有人能在故障发生前做事”。如果团队每次收到预警都不知道下一步该干什么预测系统反而会加重负担。我建议在模型上线之前先给每个故障类型配置一个响应预案。比如预测到磁盘将在 2 小时内写满自动触发日志清理或扩容通知。预测到服务错误率会在 10 分钟后超过阈值自动触发限流或重启部分实例。预测到连接池将耗尽自动执行连接数调整或重启服务。没有这些预案预警到了值班手里也只是多一条没去处的消息。而要把预案做对又需要依赖故障复盘数据。比如“上次磁盘写满后做了什么操作有效”“上次错误率升高是扩容解决的还是回滚解决的”。这些经验和数据比你模型里用哪个算法更重要。另一个实际瓶颈是数据质量。如果历史故障记录只有一句话“xxx模块故障”没有时间线、没有指标变化、没有部署记录模型很难自己学会规律。所以我建议先从故障复盘模板开始记录故障开始时间、发现时间、根因分类、影响范围、关键指标趋势、相关变更。当这类结构化记录积累到几十条以上再考虑训练预测模型会顺利很多。这几轮看下来我最大的体会是预测系统故障不是一个纯模型问题而是一个可靠性工程问题。Sequoia 投 Empirik说明资本市场看好这个方向但落到自己的集群里还是要先从数据治理和故障复盘开始。先把单条时间序列整理清楚把一次故障的时间轴画完整再考虑上不上模型。如果连基本告警都会被人忽略那么预测模型的准确率再高也只会成为新的噪音源。