近两年基础设施和业务系统的稳定性要求越来越高故障预测不再是“玄学”而是逐渐走向工程化落地的硬需求。Sequoia红杉资本孵化的 Empirik 最近从幕后走向台前独立成为公司并拿到了 2100 万美元种子轮融资专注于预测系统故障。这则消息在运维圈、SRE 圈和 AI 基础设施领域都引起了不小关注。前段时间我在整理可观测性平台和 AIOps 落地方案时也专门研究过这一类“预测性维护”系统。拆完 Empirik 的技术思路和融资背景之后我发现它背后的技术体系其实非常值得开发者学习。本文不打算只转述融资新闻而是把“预测系统故障”这个方向的技术原理、架构组成、工程落地路径和常见坑位完整梳理一遍。无论你是做后端开发、运维监控还是刚接触机器学习都能从这套体系里找到可以照着做的东西。本文将围绕四个核心问题展开为什么故障预测突然变重要这类系统在技术上是如何实现的如果自己搭一套最小预测模型代码怎么落地真正在企业里推广时会遇到哪些问题、如何规避。文章末尾会给出工程化最佳实践并梳理一条从监控告警到智能排查的成长路线。1. 背景与核心概念1.1 什么是系统故障预测系统故障预测并不是一个新概念传统运维里早就有人通过设置阈值、查看趋势图来“预估”磁盘满了、CPU 飙高。但传统方式依赖专家经验且只能处理单一指标无法应对分布式系统中复杂的非线性依赖。现代意义上的系统故障预测是指利用机器学习、统计分析和时序数据处理技术基于系统历史运行数据如 CPU、内存、网络延迟、日志、调用链等建立模型来判断系统在未来一段时间内是否可能发生故障并在故障真正发生之前给出预警与根因线索。通俗地说传统监控是“事后告警”指标已经异常了才触发通知而故障预测是“事前预警”根据指标的变化模式推断出故障苗头。举个例子传统监控CPU 使用率达到 95%发出告警。故障预测CPU 在最近 10 分钟内从 30% 逐步爬升并且与内存增长趋势存在相关性预测 30 分钟后可能出现资源耗尽提前提醒扩容。后者显然更有价值因为它留出了决策时间。1.2 故障预测与 AIOps 的关系Empirik 这类公司所在的赛道经常被归类到 AIOps智能运维。AIOps 是 Gartner 提出的概念核心是把人工智能技术应用到 IT 运维领域实现异常检测、故障诊断、根因分析和自动化修复。AIOps 的数据输入是海量的监控数据、日志数据、 trace 数据输出是更精准的告警和更快的恢复动作。故障预测是 AIOps 里的“高级能力”它比普通异常检测更进一步要求模型不仅知道“现在是不是异常”还要预测“未来会不会异常”。具体能力层级可以这样划分能力层级说明典型技术描述性监控知道系统当前状态指标采集、可视化诊断性分析知道系统为什么异常日志分析、根因定位预测性分析知道系统未来是否异常时序预测、异常趋势建模规范性决策自动决定如何规避自动扩容、自愈系统Empirik 做的就是“预测性分析”这一层并且把它产品化。1.3 为什么故障预测现在突然被资本关注过去几年云原生架构普及微服务数量动辄上百个Kubernetes 集群里服务实例经常弹性伸缩。系统复杂度爆炸之后故障变得难以预测单纯靠运维人工盯监控已经不可行。与此同时大语言模型和 AI 技术的进步让“多模态数据理解”变得更加容易。模型可以从日志、指标、代码变更记录中联合学习故障模式。Sequoia 选择孵化 Empirik本质上是对“AI 替代一部分专家运维判断”这一趋势的押注。从行业痛点上来说企业级客户最关心的不是“监控工具多好用”而是“能否在我业务出问题之前就告诉我”。故障预测系统直接承诺这一点所以资本愿意给出高估值。2. 环境准备与版本说明要理解并动手实现一个最小可用的故障预测系统你需要准备一套数据分析和机器学习的运行环境。本文后续的实战案例会使用 Python 编写下面给出推荐环境。2.1 基础运行环境操作系统Windows 10/11、macOS 12、Ubuntu 20.04/22.04 均可。Python 版本推荐 Python 3.9 及以上本文基于 Python 3.10 验证。包管理工具pip 或 conda。2.2 需要的 Python 库依赖库用途安装命令pandas数据处理与时间序列重采样pip install pandasnumpy数值计算pip install numpyscikit-learn机器学习建模与评估pip install scikit-learnstatsmodels时序分解与统计检验pip install statsmodelsmatplotlib可视化pip install matplotlib版本不需要完全一致只要是大版本兼容即可。比如 scikit-learn 1.2 和 1.3 对本文示例没有本质区别。如果你用的是公司内网环境可以用镜像源安装这里不展开代理问题。2.3 示例项目结构建议在本地创建如下目录结构fault-prediction-demo/ ├── data/ │ └── system_metrics.csv ├── src/ │ ├── feature_engineering.py │ ├── train_model.py │ └── predict.py ├── notebooks/ │ └── explore.ipynb └── README.md这个结构是后续工程化扩展的基础。数据目录存放原始监控指标src 存放核心代码notebooks 用于探索性分析。如果只是初学者跑通流程也可以把所有代码放在一个脚本里但建议尽早养成模块化思维。3. 核心语法、配置或原理拆解3.1 故障预测系统的整体技术栈Empirik 并没有公开全部技术架构但根据行业通用做法和其团队背景我们可以梳理出这类系统通常包含的关键模块数据采集层对接 Prometheus、Datadog、CloudWatch、ELK 等监控源采集时序指标、日志和链路数据。数据预处理层处理缺失值、异常值、时间对齐把不同类型的数据统一成模型可用的特征。特征工程层提取滑动窗口统计量均值、方差、峰值、趋势特征、周期性特征、熵等。预测模型层使用时序模型如 Prophet、LSTM、Transformer或异常检测模型Isolation Forest、自动编码器构建预测器。根因分析层当预测到故障时利用关联分析、因果推断或大模型辅助定位可能的原因。告警与自动化层输出预警结果对接工单系统、钉钉/企微机器人、自动扩容组件。从系统架构看故障预测不是单一算法问题而是一个完整的数据管道问题。3.2 时序数据是基础故障预测主要处理时序数据。时序数据有三个核心要素时间戳每个数据点的采集时间。度量值如 CPU 使用率、请求延迟。标签如服务名、实例 ID、地域。在 Python 中我们通常用 pandas 的DatetimeIndex来处理时序数据。常见操作包括重采样resample、滑动窗口rolling、滞后特征shift。处理时序数据时最常见的错误是“未来数据泄漏”即在构造特征时不注意时间顺序用了未来信息来预测当前。这一点在故障预测中尤其致命因为模型会因此表现得“虚高”线上却完全失效。3.3 异常检测与故障预测的模型选择故障预测并不是必须使用深度学习的。根据数据规模和场景差异常用模型可以分成三类模型类别代表算法适用场景统计类移动平均、EWMA、Holt-Winters周期性明显的单指标预测机器学习类孤立森林、XGBoost、随机森林多指标联合异常检测深度学习类LSTM、Temporal Convolutional Network、Transformer大量时序数据、复杂非线性模式对于初创企业或中小团队我建议优先从机器学习类模型开始不要一上来就堆 LSTM。原因是数据量不够、特征工程不到位时复杂模型反而容易过拟合。Empirik 这类公司之所以敢做预测是因为他们拿到了很多企业的大量历史故障数据这是普通开发者不具备的。3.4 核心衡量指标精确率、召回率与提前量故障预测系统的效果评价不能只看准确率。两个关键指标是提前量预测到故障的时间点与实际故障时间点之间的距离。比如提前 30 分钟预警运维就有时间去处理。误报率预测有故障但实际没有故障的概率。误报太多会让运维产生告警疲劳最终关闭系统。因此在设计系统时要明确业务目标你是希望宁可多报也不要漏报还是希望精准预警减少干扰。这个权衡会影响模型阈值的选择。4. 完整实战案例构建一个最小可用的故障预测模型接下来我用一个简化的服务器 CPU 指标预测案例演示故障预测的完整流程。假设我们有一台服务器记录了每分钟的 CPU 使用率、内存使用率和网络流量其中某段时间由于流量突增导致 CPU 持续高位最终在某个时间点触发了系统过载。我们要构建一个模型提前预测“未来 30 分钟内是否会出现 CPU 过载”。需要注意这个案例是为了演示核心思路并不代表生产级系统。生产环境的故障数据更复杂但整个建模流程是相通的。4.1 创建项目结构按照上面的目录结构我们在终端执行mkdir fault-prediction-demo cd fault-prediction-demo mkdir data src notebooks然后进入data目录手动创建示例数据文件system_metrics.csv。由于没有真实数据我们用随机生成的方式模拟一段时序数据。4.2 生成模拟数据为了便于演示我写一个生成数据的脚本放在src/generate_data.py。这个脚本会生成 1440 分钟即 24 小时的 CPU、内存和流量数据并标记每个时间点是否为“故障前状态”。# 文件路径src/generate_data.py import numpy as np import pandas as pd np.random.seed(42) # 生成时间索引每1分钟一条共1440条 time_index pd.date_range(start2024-06-01 00:00:00, periods1440, freqmin) # 模拟正常CPU水平20%到50%之间波动 cpu 30 10 * np.sin(np.linspace(0, 6 * np.pi, 1440)) np.random.normal(0, 2, 1440) # 模拟内存缓慢增长 memory 40 np.random.normal(0, 1, 1440).cumsum() * 0.05 memory np.clip(memory, 30, 90) # 模拟网络流量正常在100-300之间 traffic 200 50 * np.cos(np.linspace(0, 8 * np.pi, 1440)) np.random.normal(0, 15, 1440) traffic np.clip(traffic, 50, 500) # 在1000分钟之后模拟流量突增导致CPU持续上升 traffic[1000:1200] 300 cpu[1000:1200] 20 np.linspace(0, 25, 200) # 故障发生点第1200分钟CPU超过95% fault_point 1200 fault_occurred 0 labels np.zeros(1440) # 故障前30分钟1170到1199标记为1表示需要预警 for i in range(max(0, fault_point - 30), fault_point): labels[i] 1 df pd.DataFrame({ timestamp: time_index, cpu_usage: cpu, memory_usage: memory, network_traffic: traffic, will_fault_in_30min: labels }) df.to_csv(data/system_metrics.csv, indexFalse) print(df.head())运行这个脚本后你会得到一个包含四列数据的 CSV 文件。其中will_fault_in_30min就是我们要预测的标签1 表示“当前时间点之后的 30 分钟内会发生故障”。4.3 特征工程原始数据是 CPU、内存、流量三个指标不能直接输入模型因为我们要预测的是“未来是否故障”需要构建反映趋势变化的特征。我们需要从历史序列中提取特征比如过去 5 分钟、10 分钟的滑动平均和标准差。这里构造特征时必须只用当前时间点之前的数据不能混入当前点之后的数据。# 文件路径src/feature_engineering.py import pandas as pd def build_features(df): df df.copy() # 确保时间排序 df.sort_values(timestamp, inplaceTrue) # 滑动窗口特征过去5分钟和过去10分钟的平均值、最大值、标准差 df[cpu_rolling_mean_5] df[cpu_usage].rolling(window5).mean() df[cpu_rolling_max_5] df[cpu_usage].rolling(window5).max() df[cpu_rolling_std_5] df[cpu_usage].rolling(window5).std() df[mem_rolling_mean_5] df[memory_usage].rolling(window5).mean() df[traffic_rolling_mean_5] df[network_traffic].rolling(window5).mean() df[traffic_rolling_max_5] df[network_traffic].rolling(window5).max() # 当前值相对滑动均值的变化率反映趋势 df[cpu_diff_mean_5] df[cpu_usage] - df[cpu_rolling_mean_5] df[traffic_diff_mean_5] df[network_traffic] - df[traffic_rolling_mean_5] # 删除前几行因为滚动窗口产生的NaN df df.dropna().reset_index(dropTrue) return df特征设计有几个关键点不要直接用未来的数据。滑动窗口大小要结合实际监控频率。如果数据是秒级的窗口可以取 60如果是分钟级5-30 分钟比较合适。单一维度可能不够要结合多个指标的变化关系比如“流量上升但 CPU 没有变化”可能代表另一个问题。4.4 训练模型使用 scikit-learn 的随机森林分类器来训练。将数据按照时间顺序划分前 70% 作为训练集后 30% 作为测试集。这里不能用随机打乱因为时序数据一旦打乱就破坏了时间依赖性。# 文件路径src/train_model.py import pandas as pd from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report, confusion_matrix from sklearn.model_selection import TimeSeriesSplit from feature_engineering import build_features df pd.read_csv(data/system_metrics.csv, parse_dates[timestamp]) df build_features(df) feature_cols [ cpu_usage, memory_usage, network_traffic, cpu_rolling_mean_5, cpu_rolling_max_5, cpu_rolling_std_5, mem_rolling_mean_5, traffic_rolling_mean_5, traffic_rolling_max_5, cpu_diff_mean_5, traffic_diff_mean_5 ] X df[feature_cols] y df[will_fault_in_30min] # 时序划分不使用随机拆分 split_idx int(len(df) * 0.7) X_train, X_test X.iloc[:split_idx], X.iloc[split_idx:] y_train, y_test y.iloc[:split_idx], y.iloc[split_idx:] # 类别不平衡故障前样本很少用class_weight平衡 model RandomForestClassifier( n_estimators100, max_depth8, class_weightbalanced, random_state42 ) model.fit(X_train, y_train) y_pred model.predict(X_test) print(Confusion Matrix:) print(confusion_matrix(y_test, y_pred)) print(\nClassification Report:) print(classification_report(y_test, y_pred))运行后我们可以看一下结果。由于模拟数据是精心构造的效果通常不错。但在真实场景中你很可能面临严重的类别不平衡比如正样本故障前状态占比不到 0.1%这时候就需要采用欠采样、过采样或调整阈值的方法。4.5 预测与可视化训练完成后我们希望模型能够输出“未来 30 分钟故障概率”而不是硬分类。随机森林可以通过predict_proba得到概率值。设置一个阈值比如 0.3当超过阈值时触发报警。编写预测脚本# 文件路径src/predict.py import pandas as pd import matplotlib.pyplot as plt from feature_engineering import build_features # 加载模型和特征构建脚本 import joblib model joblib.load(models/rf_model.pkl) # 实际应用时需要先通过joblib.dump保存模型 df pd.read_csv(data/system_metrics.csv, parse_dates[timestamp]) df build_features(df) feature_cols [...] proba model.predict_proba(df[feature_cols])[:, 1] # 绘制预测概率和实际故障区域 plt.figure(figsize(12, 6)) plt.plot(df[timestamp], proba, label故障概率) plt.axvspan(df[timestamp].iloc[1170], df[timestamp].iloc[1200], colorred, alpha0.3, label故障前30分钟) plt.xlabel(时间) plt.ylabel(概率) plt.title(故障预测概率曲线) plt.legend() plt.show()这里需要说明joblib.dump保存模型的方法是joblib.dump(model, models/rf_model.pkl)实际生产环境中模型通常不会直接保存在本地而是存储到模型仓库或者以 API 服务的方式部署。5. 常见问题与排查思路在故障预测系统的开发与实施中会遇到很多典型问题。结合我自己的实践和一些同业反馈下面汇总成表格并给出排错思路。问题现象常见原因解决思路模型在训练集上效果很好线上几乎失效数据泄漏、特征分布漂移检查是否误用了未来数据用滚动时间窗口验证模型定期重训练告警过多运维开始忽略系统阈值设置过低或者正样本定义过宽调高阈值引入成本函数根据误报与漏报代价调整阈值正样本太少模型学不到规律故障本身就是小概率事件使用异常检测的无监督方法必要时造数据或使用迁移学习预测延迟太大等模型推理完故障已经发生实时推理链路太长使用更轻量模型将特征计算下沉到流式计算引擎中数据时间戳不对齐多个数据源时间精度不同统一时区与采样频率使用重采样对齐到同一时间网格预测到了故障但运维无法快速定位根因预测模型只输出概率没有可解释性增加特征重要性分析引入根因定位模块关联变更和日志开发故障预测系统建议从一开始就建立“模型效果不是唯一标准”的意识。真正被业务认可的系统往往是在误报率和提前量之间找到了平衡同时能提供足够的上下文帮助运维做决策。6. 最佳实践与工程建议6.1 数据层最佳实践数据采集要保留原始粒度。如果一开始只存了聚合后的 5 分钟均值后面做 1 分钟级别的预测模型就会很难办。处理好标签延迟。例如“未来 30 分钟内是否发生故障”这个标签的定义需要与业务方达成一致不能让算法团队自己拍脑袋。特征存储与线上一致。训练时如果用了 5 分钟窗口线上也必须是同样的窗口方式否则特征分布会偏移。6.2 模型层最佳实践从可解释模型开始比如 XGBoost、随机森林等准确率不够再尝试 LSTM、Transformer。使用滚动预测验证模型稳定性而不是随机 K 折交叉验证。定期重训练。故障模式会随着系统版本更新而变化建议每周或每月用新数据增量训练一次。监控模型的指标漂移。比如cpu_usage特征的在均值逐渐上升说明业务模式可能已经变了。6.3 工程化与安全边界故障预测系统本身不能成为新的故障点。要做降级方案如果模型服务挂了至少保留基础监控告警能力。权限与数据安全。监控数据通常包含业务敏感信息比如 IP、请求路径需要脱敏处理。任何自动化动作比如自动扩容、自动重启都要有手动开关和审计日志。6.4 团队协作建议故障预测不是“算法工程师自嗨”的项目。我建议在项目启动初期就邀请 SRE、运维、业务研发一起制定评估标准并准备一批历史故障案例作为测试基准。每次模型改动都在这些基准案上进行回归测试确保新模型不会漏掉老故障。7. 总结与学习路线通过本文我们以 Empirik 获得 2100 万美元种子轮融资这一事件为切入点完整梳理了预测系统故障领域的技术体系什么是故障预测它与 AIOps 的关系故障预测系统的整体技术栈数据采集、特征工程、模型训练、告警输出一个基于 Python 的最小故障预测模型实现包含模拟数据、特征工程、训练和预测常见问题排查清单和实践建议。如果你打算继续深入学习这个方向可以按以下步骤推进掌握 Python 数据处理和时序分析基础重点理解pandas的rolling、shift、resample。学习机器学习基础特别是分类模型的评估指标理解 precision、recall 和阈值之间的关系。阅读时序异常检测的经典论文和开源项目比如字节跳动的管他等但要在合法授权范围内使用。实践一个完整的指标监控与预测管道可以使用 Prometheus Grafana 做展示再用 Python 做预测服务。研究大模型在 AIOps 中的应用比如利用 LLM 理解日志并辅助根因定位这是目前很有潜力的方向。如果本文对你理解系统故障预测有所帮助可以收藏备用。接下来也可以在本地亲手跑一遍第 4 节的代码把特征窗口改一下观察模型效果的变化。理论看得再多都不如自己跑通一个模型来得踏实。