从监控告警到故障预测：系统稳定性保障的下一代技术演进

凌晨两点，手机在床头振动。我迷迷糊糊翻了个身，看到群里同事发了一条消息：支付接口错误率开始往上走了。打开电脑，监控面板上那条曲线确实像被什么推了一把，正在缓慢但坚定地抬头。等到确认是依赖的上游服务超时，再通知到对应团队，时间已经过去了将近二十分钟。受影响请求不算多，但每一次刷新都是一笔笔失败的订单。

这是几乎所有后端团队都遇到过的场景。我们花了很多精力把监控做得越来越完善，告警越来越及时，可本质上还是在做同一件事：等系统已经出事，再赶着去收拾。直到前几天看到一条消息，说一家叫 Empirik 的公司从 Sequoia 体系里独立走了出来，拿到 2100 万美元种子轮融资，方向是“预测系统故障”。我突然意识到，这个赛道正在从一个实验室概念，慢慢变成有人愿意真金白银下注的产品方向。

这篇文章不打算复述新闻，而是想认真聊清楚：预测系统故障到底和现在的监控有什么区别，它凭什么值得一个独立公司去做，落到普通技术团队身上又意味着什么。

1. 先搞清楚一个问题：预测故障和监控告警是一回事吗

很多人第一反应是：这不就是加强版告警吗？系统指标超过阈值，或者日志里出现异常关键字，然后提前一点通知你。如果只是这样，确实不值得专门写一篇长文。

但预测系统故障想做的是另一件事：在故障真正发生之前，根据系统当前的状态、历史上的失败模式、以及各项指标之间的相关性，判断“接下来可能出问题”。注意这里的关键不是“已经出问题”，而是“接下来可能”。

1.1 监控回答“现在怎么了”，预测回答“接下来会怎样”

传统监控的运作逻辑是响应式的。它依赖预先设定的规则：CPU 超过 90% 五分钟，告警；错误率超过 1%，告警；接口 P99 延迟超过 500 毫秒，告警。这些规则有一个共同前提——异常必须已经出现，系统才会发出信号。

而预测系统是另一套逻辑。它先学习这个系统在过去几个月甚至一年里的运行模式，包括正常态的波动范围、故障发生前有哪些异常征兆、某些指标出现什么样的组合变化之后，故障大概率会出现。然后拿着这些学习结果，对接下来的系统状态进行判断。

打个不严谨的比方：监控是汽车仪表盘上的水温表，指针到了红线才亮灯；预测更像是你听发动机声音不对、看仪表组合有点怪，提前判断“再跑半小时可能开锅”，然后直接进服务区检查。

1.2 为什么预测比告警难做得多

如果只是把告警阈值调低一些，那不叫预测，那叫误报。真正的难点在于：

• 故障样本永远不够。一个系统可能一年只出过几次重大故障，模型能拿来学习的正样本极少。
• 系统的正常状态不是固定的。不同时期有容量调整、版本发布、流量波动，模型的基线需要持续更新。
• 误报的成本不只是打扰。如果预测经常不准，运维人员就会逐渐不再信任这套系统，最后变成一个没人看的仪表盘。

所以 Empirik 这种公司做得越深，越会意识到：预测故障在技术上不是一个模型的事，而是一整套解决数据质量、样本稀疏、误报控制、结果解释的工程问题。

2. Empirik 在做的事：把“故障知识”变成可复用的产品

根据公开信息，Empirik 是从 Sequoia 体系内孵化的项目，最近独立出来成为公司，并且拿到了 2100 万美元的种子轮融资。种子轮能到这个体量，在基础设施软件赛道算相当高了。这也说明投资人并不是把它当成一个普通监控插件来看。

它想做的是把预测系统故障这件事产品化：不需要每个公司都养一支算法团队，不需要自己从零搭一套异常检测平台，而是拿到一个开箱即用的系统，能对接已有的监控和可观测性数据，然后输出预测。

2.1 从孵化到独立，说明这件事已经从“试验”走到“产品化”

