智能运维实战：把一次故障复盘，变成一套可复用的能力

一、从一次真实的故障说起

去年大促前压测，我们遇到过一次典型故障。晚上 8 点，支付链路成功率从 99.9% 掉到 97%，值班群里在 3 分钟内涌入 470 条告警：数据库连接数告警、网关超时告警、订单服务 5xx 告警、Redis 慢查询告警……工程师一边翻告警一边猜，20 分钟后才定位到真正原因——优惠券服务的一次批量查询把数据库连接池占满，拖垮了下游。

复盘时我们问了自己一个问题：如果同样的故障再来一次，系统能不能在 1 分钟内告诉我们"根因在优惠券服务"？ 这篇文章就是这次复盘之后，我们真正落地的一套智能运维实战方案。它不追求"大平台"，只解决四个具体问题：告警太多、根因难找、日志看不懂、扩容靠拍脑袋。

二、实战前提：先把数据底座搭对

所有智能分析的前提，是数据"能用"。我们只做了三件最基础的事，但这三件事决定了后面所有模型的效果：

• 统一标签：所有指标、日志、链路强制带上 service、instance、env、region 四个标签。没有 service 标签的数据，一律不允许接入监控。
• 补齐拓扑：把服务间的调用关系（谁调谁）沉淀成一张图，这是后面根因分析的骨架。
• 对齐时间：所有数据源统一到秒级时间戳，避免"日志比指标慢 30 秒"导致的关联错位。

这三件事很枯燥，但它们是实战的地基。跳过它们直接上模型，是我们见过最多、也最昂贵的错误。

三、场景一：告警降噪——把 470 条变成 3 条

第一仗打告警。核心思路是同源聚合：在同一个时间窗内、同一服务或同一拓扑邻域内的告警，本质上往往是同一个故障的不同表现，应该合并成一个"事件"。

下面这段代码实现了一个简化的聚合器：按服务归属和时间窗把告警聚类。

from collections import defaultdict

def aggregate_alerts(alerts, window=120):
    """
    alerts: [{"service": "...", "type": "...", "ts": 秒级时间戳}, ...]
    window: 聚合时间窗（秒）
    返回按 (service, 时间桶) 聚合后的事件列表
    """
    buckets = defaultdict(list)
    for a in alerts:
        bucket = a["ts"] // window          # 落到时间桶
        buckets[(a["service"], bucket)].append(a)

    events = []
    for (service, bucket), group in buckets.items():
        types = sorted({a["type"] for a in group})
        events.append({
            "service": service,
            "start_ts": bucket * window,
            "count": len(group),
            "types": types,
            "summary": f"{service} 在 {window}s 内触发 {len(group)} 条告警：{', '.join(types)}"
        })
    return events

在真实系统里，我们还会把拓扑关系加进来：如果 A 服务告警、它依赖的 B 服务同时告警，优先把根指向更下游的 B。上线后，那次故障场景的 470 条告警被压缩成了 3 个事件，值班同学的注意力终于能聚焦了。

四、场景二：根因定位——用相关性说话

降噪之后，下一步是回答"根因在哪"。我们用的方法不复杂但很有效：在故障时间窗内，计算各服务关键指标（错误率、延迟、连接数）与故障指标的相关性，再结合拓扑下游优先原则排序。

def pearson(x, y):
    n = len(x)
    mx, my = sum(x) / n, sum(y) / n
    cov = sum((a - mx) * (b - my) for a, b in zip(x, y))
    sx = sum((a - mx) ** 2 for a in x) ** 0.5
    sy = sum((b - my) ** 2 for b in y) ** 0.5
    return cov / (sx * sy + 1e-9)

def rank_root_cause(fault_series, candidates):
    """
    fault_series: 故障指标的时序（如支付成功率）
    candidates: {"服务名": 该服务指标时序}
    返回按相关性绝对值排序的候选根因
    """
    scored = [(svc, round(abs(pearson(fault_series, s)), 3))
              for svc, s in candidates.items()]
    return sorted(scored, key=lambda x: -x[1])

输出可能像这样：[("coupon-service", 0.91), ("order-service", 0.62), ("gateway", 0.31)]。再叠加一条拓扑规则——故障服务的下游依赖优先——就足以把工程师快速引导到正确的方向上。这套逻辑不"炫技"，但在那次复盘中，它把定位时间从 20 分钟压到了 2 分钟以内。

五、场景三：日志异常检测——不用看懂每条日志

日志的问题不是"少"，而是"多且杂"。我们的做法分两步：先把日志模板化（把变量抽掉，留下结构），再对模板的出现频次做异常检测。频次突增的模板，往往就是故障的指纹。

import re

def to_template(line):
    # 把数字、UUID、IP 等变量替换为占位符，得到日志模板
    line = re.sub(r"\b[0-9a-f]{8}-[0-9a-f-]{27}\b", "<UUID>", line)
    line = re.sub(r"\b\d{1,3}(\.\d{1,3}){3}\b", "<IP>", line)
    line = re.sub(r"\b\d+\b", "<NUM>", line)
    return line.strip()

# 示例
print(to_template("2024-06-01 20:03:11 ERROR db pool timeout, conn_id=88231, host=10.2.3.4"))
# -> "ERROR db pool timeout, conn_id=<NUM>, host=<IP>"

得到模板后，按分钟统计每个模板的出现次数，套用第三节的滑动窗口异常检测，就能自动发现"某个错误模板突然暴涨"。实战中，这条能力让我们在故障发生 40 秒内就抓到了 db pool timeout 的爆发曲线。

六、场景四：从"预测"到"自愈"的闭环

预测和自愈是智能运维真正产生业务价值的地方，但也是最需要谨慎的地方。我们的原则是：先预测、后建议、再自动，逐级放开。

• 容量预测：对核心服务的 QPS 和连接数做趋势预测（Prophet 或简单的季节分解即可），提前 30 分钟给出扩容建议；
• 自动扩缩容：只对无状态服务开放自动扩容，缩容保留人工确认；
• 自动自愈：先只做"重启异常实例""摘除不健康节点"这类低风险动作，且必须带熔断条件——连续自愈失败 2 次就立刻转人工。

这条闭环上线后，我们统计到一个很有说服力的数字：无状态服务的平均恢复时间（MTTR）下降了约 45%，而人工介入次数减少了近六成。

七、实战中最容易踩的三个坑

坑一：模型很准，数据很脏。 我们有次异常检测天天误报，最后发现是某台机器的时钟偏了 5 分钟，导致指标错位。数据治理的价值永远高于模型调参。

坑二：追求全自动，一次误操作代价巨大。 自动化一定要有"熔断"和"可回滚"，宁可少自动一点，也不能让 AI 的误判直接作用在生产上。

坑三：没有度量，就说不清价值。 我们从第一天就盯四个指标：告警量、MTTR、误报率、自动化处置率。没有这四个数字，AIOps 项目在预算会上很难活下去。

八、结语

回头看，这次智能运维实战最大的收获不是某个算法，而是把一次故障复盘沉淀成了一套可复用的能力：告警聚合让它"看得清"，根因排序让它"找得准"，日志模板让它"听得懂"，预测自愈让它"动得快"。

智能运维不是一个要一次性建成的大平台，而是一组可以逐个击破的实战场景。选一个痛点最深的场景，用最朴素的方法跑通闭环，拿到可量化的收益——这比任何架构图都更有说服力。