凌晨两点告警电话把 SRE 从睡梦中叫醒。你打开监控面板发现 CPU 在 10 分钟前已经冲到 95%随后服务开始频繁 5xx用户投诉已经出现在群里。这个场景每一位负责线上系统的人都太熟悉了。传统监控做的事情本质上是“等事故发生时告诉你”。而你能做的往往只是把故障影响缩短几分钟——该发生的还是发生了。Empirik 最近的消息值得关注这家由 Sequoia红杉孵化的公司正式独立运营并拿下了 2100 万美元种子轮融资。它的方向很清晰——用 AI 模型在故障真正发生之前预判系统风险。这不是一条普通的融资新闻。它背后代表着一个正在发生的行业转变运维和监控行业正在从“看数据”走向“做预测”。本文不打算只复述融资数字而是想把这个方向的技术原理、与传统方案的区别以及你自己能怎么开始验证这套思路完整讲清楚。1. 为什么这次融资值得技术人关注先给结论Empirik 拿到的不是一笔简单的“AI 概念融资”。如果你仔细看它的方向——系统故障预测——就会发现它踩中的是过去十年 SRE 和 DevOps 实践里最痛的那根神经我们能不能在故障影响用户之前就提前知道它会来传统监控体系发展到现在已经非常成熟。指标采集、日志聚合、分布式链路追踪、告警规则配置、仪表盘可视化这套组合拳让工程师拥有了非常强的“事后定位”能力。但问题恰恰出在这里绝大多数团队的能力边界停留在“故障已经发生如何快速定位”。而“故障即将发生如何提前干预”这个环节一直是靠老师的经验直觉。经验直觉靠不靠谱对于十年经验的大神靠谱。但对于一个正在快速扩张、系统架构每天都在变化的团队经验往往是滞后的。新服务上线、流量突增、配置变更、依赖升级任何一个变量都可能让过往经验失效。Empirik 想要做的是把“老师傅的经验直觉”变成一套可学习的、可规模化的模型能力让系统从海量指标、日志和链路数据里自动学习“故障发生前到底有哪些征兆”然后在征兆出现时发出早期预警。这件事的价值不是“少看几个告警”而是改变事故处理的全程节奏传统模式故障已发生 → 告警触发 → 工程师介入 → 止损 → 复盘。预测模式风险信号积累 → 模型预警 → 工程师提前排查 → 在故障成形前消除。如果这套链路能真正跑通它降低的不只是 MTTR平均恢复时间还包括事故对用户体验、对业务收入、对团队士气的整体冲击。这才是这笔融资背后真正值得技术人关注的地方。2. 系统故障预测的核心概念与行业背景要理解 Empirik 在做的事情先要把几个概念边界理清楚。这里很容易混淆的是三件事监控、告警、预测。监控Monitoring回答的是“系统现在是什么状态”它采集 CPU、内存、QPS、错误率、延迟等数据并把这些数据展示出来。告警Alerting回答的是“系统当前是否异常”它基于阈值或规则判断当前状态是否越界。预测Prediction回答的则是“系统未来会不会异常”它基于历史数据学习规律推测未来一段时间内的风险概率。三者不是替代关系而是递进关系。没有良好的监控数据采集预测就是无米之炊没有科学的告警规则预测结果也无法有效触达工程师。但预测带来的价值增量是前两者给不了的时间差。再聊一个你可能听过的词AIOps。Gartner 在多年前提出 AIOps 时核心定义是“将人工智能应用于 IT 运维通过大数据和机器学习提供主动的、个性化的、动态的洞察”。这个概念在过去几年被用得非常泛很多产品只要加了一个 AI 算法就敢自称 AIOps。但真正把 AI 价值落在“预测故障”而不是“美化图表”上的产品其实并不多。系统故障预测在技术实现上通常依赖三类数据第一类是指标时序数据。CPU、内存、磁盘 IO、网络流量、GC 耗时、QPS 曲线这些数据天然是时间序列。模型可以通过历史周期学习“正常曲线长什么样”再对比实时数据判断是否出现偏差。第二类是日志文本数据。应用日志里往往藏着故障的前兆大量重试、连接超时、慢查询、异常堆栈。传统方式靠关键字告警但模型可以学习更复杂的模式比如“某个异常在 5 分钟内连续出现 30 次且错误率同步上升”这样的组合信号。第三类是链路追踪数据。微服务场景下一次请求穿越多个服务任何一个服务变慢都可能拖垮整条链路。通过分析链路数据模型可以识别出“某个下游服务的 P99 延迟正在持续爬升”这类渐进式风险。Empirik 的具体模型架构和产品细节目前公开披露的信息有限外界能看到的更多是融资和公司定位。但根据行业通用的技术路线来推断它大概率也是围绕上述三类数据构建预测能力的。这个判断不一定精确但方向上应该不会偏。3. 从孵化到独立Empirik 的技术定位与产业信号Empirik 这一轮融资有一个特殊的背景它是从 Sequoia 孵化项目中走出来的。这里要先解释一下“孵化”的含义。在早期投资圈头部基金除了传统的主基金投资之外也会设立专注于“从 0 到 1”阶段的孵化项目。这类项目的特点是基金不只是投钱还会深度参与产品方向的验证、早期团队搭建、种子用户对接甚至在项目方向还不够清晰时就先帮创始团队找到技术切入点。Sequoia 作为全球顶级基金其在 AI 领域的布局本身就具有很强的信号意义。从公开信息看Empirik 在孵化期内完成了从“想法验证”到“产品雏形”的转变独立后立刻获得 2100 万美元种子轮。这个金额放在种子轮里是相当大的——大多数种子轮融资在 100 万到 1000 万美元之间。大额种子轮通常意味着投资方对技术方向和团队能力有比较强的信心。那么Sequoia 为什么愿意在孵化阶段就押注“系统故障预测”这个方向我的判断是这里存在一个明显的市场空白。过去几年可观测性赛道已经跑出了非常大的公司。Datadog、Grafana、Prometheus 生态、云厂商自带的监控服务这些产品把“数据采集、存储、可视化、告警”做到了很高的成熟度。但如果你去问一线 SRE他们最常见的抱怨仍然是告警太多、告警太吵、有价值的预警太少。问题在于当所有人的工具都是“阈值 规则”这套逻辑时告警质量天然受限于人的经验。你花大量时间调阈值结果流量高峰一来正常波动也触发告警你把阈值调高又担心漏掉真正的故障。Empirik 想切入的正是“规则不够用需要模型来补”的这一层。它不一定是要取代 Prometheus 或 Datadog更可能是作为可观测性体系之上的“预测层”读取已有的监控数据输出“未来某个服务大概率会出问题”的预测信号。如果这个定位成立那这轮融资在产业层面释放的信号就很清楚下一阶段的运维竞争重点不再是采集多少数据、画出多漂亮的仪表盘而是谁能从同样的数据里挖掘出更强的预测能力。4. 传统监控与预测式故障发现的核心差异为了更直观地理解预测式故障发现的价值我们可以把传统监控方案和一个理想的预测方案放在同一张表里对比维度传统监控 阈值告警预测式故障发现触发时机指标越界或错误率超过阈值时风险模式开始形成时数据依赖实时指标 预设规则历史数据 实时数据 模式学习核心能力描述“发生了什么”推断“将要发生什么”告警质量依赖工程师手工调阈值模型自适应学习基线对经验依赖高规则是人写的相对低规律由数据驱动主要局限漏报和误报长期共存模型需要高质量训练数据且可解释性待提升团队落地成本低工具链成熟高需要数据 pipeline 和模型工程能力这张表并不是说传统监控要被淘汰。实际上预测式方案通常需要构建在可靠的监控数据之上。但它的确揭示了一个趋势当数据量到达一定规模后靠人写规则的方式会遇到明显的天花板。举一个具体例子。某个电商系统在大促前会增加一批临时 Pod扩容过程中有一个服务的连接池参数配置错误导致部分请求出现间歇性超时。传统告警下只有当超时比例超过阈值时才会触发告警而等到超时比例足够大用户可能已经感觉到了。预测模型则可以结合多项特征连接池使用率的增长斜率、超时错误在日志中的出现频率、该服务在链路中的依赖关系、历史大促期间同类配置变更后的表现。当这些特征组合起来的风险评分达到某个水平模型就可以提前发出预警而此时系统可能还没有出现明显的用户可见故障。这就是“从监控到预测”的核心区别传统方案是在事故的末端等信号预测方案是在事故的早期找规律。5. 不依赖 Empirik你也可以跑通一套故障预测最小实验可能有人会问Empirik 的产品再厉害我现在也拿不到手这篇文章对我有什么实际帮助这是一个很现实的问题。其实“系统故障预测”这个概念验证起来并不需要多么复杂的平台。只要你的团队有日志、指标数据并且具备基本的 Python 环境就可以在几天内做出一个最小实验直观感受“模型预测故障”和“阈值告警”之间的区别。下面我用一个通用思路分三步走通这套最小实验。注意这里不是 Empirik 的官方教程而是帮助你理解该技术方向的一种可落地路径。5.1 环境准备与数据说明实验环境建议如下Python 3.9 或以上版本pandas、numpy 用于数据处理scikit-learn 用于机器学习建模matplotlib 用于结果可视化Prometheus 或任意指标导出系统用于获取历史时序数据如果没有可以用构造数据代替先用 pip 安装依赖pip install pandas numpy scikit-learn matplotlib实验数据集可以选择两类一是你自己系统里的 CPU、内存、QPS 等指标导出为 CSV二是用脚本构造一段带异常趋势的模拟序列。为了便于复现下面用模拟数据演示完整流程。5.2 基于时间序列趋势的故障预测示例核心思路很简单用历史正常数据训练一个回归模型预测未来一段时间的指标值。如果真实值显著偏离预测值就说明系统正在偏离正常基线。先构造模拟数据。假设某个服务 QPS 曲线日常在 100 附近波动第 200 个时刻开始由于下游依赖变慢QPS 开始异常下滑。import numpy as np import pandas as pd import matplotlib.pyplot as plt from sklearn.linear_model import LinearRegression np.random.seed(42) time_step np.arange(0, 300) base 100 5 * np.sin(time_step / 10) normal_tail np.zeros(50) anomaly_tail -0.6 * np.arange(50) qps base.copy() qps[250:] anomaly_tail df pd.DataFrame({time: time_step, qps: qps}) print(df.tail(10))这里在序列的最后 50 个点上加入了持续下滑趋势模拟真实故障前的征兆。接下来我们用前 250 个样本训练模型预测后 50 个点的正常值范围。from sklearn.metrics import mean_absolute_error train_df df[df[time] 250] test_df df[df[time] 250] X_train train_df[[time]].values y_train train_df[qps].values model LinearRegression() model.fit(X_train, y_train) future_time test_df[[time]].values predicted model.predict(future_time) mae mean_absolute_error(test_df[qps], predicted) print(Mean Absolute Error:, mae)这一步执行后你会看到模型学习到的是一条“正常情况下的趋势曲线”。如果系统的真实曲线明显低于这条预测曲线就说明当前状态正在偏离正常。最后把结果画出来观察。plt.figure(figsize(12, 5)) plt.plot(df[time], df[qps], labelactual qps) plt.plot(test_df[time], predicted, labelpredicted qps, linestyle--) plt.axvline(x250, colorred, linestyle:, labelprediction start) plt.legend() plt.title(QPS Anomaly Prediction Demo) plt.xlabel(time step) plt.ylabel(qps) plt.show()这个示例虽然非常简化但它揭示了预测式告警的基本形态不是等指标跌破阈值才告警而是当指标开始偏离“应当是什么样”时就触发预警信号。5.3 基于日志异常模式的预测增强指标趋势预测只能覆盖一部分故障前兆。很多故障的早期信号出现在日志里例如连接池耗尽前会先出现大量连接等待日志内存溢出前会频繁出现 GC 时间增长。一个更贴近生产环境的做法是对日志信号做时间窗口聚合再结合多个特征训练分类模型。这里演示一个简化版的“日志特征 分类器”实验。假设我们有两种状态正常状态和即将故障状态。我们从日志中提取几个关键特征单位时间内异常关键字出现次数、平均响应时间的变化斜率、错误率。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report samples [] for i in range(500): error_count np.random.poisson(lam2) latency_slope np.random.normal(loc0, scale0.5) error_rate np.random.uniform(0, 0.5) will_fail 0 if error_count 8 and latency_slope 1.2 and error_rate 3: will_fail 1 samples.append([error_count, latency_slope, error_rate * 100, will_fail]) df pd.DataFrame(samples, columns[error_count, latency_slope, error_rate, will_fail]) X df[[error_count, latency_slope, error_rate]] y df[will_fail] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.3, random_state42) clf RandomForestClassifier(n_estimators100, random_state42) clf.fit(X_train, y_train) y_pred clf.predict(X_test) print(classification_report(y_test, y_pred))这个实验的逻辑是把“多个维度同时出现异常”作为预测目标模型学习不同特征组合与故障风险之间的映射关系。相比单指标阈值多特征模型能更早捕捉到组合型风险。5.4 告警压缩与风险评分思路最后一步是给预测结果加上“风险评分”和“告警优先级”的维度。生产环境中告警质量差的根本原因之一是每个单点异常都会触发一条告警而工程师根本来不及判断哪些告警才是根因。一种实用的思路是不对每条告警独立处理而是把同一个时间窗口内的告警聚合成一个“事件”并为这个事件计算根因评分。评分可以综合以下因素告警涉及的节点是否处于同一条调用链。指标异常是否同时在延迟、错误率、饱和度多个维度出现。该服务的历史故障频率和影响范围。异常时段是否与最近变更操作匹配。用代码表示一个简单的聚合评分逻辑alerts [ {service: order, metric: latency, severity: 3}, {service: order, metric: error_rate, severity: 4}, {service: payment, metric: satellity, severity: 2}, {service: user, metric: cpu, severity: 1}, ] def score_event(alerts): service_count len(set(a[service] for a in alerts)) total_severity sum(a[severity] for a in alerts) return service_count * 10 total_severity * 2 event_score score_event(alerts) print(event score:, event_score)在真实产品中这一步通常由告警平台和知识图谱配合完成。但从工程角度看核心思想是相通的控制告警数量提升单条告警的信息密度把工程师有限的注意力作用在最有价值的风险信号上。6. 如何验证预测效果指标与评估方法很多人会把“预测准确率”当成唯一指标这其实是误区。故障预测是一个典型的不平衡分类问题系统绝大多数时间都是正常的真正发生故障的时刻非常少。如果你训练的模型把 98% 的场景都预测为“正常”准确率也能达到 98%但对实际运维没有任何帮助。因此评估系统故障预测效果时应该优先关注几个运维价值明确的指标。第一是提前预警时间。这是预测相对传统告警最核心的优势指标。它衡量的是模型发出的预警比真实故障影响到用户的时间点提前了多久。提前 30 分钟和提前 5 分钟对应的处理策略完全不同。第二是误报率。误报过多会直接导致工程师不再信任预警回到告警疲劳的老路。实践中可以通过调整决策阈值来控制误报率但代价往往是漏报率上升需要在两者之间找平衡。第三是召回率。故障是代价高昂的事件漏掉一次重大故障的损失可能抵消掉优化误报率带来的所有收益。所以预测系统上线初期通常建议容忍相对高的误报率优先保证召回率。配套的验证方法一般分为离线回测和线上灰度。离线回测用历史数据模拟“如果模型在某个时间点运行能否提前发出预警”可以快速评估模型潜力。线上灰度则选择一个低风险服务作为试点观察预警是否对团队处理流程带来实际帮助。这一阶段常见的输出是一张“预警记录表”包含时间戳、预测风险源、提前时长、是否命中真实故障、工程师处理结论。这张表是后续迭代模型和调整阈值的核心依据。7. 常见问题与排查思路在实践故障预测的过程中有几个问题几乎每个团队都会遇到。这里把高频问题整理成一张排查表方便直接对照定位。问题现象可能原因排查方式解决方案预测结果几乎全部是“正常”异常样本太少模型没有学到故障模式检查训练数据中是否包含足够多的故障前时段样本补充历史故障数据或使用异常注入方式构造样本误报太多工程师开始忽略预警决策阈值设置过偏召回或特征本身区分度不够查看误报样本的共同特征分析阈值曲线调高决策阈值增加高区分度特征对误报做分类归因离线回测效果好线上表现变差线上数据分布和训练数据分布不一致对比训练集和线上数据的特征分布建立周期性重训练流程引入线上实时特征模型预警总是晚于已有告警特征窗口设置太长模型反应迟缓检查特征计算窗口和预警触发逻辑缩短特征窗口增加短周期特征优化预警触发机制预测结果无法解释团队不敢信模型可解释性不足缺乏归因能力使用 SHAP 等工具分析特征贡献度输出特征贡献排序关联具体指标和日志证据数据质量差指标有大量缺失采集链路不稳定上报口径不一致检查指标采集端点和数据完整性统一采集标准补全数据 pipeline对缺失做标记处理这张表里的问题本质上是所有 AI 运维系统落地时都会遇到的通用问题。它提醒我们一件事预测模型不是部署完就结束的项目而是一个需要持续迭代和工程投入的系统。8. 工程落地建议与最佳实践结合行业里已经验证过的经验如果要在一个真实生产团队里推动故障预测能力落地有几条原则建议认真对待。第一先选一个边界清晰的场景。不要一开始就试图预测所有类型的故障而是选择一种有明确数据支撑、故障影响大、且目前靠规则无法很好解决的场景。例如数据库连接池耗尽预测、某条核心链路的延迟劣化预测、磁盘或带宽的容量耗尽预测。边界清晰评价标准才清晰。第二预测结果必须与处理流程打通。只有当预警能转成具体的下一步操作时预测才有价值。团队要提前约定好收到预测预警后谁负责响应、第一步检查什么、什么情况下升级处理。否则预测就只是一堆没有行动指向的“未来信息”。第三严格遵守先离线后在线、先低风险后核心的原则。预测类模型直接应用于核心生产链路存在误报引发错误处置的风险。更稳妥的路径是先在离线环境用历史数据完成回测再放到一个低风险服务上以“附带观察”方式运行一段时间确认效果稳定后再逐渐扩大范围。第四建立反馈闭环。每一次预警都必须记录最终的处置结果用这些结果去评估模型效果并把有效样本重新纳入训练集。这比任何调参都重要。没有反馈闭环的预测系统时间越长效果越差。第五关注安全边界。预测系统本身会读取大量敏感的指标、日志和链路数据这些数据往往包含系统拓扑、业务参数甚至用户相关信息。在内部落地时要按最小权限原则控制模型的训练数据访问范围避免预测组件成为新的数据风险点。第六模型可解释性是生产环境的刚需不是可选项。工程师不会信任一个无法解释的“黑盒预警”。当模型给出“某服务 30 分钟后故障风险高”的预测时系统必须同时说明是哪些指标偏离了基线、哪些特征贡献最大、与历史上哪次故障最相似。只有这样才能真正催生行动。9. 总结与后续学习方向Empirik 拿到这笔融资真正值得关注的不只是金额本身而是它背后那条清晰的技术判断系统故障预测正在从实验室走向生产环境。监控行业已经花了十几年解决“数据怎么采、怎么存、怎么看”的问题下一波技术红利大概率会集中在“数据怎么变成预测行动”这个环节。对于普通开发者和运维工程师来说未必需要立刻用上 Empirik 这类产品但理解这个技术方向并在自己的系统里尝试跑通一个指标偏离检测或日志异常聚合的最小实验是非常有价值的事情。它不仅能让你更早发现系统风险也能帮助你重新审视团队现有的告警体系和数据处理流程找到效率提升的具体切入点。如果你决定沿着这个方向继续深入有几个知识模块值得投入时间时间序列分析与预测重点掌握趋势分解、周期识别、异常检测算法。日志与指标的特征工程理解如何从原始数据中提取有效的故障前兆特征。不平衡分类问题的建模与评估掌握精确率、召回率、F1、PR 曲线的实际意义。告警治理与 SRE 实践理解预测结果如何融入 on-call 流程和故障复盘机制。最后提醒一句任何预测系统都不能替代工程师对业务和架构的理解。模型给出的是“风险信号”最终判断和处置仍然需要人来完成。这既是当前的约束也是这个领域未来值得长期优化的方向。建议把这篇文章收藏起来等到你们团队开始讨论“要不要引入 AI 故障预测”时再翻出来对照一遍应该能帮你少走不少弯路。