大公司内部的孵化项目很多，但不是每一个都能独立出来拿融资。能走出来，通常满足了两个条件：

第一，方向被验证过。至少在少数真实场景里证明这种预测是有价值的，而不是科学幻想。

第二，产品边界清晰。知道自己的客户是谁，知道交付形式是什么，知道和现有监控体系是互补关系而不是替代关系。

从工程文化“吃狗粮”的角度看，Empirik 从 Sequoia 的孵化体系里长出来，意味着它的早期迭代有真实基础设施场景做支撑。这一点非常重要，因为预测系统最怕的就是在干净数据集上效果很好，一接到真实生产数据就崩。

2.2 这类产品真正卖的不是模型，是流程信息化

很多技术团队一听到 AI 预测，第一反应是“你们用什么模型”。但其实，模型只是中间一环。一个能落地到生产环境的预测产品，核心能力是下面这几条：

• 数据接入：能不能对接 Prometheus、Grafana、Datadog、日志平台、链路追踪系统，把分散的数据聚合到一个时序分析体系里。
• 故障模式提取：能不能从历史故障中自动识别出“故障发生前的状态组合”，而不是靠人手动总结规则。
• 预测到行动的闭环：预测出问题之后，能不能自动创建工单、通知到人、对接已有告警系统，甚至触发预案。
• 反馈机制：预测错了要能消化，预测对了要能强化，让系统越用越准。

所以，Empirik 的 2100 万美元种子轮，背后其实是押注一个判断：故障预测正在从“算法竞赛”变成“基础设施能力”。谁先把预测能力嵌入到日常的研发和运维工作流里，谁就拿到了下一轮可观测性竞争的入场券。

3. 为什么“系统故障预测”在最近两年才变得可落地

一个客观事实是：预测系统故障不是新概念。很多年前就有论文在讨论用机器学习做异常预测，但一直停留在小范围实验。最近这两年，条件才开始成熟。

3.1 数据基础终于够格了

预测要成立，首先要能拿到足够长、足够干净的历史数据。可观测性行业这十几年做了很多基础工作：指标采集标准化、日志结构化、链路追踪规范化。对今天的大多数中大型互联网团队来说，系统的重要运行数据基本上都有留存。

数据留存和清洗这些看似不性感的环节，反而是预测模型能用的前提。没有连续、一致的时间序列数据，任何模型都只是纸上谈兵。这也是为什么很多有远见的团队前几年在可观测性上砸钱，当时看着像成本，现在看其实是给 AI 化应用铺路。

3.2 应用场景从“机房设备”扩展到了“软件系统本身”

早期做故障预测，更多集中在物理设备上：硬盘坏道、风扇转速、服务器温度。因为硬件设备的生命周期有迹可循，传感器数据相对规律，特征也清晰。

但软件系统的故障预测难得多。一个分布式系统的故障，可能是代码缺陷、配置变更、流量突变、依赖服务抖动，甚至是某个用户异常请求触发。故障原因之间互相缠绕，单一指标往往看不出问题，需要把指标、日志、依赖关系、变更记录放在一起综合分析，才能找到前兆信号。

近两年 AIOps 概念的普及、以及大模型对海量日志和文档的处理能力上升，让“把多种数据放一起找规律”这件事的工程成本大幅下降。Empirik 这类公司能成立，恰好站在这个时间节点上。

3.3 技术团队的心态也开始变了

以前一提预测，运维团队和 SRE 是抵触的：我连现在的告警都要靠规则压误报，你搞一个黑盒模型天天给我说“要出事了”，我怎么信？

但现在越来越多的团队意识到，服务规模和系统复杂度已经超出人能完全手工掌控的范围了。一个中大型后端系统，每天产生的指标和日志数量是一个人不靠工具根本看不过来的量级。与其被动筛选，不如让算法先把可疑的模式圈出来，再由人来做判断。

这种心态转变非常关键：预测系统要落地，不是替代 SRE，而是给 SRE 配一个不知疲倦的助理，先把最值得关注的问题筛出来。

4. 如果要从零开始搭一套“故障预测系统”，该怎么做

