从半夜救火到 AI 自愈：传统运维→DevOps→AIOps 三代故障处置演进，附实战代码与落地路线图

我是韩先超，51CTO 学堂 K8s、Python 教学总监、AIOps 实战训练营讲师，云计算架构师，具有 8 年项目实战经验+5 年教学经验，线上学员已达 300w+。

不知道做技术的你，有没有体会过这种恐惧：半夜睡得正沉，手机突然炸响，运维告警电话打过来。线上出故障了，必须立刻爬起来处理。

同样是支付集群故障，我们看看不同年代，团队都是怎么扛过去的。

2012 年，双十一前夜

支付错误率从 0.02% 一路飙升到 8.7%。值班室瞬间乱成一锅粥。

几个人 ssh 登录十几台机器不停刷日志，有人翻 Excel 核对变更记录，微信群疯狂刷屏追问：刚才是谁上线改了东西。

折腾四十多分钟才定位，就因为新扩容机器少写了一行配置。

2018 年，已经用上 DevOps 的团队

发布流水线直接标红，金丝雀环境自动回滚。Grafana 看板一眼看到支付 P99 延迟从 80ms 直接冲到 1.2s。

十二分钟业务恢复，事后复盘，是配置中心默认参数和镜像内部配置发生冲突。

2025 年，AIOps 平台接管现场

故障发生第 90 秒，两万多条杂乱告警被压缩成一张根因卡片：新节点缺少服务发现标签。第 3 分钟，系统自动隔离问题节点，完成扩容。

人是故障处理完毕之后才被 @出来，只需要复核确认，不用连夜冲上去救火。

一模一样的业务故障，三个时代，完全不同的处置结局。

今天这篇文章，就把这条发展路线讲透：传统运维是怎么被业务规模压垮，DevOps 如何打破开发和运维之间厚厚的墙，而 AIOps，又是怎么把单纯的自动化，升级成完整的智能故障闭环。

文中有演进时间线、对比表格、国内真实事故案例，附带可直接上手的代码片段，最后还有一份可以直接拿去部门汇报的运

维成熟度落地路线图。

运维的五次跃迁，不要跳级建设

如果把 “保障系统稳定运行” 比作一条铁路，国内运维行业大致走过了五个阶段。

绝大多数公司没办法跳阶段升级。底层基础没打牢，直接上高阶方案，最后只会剩下一堆 PPT，落不了地。

简单总结三句话：

• 传统运维解决系统能不能跑起来；
• DevOps 解决系统能不能改得又快又稳；
• AIOps 解决业务迭代越来越快，人力已经跟不上的问题。

传统运维：系统稳不稳，全靠老师傅

十几年前做运维，这些场景，大家应该多少还有印象：

• 业务跑在物理服务器上面，机器 IP 记在 Excel 表格；
• 版本发布就是远程登录服务器，上传程序包，手动重启进程；
• 监控用 Zabbix、Nagios，阈值基本拍脑袋定，CPU 超过 80% 就发短信告警；
• 线上故障来了，先到处找人，再登录机器排查，最后才定位问题根源。

开发只管扔程序包，背锅的全是运维，开发、运维、测试三方壁垒分明。

这套模式在机器不多、版本更新频率低的时候很好用。

早年，银行核心、运营商计费系统，靠的就是经验丰富的老运维、固定变更窗口、双人复核制度维持稳定性。

但这套模式的短板也极其致命。

早期团队的自动化，很多就是把老运维的检查步骤写成 shell 脚本。脚本可以代替人执行检查，但是看不懂业务上下文，不会思考问题。