如果你现在被领导安排做“故障预测预研”，或者你单纯想搞清楚这个东西在自己的团队里能不能用，其实不用急着买商业产品，也不用一开始就上大模型。可以从一个最小代价的路径开始，逐步验证价值。

4.1 第一步，先把数据和基线整理清楚

很多团队连“系统正常时应该是什么样”都说不上来。没有健康基线，没有容差范围，那预测就无从谈起。

实际操作建议：

• 选 5 到 10 个核心指标，比如单机 CPU、内存、GC 时间、接口延迟、错误率、流量等。
• 把至少 90 天的历史数据导出，按工作日、节假日、大促时间分段统计。
• 画出每个指标的周规律和日规律，找到正常的波动区间。

这一步不做模型，只是纯统计。但它决定了后面所有工作的地基。

4.2 第二步，用统计方法和轻量模型做异常前兆识别

在传统监控之外，可以再加一个“趋势异常”维度。典型方法包括：

• 用滑动窗口计算最近的均值和方差，与基线对比，超过一定倍数就标记为异常前兆。
• 对时间序列做简单的季节性分解，发现残差部分异常升高时发出提醒。
• 训练一个隔离森林或一类 SVM 模型，用来判断当前时刻的系统特征是否和历史故障高发期的特征相似。

这里不需要上深度学习，也不需要搭 GPU 集群。很多 Python 库都能完成这类分析，比如 scikit-learn、statsmodels。建议先用一条链路的几个指标做实验。

4.3 第三步，加上“预测窗口”和“置信度”

预测系统和普通告警的核心区别在于，它得回答两个额外的问题：还有多久出问题？有多大把握？

所以，模型输出不能只有一个“是/否”，而应该是一个类似这样的结构化结果：

有了这个结构，后续的告警分诊、自动通知、预案触发才有可能。如果只是输出一个布尔值，大家还是不知道怎么用。

4.4 第四步，用反馈闭环不断校正

预测系统要长期可靠，必须记录每一次预测的结果，回填到训练样本里：

• 预测了，没出事 → 标记为误报，观察是哪个特征误导了模型。
• 没预测，出事了 → 回到数据里找遗漏的模式，补充特征。
• 预测了，也出事了 → 记录预测时距离真正故障早了多少时间，评估提前量的价值。

这套反馈闭环，本质上和做推荐系统、广告系统的思路一模一样。预测越准，不是靠一次性做一个好模型，而是靠每次错误都被消化成新的训练信号。

注意：不要一上来就追求“预测所有故障”。先选一类高频、可定义、影响明确的故障场景，比如下游依赖超时，把这一类做透，比什么都想预测但什么都不准要强得多。

4.5 第五步，评估这套系统到底值不值得用

评估预测系统需要看的指标，不能只看准确率。准确率很高，很可能是因为你在预测那些永远不会发生的“故障”。

要重点看三个维度：

• 提前量：预测比告警平均提前了多少时间，这个时间够不够团队做干预。
• 误报率：每次误报都会消耗团队注意力，误报太多，系统会被关掉。
• 可解释性：模型给出预测时，能不能同时告诉你是哪些指标异常导致的。不能解释的预测，在严肃的故障处理流程里很难被信任。

如果一个预测系统的提前量很大、误报率又很低，同时能把相关的异常指标一并列出来，那它就已经不是学术玩具，而是真正可以进值班室的东西了。

5. 这类方案的适用边界，以及技术团队该以什么姿势接住它

不能说拿到了 2100 万美元融资，就证明故障预测已经盖棺定论，适合所有团队立刻上马。它更适合一部分团队先跑起来，另一些团队可能暂时还用不上。

5.1 适合什么样的团队

• 已经有比较完善的可观测性平台，指标和日志留存超过半年。
• 系统规模大到人肉看监控已经看不过来。
• 有一定的数据工程和算法工程能力，或者愿意付费使用成熟的商业预测产品。
• 团队有明确的“故障前干预”流程，比如预案演练、快速变更回滚、流量切换。

在这些前提下，预测系统的价值容易被放大。因为它瞄准的本来就不是“小体量系统靠人肉已经能管好”的场景。

5.2 不适合什么样的团队

• 连最基础的告警和监控还没有建设好。
• 历史数据一团糟，有大量缺失和口径不一致。
• 每天的主要工作还停留在“出一件事，修一个 bug”的阶段。
• 团队对自动化决策的信任度很低，任何模型输出都要吵半天才敢处理。

对一个数据基础还不太好的团队来说，当务之急不是引入预测模型，而是先把指标、日志、配置和变更记录这几个维度统一采集和打通。没有齐整的数据，再强的预测引擎也无从下手。

5.3 对普通后端工程师和 SRE 来说，这意味着什么

哪怕是还在做传统业务开发的团队，也应该关注这个方向。原因是：预测系统一旦成熟，它改变的不是某一个技术点，而是整个生产事件的响应流程。

以前是：故障发生 → 告警 → 响应 → 排查 → 修复 → 复盘。 以后会是：风险预测 → 定位关联指标 → 判断影响范围 → 提前干预 → 避免故障发生。

一旦工作重心前移，整个团队的关注点会从“救火能力”转向“预防能力”。这对工程师的要求也会变化：除了会看日志、会排查问题，还得懂指标之间的关联、会验证预测结果、会设计前兆规则。

也就是说，故障预测不仅是工具演进，也在悄悄推动运维和研发职责的重新定义。

5.4 给正在考虑引入这类方案的团队一条可执行的路径

我建议这样推进：

1. 先选一个核心业务域，把它的可观测性数据完整梳理一遍。
2. 从历史故障事件里挑三类常见的、有明确前兆的故障。
3. 用规则、统计和简单机器学习模型做一次回测，看看如果按照当前方案提前预警，能提前多少时间、漏报多少、误报多少。
4. 如果回测结果能形成可用的提前量和可接受的误报率，再开始集成到告警链路。
5. 在灰度上线阶段，预测结果先以“建议”形式推送给值班人员，不自动触发动作，等团队对系统建立信任后再逐步升级。

这个顺序的好处是试错成本低。不管最终是自研、用开源项目做二次开发，还是等 Empirik 这类商业产品成熟后接入，这套方法论都能复用。

6. 站在 2025 年回头看，为什么是现在

融资信息本身很容易被当成一条新闻划过，但把它放到行业演进的时间轴里看，信号会更清晰。

过去十年，可观测性行业解决的问题是“看得见”：让系统的每一次请求、每一个错误、每一个资源消耗都有迹可循。这个阶段的产品已经比较成熟，头部玩家的市场格局也比较稳定。

而“预测故障”要解决的问题是“看得懂”：从海量运行数据里提炼出风险信号，甚至直接告诉你下一步该怎么处理。它不再是一个可观测性功能的延伸，而是向 AI for Reliability 这个方向迈出的更彻底的一步。

这也是为什么 Empirik 这种公司会选择独立融资，而不是继续留在大体系里当一个内部工具。因为预测系统的客户群、交付模型、技术栈和传统监控都不一样，需要一个独立团队用创业公司的速度去跑。

甚至可以说，如果这类公司能持续获得融资、不断验证客户价值，接下来我们大概率会看到一轮连锁反应：可观测性大厂快速补齐预测能力，创业公司从垂直场景单点突破，越来越多的中大型团队把“预测”纳入稳定性建设的关键词。

这件事最后会走到哪一步，没人能百分百断言。但我比较确定的是，故障处理正在从一门以“快速响应”为核心的手艺，变成一门以“提前预判”为核心的工程学科。对普通工程师来说，尽早理解这套思路，比纠结用什么公司、什么模型重要得多。

如果你所在的团队还没有开始做任何预测相关的尝试，我的建议很简单：先不要去追逐新潮的模型框架，而是把自己最熟悉的核心链路的历史数据拉出来，看看在每一次故障发生之前，是不是真的存在可以被提前抓住的异常信号。很多时候，答案已经有，只是我们一直没去想。