#!/usr/bin/env bash
# healthcheck.sh  2010年风格主机巡检脚本
# crontab定时: */5 * * * * /opt/ops/healthcheck.sh >> /var/log/ops-health.log 2>&1
set -euo pipefail
HOST=$(hostname)
WARN=()
cpu=$(top -bn1 | awk '/Cpu\(s\)/{print 100-$8}' | cut -d. -f1)
mem=$(free | awk '/Mem:/{printf("%d", $3/$2*100)}')
disk=$(df -P / | awk 'NR==2{gsub("%","",$5); print $5}')
[[ "$cpu"  -gt 85 ]] && WARN+=("CPU ${cpu}%")
[[ "$mem"  -gt 90 ]] && WARN+=("MEM ${mem}%")
[[ "$disk" -gt 85 ]] && WARN+=("DISK ${disk}%")
if ! curl -fsS --max-time 3 http://127.0.0.1:8080/health >/dev/null; then
  WARN+=("APP_HEALTH_DOWN")
fi
if ((${#WARN[@]})); then
  msg="[$HOST] $(date '+%F %T') ALERT: ${WARN[*]}"
  echo "$msg"
  # 对接邮件、短信、企业微信告警机器人
  echo "$msg" | mail -s "OPS ALERT $HOST" ops@company.com
  exit 1
fi
echo "[$HOST] $(date '+%F %T') OK cpu=$cpu mem=$mem disk=$disk"

脚本在二三十台机器的时候很好用，一旦规模扩大到两千台，就是灾难：

1. 阈值写死不变：大促期间 CPU 70% 属于正常负载，凌晨 CPU 30% 反而有可能线程死锁；
2. 完全没有业务上下文，不知道机器刚刚做过发布，也不知道下游服务出问题；
3. 告警广播轰炸，一出事所有人收到消息，等于没人负责；
4. 脚本只会报警，真正修复操作，依旧需要运维登录机器手动处理。

真实事故案例：某城商行月末批处理故障

背景：系统每天晚上 22 点跑批处理，月末业务文件量是平时 6 倍。运维参考上一年经验预留处理窗口。

根因：监控只采集磁盘空间，没有监控 inode 指标。更深层问题，故障检查要点全部装在老员工脑子里，没有固化成系统能力，容量没有和业务日历做联动。

这次事故造成对外营业延迟 80 分钟，收到监管问询，当晚 11 名技术人员通宵加班。

传统运维的真实写照：故障能救回来，靠的是老师傅；故障处理慢，也是因为只有老师傅。

过渡阶段：ITIL 标准化+虚拟化云时代

很多团队误以为上一套工单系统就是 DevOps，其实这只是用流程对抗混乱的阶段。

ITIL、ISO20000 给运维带来一套完整可审计的服务体系：事件管理、问题管理、变更管理、配置管理、发布管理。

CMDB 试图梳理清楚企业所有 IT 资产以及相互依赖关系。

ITIL 是企业运维走向成熟的必经之路，但绝对不是终点。

互联网业务迭代加快，发布频率从每月一次变成一天几十次，固定变更窗口本身，反而成为故障的来源，大量变更积压集中在窗口爆发。

紧接着，随着虚拟化、公有云的到来，申请一台服务器从两周缩短到两分钟。

但是新麻烦接踵而至：虚拟机漂移、镜像腐化、安全组配置出错；一台物理机宕机，上面几十个业务同时疯狂告警。

这个阶段最重要的成果：基础设施变成 API 接口。没有这个基础，后面的 IaC、弹性伸缩根本无从谈起。

resource "aws_autoscaling_group" "pay" {
  min_size         = 4
  max_size         = 40
  desired_capacity = var.desired
  tag {
    key                 = "service"
    value               = "payment"
    propagate_at_launch = true
  }
}

DevOps：拆掉部门墙，把上线交给流水线

很多人有个误区：招个岗位叫 DevOps 工程师，买一套 Jenkins，就算落地 DevOps。并不是。行业常用 CALMS 模型理解 DevOps。

谷歌 SRE 进一步把这套理念工程化，提出错误预算、SLO，尽量消除纯手工重复劳动（Toil）。

国内大厂实践也证明高频发布和稳定性并不冲突，前提是自动化体系足够扎实。

DevOps 核心衡量：DORA 四大指标

注意：四个指标要结合看。只追求上线速度，不控制失败率，等于加速制造线上事故。

DevOps 最小闭环链路

代码提交 → 自动构建自动化测试 → 制品仓库保存镜像 → 基础设施即代码(IaC)→ 金丝雀/蓝绿滚动发布 → 完整可观测体系(指标、日志、链路追踪)→ 自动回滚、服务熔断 → 故障复盘反哺流水线规则

下面是一份简化的 GitHub Actions 流水线示例，重点体现测试门禁、不可变镜像、金丝雀发布、SLO 自动回滚逻辑。

# .github/workflows/pay-service.yml
name: pay-service-cd
on:
  push:
    branches: [main]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 单元测试 + 契约测试
        run: |
          go test ./... -count=1
          npm run test:contract
      - name: 构建推送镜像
        run: |
          docker build -t harbor.example.com/pay:${{ github.sha }} .
          docker push harbor.example.com/pay:${{ github.sha }}
  canary:
    needs: ci
    runs-on: ubuntu-latest
    steps:
      - name: 部署5%流量金丝雀
        run: |
          kubectl set image deploy/pay pay=harbor.example.com/pay:${{ github.sha }}
          kubectl argo rollouts set weight pay 5
      - name: 金丝雀观察10分钟
        run: |
          python scripts/slo_gate.py \
            --service pay \
            --slo error_rate<0.1 \
            --slo p99_ms<200 \
            --window 10m
      - name: 确认发布或者自动回滚
        run: |
          kubectl argo rollouts promote pay || \
          kubectl argo rollouts abort pay

配套 SLO 质量门禁脚本，金丝雀阶段拿真实业务流量做校验：

# scripts/slo_gate.py
import os, sys, time, requests
PROM = os.environ["PROM_URL"]
QUERY = '''
sum(rate(http_requests_total{service="pay",code=~"5.."}[2m]))
/
sum(rate(http_requests_total{service="pay"}[2m]))
'''
def error_rate():
    r = requests.get(f"{PROM}/api/v1/query", params={"query": QUERY}, timeout=5)
    v = float(r.json()["data"]["result"][0]["value"][1])
    return v
deadline = time.time() + 600
while time.time() < deadline:
    rate = error_rate()
    print(f"pay error_rate={rate:.4%}")
    if rate > 0.001:
        sys.exit("SLO超出阈值，终止金丝雀发布")
    time.sleep(15)
print("金丝雀运行正常，允许全量发布")

实战案例：电商大促，DevOps 改造前后对比

改造前 2016 双十一： 发布窗口 22 点‑凌晨 2 点，一次性上线 37 个变更；回滚需要找旧包核对配置，平均 46 分钟；变更失败率 18%，40 人现场通宵值守。

改造后 2018 双十一：

曾经发生一次线上险情：优惠券服务配置折扣上限填错，金丝雀 5% 流量就出现异常 GMV，SLO 门禁 4 分钟直接中止发布，回滚，业务用户几乎没有感知。

DevOps 核心不是让开发上线更快，而是把上线出错的代价变低，做到可回滚、可度量、可控。

DevOps 补齐三件套：SRE、可观测、平台工程

很多团队流水线搭完，线上故障依旧不断，大多是下面三块没做扎实。

SRE：错误预算解决 “要速度还是要稳定” 的争吵

SLO 设定服务可用指标，比如 99.9% 可用，换算下来每月错误预算大约 43 分钟。

错误预算消耗完毕 → 暂停新功能上线，优先解决稳定性债务；

错误预算还很充足 → 可以大胆迭代实验。

可观测性：不只看机器活没活，要看用户疼不疼

传统监控盯着 CPU 内存；可观测性回答：用户请求慢不慢、报不报错、卡在哪个调用环节，和哪次上线变更有关系。

这里，Metrics 指标、Logs 日志、Traces 调用链，再加上变更事件，四样东西要打通，不能是四套割裂系统。

一份贴近业务的告警，不应该是简单 CPU>80%，而是盯着业务 SLO：

groups:
  - name: pay-slo
    rules:
      - alert: PayErrorBudgetBurn
        expr: |
          (
            sum(rate(http_requests_total{service="pay",code=~"5.."}[5m]))
            /
            sum(rate(http_requests_total{service="pay"}[5m]))
          ) > 0.001
        for: 2m
        labels:
          severity: page
          service: pay
        annotations:
          summary: "支付错误率消耗错误预算"
          dashboard: "https://grafana.example.com/d/pay"
          playbook: "https://wiki.example.com/runbook/pay-5xx"

平台工程：把 DevOps 变成所有人的默认体验

如果每个业务小组都自己搭一套 Jenkins、自己写 Dockerfile，就会出现几十套五花八门的流水线，维护成本爆炸。

平台工程目标就是提供一条金色标准路径：开发做完代码 git push，自动完成构建、安全扫描、发布、观测、权限管控，不需要各个业务团队重复造轮子。

没有标准化平台，后面做 AIOps 就是空中楼阁。

AI 运维平台需要干净、统一、带业务语义的数据，乱七八糟的 “雪花环境” 喂不出靠谱的算法。

AIOps：从固定自动化规则，走向系统自主判断

为什么 DevOps 之后，还需要 AIOps？

DevOps 把版本迭代速度拉高一个量级，随之而来新的痛点：

• 微服务拆分之后，告警数量暴涨，值班人员被告警风暴淹没；
• 一次故障牵扯上百个服务，人脑梳理不完复杂调用拓扑；
• 80% 故障都是历史故障变体，但是每次处理都要重新排查；
• 夜班风险最高，但是人的状态最差，很容易误操作。

DevOps 擅长处理输入明确、规则写死的自动化；AIOps 擅长处理噪声多、原因不确定的复杂场景。

AIOps 能力落地优先级，别上来就买酷炫大屏

很多厂商一上来就推销根因大屏、大模型聊天机器人。实际落地要讲究投入产出顺序。

举个极简动态基线示例，用历史同时间段数据判断异常，而不是写死阈值：

"""anomaly_baseline.py
中位数+MAD实现稳健动态基线，抵御毛刺尖峰干扰
"""
from collections import defaultdict
from datetime import datetime, timedelta
import numpy as np
def mad_based_score(series):
    median = np.median(series)
    mad = np.median(np.abs(series - median)) or 1e-6
    robust_z = 0.6745 * (series[-1] - median) / mad
    return float(robust_z), float(median)
def is_anomaly(history_same_slot, current, z_th=4.0):
    arr = np.array(list(history_same_slot) + [current], dtype=float)
    z, baseline = mad_based_score(arr)
    seasonal = current > baseline * 3 and current > 0.05
    return (abs(z) >= z_th) or seasonal, z, baseline
# 示例：周五晚高峰业务本身流量就高，不能复用工作日阈值
ok, z, base = is_anomaly([0.0002, 0.0003, 0.0002, 0.0004], current=0.012)
print(f"anomaly={ok} z={z:.2f} baseline={base:.4%}")

告警收敛，依靠时间窗口、服务拓扑、文本相似度把大量告警聚合成事件：

"""alert_cluster.py 简化告警聚合逻辑"""
from dataclasses import dataclass
from datetime import datetime, timedelta
from difflib import SequenceMatcher
@dataclass
class Alert:
    t: datetime
    service: str
    fingerprint: str
    msg: str
    parent: str
def same_incident(a: Alert, b: Alert, window=timedelta(minutes=5)) -> bool:
    if abs((a.t - b.t).total_seconds()) > window.total_seconds():
        return False
    if a.service == b.service or a.parent == b.service or b.parent == a.service:
        return True
    if a.fingerprint == b.fingerprint:
        return True
    return SequenceMatcher(None, a.msg, b.msg).ratio() > 0.75
def cluster(alerts: list[Alert]) -> list[list[Alert]]:
    groups = []
    for alert in sorted(alerts, key=lambda x: x.t):
        for g in groups:
            if any(same_incident(alert, x) for x in g):
                g.append(alert)
                break
        else:
            groups.append([alert])
    return groups

拿到聚合事件，再结合变更记录、拓扑上下游做根因打分，优先怀疑先报错的、上游依赖的、刚刚发布变更的服务。

自愈功能诱惑力最大，风险也最高

绝对不能无脑全量自动修复，一定要分级+安全护栏。

简单带防护的隔离逻辑示例：

"""heal.py 带安全护栏的自动缓解"""
class Guard:
    def __init__(self, min_ready=3, max_drop_ratio=0.3):
        self.min_ready = min_ready
        self.max_drop_ratio = max_drop_ratio
    def can_isolate(self, ready: int, isolate_n: int) -> bool:
        if ready - isolate_n < self.min_ready:
            return False
        if isolate_n / max(ready, 1) > self.max_drop_ratio:
            return False
        return True
def maybe_isolate(k8s, svc, bad_pods, guard: Guard, dry_run=True):
    ready = k8s.ready_count(svc)
    if not guard.can_isolate(ready, len(bad_pods)):
        return {"action": "escalate_to_human", "reason": "安全护栏拦截"}
    if dry_run:
        return {"action": "isolate", "pods": bad_pods, "dry_run": True}
    for pod in bad_pods:
        k8s.cordon_and_delete(pod)
    return {"action": "isolate", "pods": bad_pods, "dry_run": False}

大模型加入之后，AIOps 变成什么样

大模型不会直接替代时序异常检测，更多补齐运维里语言、知识编排这块短板。

大模型负责推理和语言表达；统计模型负责识别指标异常；策略引擎守住安全底线。三者缺一，都只是演示 Demo，不能上生产。

真实案例：上千微服务团队如何解决告警风暴

规模背景：1200 个微服务，每天产生 18 万条告警。夜班运维人均接收 200 多条告警，真正需要人介入处理的故障不到 8 起。

一次可用区网络抖动，瞬间 400 个服务同时告警，值班人员 20 分钟分不清应该扩容还是回滚。

具体分三期，历时 9 个月落地 AIOps：

第一步：统一实体标签，每一条告警必须带上 service、env、change_id 标签，标签缺失直接降级丢弃；

第二步：告警事件收敛，5 分钟窗口内、拓扑相关告警合并为事件。日均 18 万告警压缩到 220 个事件；

第三步：根因分析，把变更事件当做一等分析条件，70% 故障根源来自近 30 分钟内的变更；

最后才上自愈，只开放 L1 级别动作（摘除实例、扩容熔断）；回滚等高风险操作必须人工确认。

落地前后对比：

踩过的大坑：项目最开始直接采购 AI 根因大屏，算法准确率只有 40%，开发吐槽和算命差不多。

几乎没有改动算法，只是把底层数据治理做好，相同算法准确率直接提升到 78%。AIOps 核心在数据，不是算法本身。

三类故障处置模式横向对比（支付类故障）

写在最后

传统运维时代，我们崇拜半夜冲进机房把系统修好的工程师。

DevOps 时代，我们崇拜搭建体系，让半夜故障尽量不再发生的系统。

AIOps 时代，我们追求一套闭环，在海量告警噪声下，做出正确并且可以撤销的自动化决策。

三者不是互相否定，是工具的迭代升级。

1. 先把人的经验固化为脚本，摆脱纯手工；
2. 再把脚本升级成流水线、基础设施即代码，摆脱个人英雄主义；
3. 最后基于流水线沉淀下来的数据，构建智能能力，摆脱人肉应对大规模系统。

团队不用一上来就启动宏大 AIOps 项目。

从一件小而硬的实事入手就足够：挑一个核心业务服务，把 SLO 定下来，落地金丝雀发布，告警全部带上 service 标签，写一份真正能拿来执行的 Runbook。

这四件事做好，AI 运维才能落地。