想象你是一家三甲医院的值班医生。凌晨两点，呼叫器同时炸响：3 床血压偏低、5 床心率失常、9 床体温 39.8 度……你被警报声淹没，疲于奔命地逐个查看。更糟的是，等护士跑去重测时，多数警报早已自行消失——它们只是监测仪的抖动，真正的危机反而可能藏在某个没响的角落里。这就是今天大多数运维团队（SRE，可以理解为“系统的家庭医生”）的日常：CPU、延迟、错误率这些“生命体征”由监控系统盯着，但海量告警让人麻木，一次故障要人工翻日志查几小时。AIOps（智能运维）就像给医院装上一套“AI 分诊系统”：它自动识别哪些指标真的异常，把相似症状归并成一条告警，顺着“血脉”（服务调用链）帮你找到病根，甚至在病人倒下之前就发出预警。这篇“病历式”教程，会带你完整走一遍 AIOps 的异常检测、阈值调优、根因分析、告警降噪、混沌工程配合与效果度量，让 SRE 团队从“救火英雄”变成“体检医生”。

岗位关联

掌握 AIOps 异常检测与根因分析，等于给系统配上全天候的“AI 值班医生”。这是 SRE 从被动救火走向主动预防的分水岭，也是可观测性工程落地后最直接的收益点。

目录
  1. 可视化演示
  2. AIOps核心理念：从救火队到体检中心
  3. 异常检测算法：护士手里的体温计
  4. 阈值调优策略：会“长大”的体温基线
  5. 根因分析推理：医生的鉴别诊断
  6. 告警降噪：急诊分诊台
  7. 混沌工程配合：给系统打疫苗
  8. 效果度量：体检报告说了算
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示3-Sigma异常检测时序阈值、服务拓扑根因传播路径、告警风暴降噪聚合三阶段交互探索。

本节配有交互动效（进入视口后自动加载，约 3KB）。

3-Sigma时序异常检测 指标时序波形实时滚动扫描 超出±3σ阈值标记异常点 Z = |x - μ| / σ, anomaly if Z > 3 统计方法适合CPU内存等稳定指标

AIOps核心理念：从救火队到体检中心

急诊科医生和体检科医生最大的区别是什么？急诊科医生永远在抢救，永远被最响的警报牵着走，永远缺人手；体检科医生则拿着报告单，提前发现血压血脂的异常趋势，把大病扼杀在摇篮里。AIOps 要做的，就是把 SRE 团队从“急诊科”推向“体检科”——这也是 AIOps 三个字的本意：AI + IT 运维。

具体怎么做？它把系统运行的海量数据当作“体检样本”：指标（CPU、内存、延迟，相当于体温血压）、日志（系统自己说了什么，相当于病人的主诉）、链路（请求经过了哪些服务，相当于血液流向）。传统监控只回答“现在超过阈值了吗”，AIOps 用机器学习回答更难的问题：接下来会出问题吗？问题到底出在哪？于是形成三大核心任务——异常检测（发现症状）、根因分析（定位病根）、告警降噪（过滤噪音）。

衡量“发现得快不快”，行业里有一个硬指标叫 MTTD（Mean Time To Detect，平均故障发现时间）。它统计从故障发生到被 AI 发现，平均要花多少分钟。

从“等呼叫器响”到“主动看体检报告”，这就是 AIOps 带给 SRE 的能力跃升：同样的团队规模，却能照看十倍的系统规模。

MTTD=TtotalNfaults\displaystyle \text{MTTD} = \frac{T_{\text{total}}}{N_{\text{faults}}}
把一段时间内所有故障的“发现耗时”加起来，除以故障次数，就是平均发现时间。MTTD 越短，说明 AI 这个“体检医生”越敏锐。
  1. 总发现耗时 T_total每个故障从发生到被系统捕获的时间，全部累加。
    Ttotal=∑i=1nti\displaystyle T_{\text{total}} = \sum_{i=1}^{n} t_i
  2. 故障次数 N_faults统计周期内一共发生了多少次故障。
    Nfaults=n\displaystyle N_{\text{faults}} = n
  3. 相除取平均总耗时除以次数，得到“平均多久能发现一次故障”。
    MTTD=TtotalNfaults\displaystyle \text{MTTD} = \frac{T_{\text{total}}}{N_{\text{faults}}}

异常检测算法：护士手里的体温计

护士判断病人是否发烧，靠的是体温计和一条“正常体温范围”。如果只靠手感，每个护士标准都不一样。异常检测算法，就是那根刻度精确的体温计——它先根据历史数据算出系统指标的“正常波动区间”，再判断当前读数是否越界。

最简单也最常用的方法是统计阈值法，核心是统计学里的 3σ 法则。它假设正常指标围绕一个均值 μ 上下波动，波动幅度用标准差 σ 描述。某个读数 x 如果离均值太远，超出 3 个标准差，就怀疑是异常。要判断“多远算远”，我们把它换算成一个标准化的分数 z：

除了统计法，还有机器学习模型派：时序预测（用历史预测“本该是多少”，实际与预测差太多即异常）、孤立森林（把稀有的离群点“孤立”出来）。选型经验是：指标平稳的业务先上 3σ，成本低、可解释性强；流量模式复杂的核心链路再叠加模型。体温计准不准，直接决定护士信不信任它——算法选错，要么漏诊要么误报，AIOps 就会沦为“狼来了”的放羊娃。

z=∣x−μ∣σ\displaystyle z = \frac{|x - \mu|}{\sigma}
z 表示“当前值偏离正常均值多少个标准差”。|z| 大于 3 时，意味着这个读数在正态分布下出现的概率不足 0.3%，大概率不是正常抖动。
  1. 当前读数 x此刻采集到的指标值，比如 CPU 利用率 92%。
    x\displaystyle x
  2. 历史均值 μ过去一段时间数据的平均值，代表“正常水平”。
    μ=1n∑i=1nxi\displaystyle \mu = \frac{1}{n}\sum_{i=1}^{n} x_i
  3. 标准差 σ衡量数据围绕均值波动的剧烈程度，σ 越大说明平时颠簸越厉害。
    σ=1n∑i=1n(xi−μ)2\displaystyle \sigma = \sqrt{\frac{1}{n}\sum_{i=1}^{n}(x_i - \mu)^2}
  4. 相除得到 z 分数把“偏离量”除以“正常波动幅度”，得到标准化的偏离程度。
    z=∣x−μ∣σ\displaystyle z = \frac{|x - \mu|}{\sigma}

阈值调优策略：会“长大”的体温基线

儿童正常体温 36.5~37.5 度，剧烈运动后 38 度也算正常。如果医院对所有人都用同一个“37 度报警”阈值，操场跑完步的孩子全得被隔离。系统也一样：白天高峰 CPU 70% 很正常，凌晨三点 CPU 70% 就是事故。固定的“37 度”式阈值，在真实业务里必然误报刷屏。

于是有了动态基线：让“正常范围”跟随时间、流量、业务周期流动。周末的低流量和工作日的高峰会形成完全不同的基线；大促日的基线甚至要单独建模。实现动态基线最经典的工具是 EWMA（指数加权移动平均），它给新数据更大的权重，给旧数据逐渐衰减的权重：

调优时还要做业务维度分层：每个服务、每个机房、每个时段各算各的基线；遇到数据漂移（比如新版本上线导致指标分布整体偏移），要能自动重新学习。好的基线就像会“长大”的体温标准：既懂孩子和成人的区别，也懂白天和黑夜的区别。

EWMAt=α×xt+(1−α)×EWMAt−1\displaystyle \text{EWMA}_t = \alpha \times x_t + (1-\alpha) \times \text{EWMA}_{t-1}
新基线 = 新数据占 α 份信任 + 旧基线占 (1−α) 份信任。α 越大越“跟手”，α 越小越“平滑”。
  1. 新观测值 x_t当前最新一个指标读数。
    xt\displaystyle x_t
  2. 上一时刻基线 EWMA_{t-1}截至上一分钟平滑出来的正常水平。
    EWMAt−1\displaystyle \text{EWMA}_{t-1}
  3. 平滑系数 α取值 0 到 1 之间，决定对新数据的信任程度。
    α∈(0,1)\displaystyle \alpha \in (0, 1)
  4. 加权合成新基线新旧信息按权重混合，得到跟随业务“呼吸”的动态基线。
    EWMAt=α×xt+(1−α)×EWMAt−1\displaystyle \text{EWMA}_t = \alpha \times x_t + (1-\alpha) \times \text{EWMA}_{t-1}

根因分析推理：医生的鉴别诊断

护士发现你高烧 39 度，但高烧只是症状，原因可能是流感、肺炎甚至阑尾炎。医生要做的“鉴别诊断”，就是 AIOps 的根因分析（RCA，Root Cause Analysis）：从“哪里不舒服”倒推“哪里真正坏了”。微服务架构下，一次故障牵一发动全身，错误地把忙碌的下游当成凶手是家常便饭。

推理手段有三个递进层次。第一是调用链追踪：像看血脉流向一样，找出请求在哪一跳耗时暴增；第二是拓扑图定位：画出服务之间的依赖关系，圈出嫌疑范围；第三是关联分析：看哪些指标在同步异常。关联分析用皮尔逊相关系数度量两个指标是否“同呼吸共命运”：

但相关系数高不等于因果，就像高烧和头痛相关，真正的病根可能是肺炎。要确认因果方向，必须结合调用链和拓扑图：谁调用谁、谁的下游先出问题，方向对了才是根因。医生不会只看体温计，还会压压你的肚子——RCA 的“组合拳”才能找到真正发炎的器官。

ρ=∑i=1n(ai−μa)(bi−μb)n×σa×σb\displaystyle \rho = \frac{\sum_{i=1}^{n}(a_i - \mu_a)(b_i - \mu_b)}{n \times \sigma_a \times \sigma_b}
ρ 的取值范围是 [-1, 1]。越接近 1，两个指标越同步上涨；越接近 -1，越此消彼长；接近 0 则互不相干。
  1. 两个指标的样本 a_i、b_i例如支付成功率和数据库连接数在每分钟的取值。
    ai, bi\displaystyle a_i,\ b_i
  2. 分子是协方差两个指标同时偏离各自均值的平均程度，度量“共舞”的强度。
    cov(a,b)=1n∑i=1n(ai−μa)(bi−μb)\displaystyle \text{cov}(a,b) = \frac{1}{n}\sum_{i=1}^{n}(a_i - \mu_a)(b_i - \mu_b)
  3. 分母是两个标准差的乘积把协方差归一化，消除两个指标量纲不同的问题。
    σa×σb\displaystyle \sigma_a \times \sigma_b
  4. 相除得到相关系数 ρ标准化后的“共舞”分数，越接近 1 越可疑。
    ρ=cov(a,b)σa×σb\displaystyle \rho = \frac{\text{cov}(a,b)}{\sigma_a \times \sigma_b}

告警降噪：急诊分诊台

急诊室最忙的时候，十个病人同时喊疼。经验丰富的护士不会挨个跑，而是先分诊：谁在流血、谁只是擦伤、哪些症状其实是同一种病，按轻重缓急处理。AIOps 的告警降噪就是这套分诊逻辑——一个数据库故障，会引发订单超时、网关 5xx、用户投诉系统连环报警，不降噪的话值班群一分钟刷 50 条。

降噪四板斧。第一是告警聚合：同一时间窗口内，把同一类事件合成一条；第二是告警去重：同一个指标反复越界，只保留第一条，等它恢复后再重新计数；第三是抑制规则：下游服务的告警被上游根因告警“压制”——既然爹病倒了，儿孙的哭喊就不用全报；第四是优先级排序，给每条告警打个分数，让最严重的排最前：

分诊台的价值不是让警报消失，而是让值班人员只听到“必须听”的那一声。降噪做得好，SRE 才有精力在真正的大故障面前保持清醒。

P=w1×S+w2×L+w3×D\displaystyle P = w_1 \times S + w_2 \times L + w_3 \times D
优先级 P = 影响范围权重 × 受影响规模 + 严重度权重 × 偏差程度 + 持续时间权重 × 已持续分钟数。分数越高，越要优先处理。
  1. 影响范围 S受影响的用户数或服务数，相当于“有多少病人被牵连”。
    S\displaystyle S
  2. 严重度 L错误率、延迟超出基线的倍数，相当于“病情有多重”。
    L\displaystyle L
  3. 持续时间 D异常已经持续的分钟数，相当于“已经烧了多久”。
    D\displaystyle D
  4. 加权求和得优先级 P三个维度各乘权重后相加，权重 w 由团队按业务经验设定。
    P=w1×S+w2×L+w3×D\displaystyle P = w_1 \times S + w_2 \times L + w_3 \times D

混沌工程配合：给系统打疫苗

疫苗的原理，是注入少量灭活的病毒，让免疫系统提前练兵。混沌工程（Chaos Engineering）一模一样：在可控条件下主动向系统注入故障，看异常检测能不能发现、根因分析能不能定位、应急预案能不能兜住。很多团队上了 AIOps 后心里没底：“这套 AI 真出故障时靠谱吗？”混沌工程就是答案——用演练验证 AI，而不是等真故障来验证。

具体做法分四步。第一步是故障注入：注入延迟、断连、杀进程、资源耗尽等实验性故障；第二步是演练验证：观察 AIOps 是否如预期报警和定位；第三步是打磨应急预案：把演练中暴露出的处置盲点补进值班手册；第四步是持续韧性测试，用韧性分量化系统的抗打击能力：

打过疫苗的身体，遇到真病毒才能从容应对；演练过的系统，遇到真故障才不会“第一次见”。混沌工程是 AIOps 最好的试金石，两者配合，团队对系统韧性的信心才不是玄学。

Rscore=1−NfailNtotal\displaystyle R_{\text{score}} = 1 - \frac{N_{\text{fail}}}{N_{\text{total}}}
韧性分 = 1 − 演练失败率。演练中系统稳态被破坏且无法自动恢复的次数越少，韧性分越接近 1，系统越扛打。
  1. 演练失败次数 N_fail注入故障后，稳态指标被破坏且没有自动恢复的演练次数。
    Nfail\displaystyle N_{\text{fail}}
  2. 总演练次数 N_total统计周期内完成的故障注入实验总数。
    Ntotal\displaystyle N_{\text{total}}
  3. 用 1 减去失败率把失败率转化为“成功率”，越接近 1 越坚韧。
    Rscore=1−NfailNtotal\displaystyle R_{\text{score}} = 1 - \frac{N_{\text{fail}}}{N_{\text{total}}}

效果度量：体检报告说了算

病人恢复得好不好，不能靠一句“我感觉不错”，要看体温曲线、白细胞计数这些客观数据。AIOps 的效果同样要量化，否则“用了 AI 以后稳多了”只是心理安慰。度量维度有三层：检测能力、恢复速度、告警质量。

检测能力看两个指标：异常检出率（真正的故障有多少被 AI 抓到）和告警误报率（报警里有多少是虚惊一场）。恢复速度看 MTTD 和 MTTR（Mean Time To Repair，平均故障恢复时间）——发现得早、恢复得快，损失就小。但单纯追求检出率会让误报刷屏，单纯压低误报又会漏掉真故障，于是用 F1 分数把两者拧成一个综合分：

最后别忘了压测加固闭环：每次大促前的产线压测、每次混沌演练的结果，都要回流到基线调优和告警规则里。从“感觉更稳了”到“数据证明更稳了”，AIOps 团队才能持续获得老板和同事的信任。

F1=2×P×RP+R,P=TPTP+FP,R=TPTP+FN\displaystyle F1 = \frac{2 \times P \times R}{P + R}, \quad P = \frac{TP}{TP + FP}, \quad R = \frac{TP}{TP + FN}
P 是精确率：报出来的告警里真故障占多少；R 是召回率：真实故障里被找出的占多少。F1 是两者的调和平均，任何一方偏科都会拉低总分。
  1. 真正例 TP、假正例 FP、假负例 FNTP 是故障发生且被检出；FP 是没故障却报警；FN 是故障发生但漏报。
    TP, FP, FN\displaystyle TP,\ FP,\ FN
  2. 精确率 P分母是“报出的全部告警”，衡量报警的含金量。
    P=TPTP+FP\displaystyle P = \frac{TP}{TP + FP}
  3. 召回率 R分母是“真实发生的全部故障”，衡量抓捕的完整度。
    R=TPTP+FN\displaystyle R = \frac{TP}{TP + FN}
  4. F1 调和平均P 和 R 互为短板，取调和平均得到一个“不偏科”的综合分。
    F1=2×P×RP+R\displaystyle F1 = \frac{2 \times P \times R}{P + R}

AI 应用场景

电商大促全链路巡检

阶段：异常检测 + 阈值调优

解决的问题：大促流量是平时的 10 倍，固定阈值疯狂误报。传统做法是临时人工调阈值，调到多少全凭感觉，一晚上值班群被无效告警淹没。

具体案例：某电商 SRE 团队在大促前用过去三年的大促指标训练动态基线，按商品页、订单、支付等业务维度分开建模，用 EWMA 跟随流量曲线，3σ 检测实时扫描。结果误报率从每小时 200 条降到 10 条以内，真正的水位异常反而在 3 分钟内就被捕获。

微服务故障快速定位与告警降噪

阶段：根因分析 + 告警管理

解决的问题：一次订单服务抖动引发下游 20 个服务连环告警，值班人员靠肉眼翻链路图定位，平均耗时 45 分钟。传统告警系统把“症状”和“病根”混为一谈。

具体案例：支付服务数据库连接池耗尽时，AIOps 检测到支付成功率、订单超时率、数据库连接数三个指标同步飙升，相关系数超过 0.9；结合服务拓扑确认订单服务调用支付服务，5 秒给出根因候选。同时 46 条告警被聚合去重为 2 条：一条“支付数据库连接池耗尽（根因）”、一条“订单超时率上升（衍生）”。

混沌工程演练与韧性验收

阶段：故障注入 + 效果度量

解决的问题：AIOps 系统上线后，团队不知道它在真实故障面前是否可靠。传统做法只能等线上出事来“检验”，代价巨大。

具体案例：某团队每月举行一次 GameDay（游戏日演练），向缓存集群随机注入节点宕机故障。前三次演练发现异常检测延迟高达 12 分钟，于是把缓存指标纳入 3σ 检测并调低 α 值；迭代三个月后，MTTD 降到 4 分钟，MTTR 从 45 分钟降到 18 分钟，韧性分稳定在 0.95 以上。

Python 演示

python96 行
import mathimport random  def calc_stats(values):    """计算均值与标准差, 相当于给指标建立正常体温区间"""    n = len(values)    mean = sum(values) / n    var = sum((v - mean) ** 2 for v in values) / n    std = math.sqrt(var)    return mean, std  def detect_anomalies(series, k=3.0):    """用前半段干净数据建基线, 在后半段找超出 k 个标准差的点(3σ 法则)"""    split = len(series) // 2    mean, std = calc_stats(series[:split])    hits = []    for i in range(split, len(series)):        z = abs(series[i] - mean) / std        if z > k:            hits.append((i, series[i], z))    return hits  def dedup_alerts(hits, window=3):    """滑动窗口去重: 窗口内的重复告警只保留第一条"""    out = []    until = -1    for idx, val, z in hits:        if idx <= until:            continue        out.append((idx, val, z))        until = idx + window    return out  def correlation(a, b):    """皮尔逊相关系数, 值越接近 1 表示两个指标同步性越强"""    n = len(a)    ma, sa = calc_stats(a)    mb, sb = calc_stats(b)    if sa == 0 or sb == 0:        return 0.0    cov = sum((a[i] - ma) * (b[i] - mb) for i in range(n)) / n    return cov / (sa * sb)  def rca_rank(metrics, root_candidate):    """计算其它服务与根因候选的相关系数, 按嫌疑度排序"""    root = metrics[root_candidate]    scores = {}    for name, series in metrics.items():        if name == root_candidate:            continue        scores[name] = correlation(root, series)    return sorted(scores.items(), key=lambda item: -item[1])  def main():    random.seed(42)  # 固定随机种子, 保证结果可复现    n = 60    t = list(range(n))     # 构建四个服务的分钟级指标, 含正常波动    api = [50 + 5 * math.sin(i * 0.2) + random.gauss(0, 2) for i in t]    pay = [50 + 4 * math.sin(i * 0.2) + random.gauss(0, 2) for i in t]    order = [p + 6 + random.gauss(0, 2) for p in pay]  # 订单依赖支付    inv = [40 + 3 * math.sin(i * 0.1) + random.gauss(0, 2) for i in t]     # 第 40 分钟起支付服务开始劣化 (真实故障注入)    for i in range(40, n):        pay[i] += 60     metrics = {"api-gateway": api, "order-svc": order,               "payment-svc": pay, "inventory-svc": inv}     print("=== 3sigma 异常检测(后半段) ===")    for name, series in metrics.items():        hits = detect_anomalies(series, k=3.0)        if hits:            print(name, "越界点数:", len(hits), "首个越界点:", hits[0])     print("\n=== 滑动窗口去重(窗口=3) ===")    for name, series in metrics.items():        hits = detect_anomalies(series, k=3.0)        clean = dedup_alerts(hits, window=3)        print(name, "原始", len(hits), "条 -> 去重后", len(clean), "条")     print("\n=== 根因关联分析(候选: payment-svc) ===")    for name, r in rca_rank(metrics, "payment-svc"):        print(name, "相关系数:", round(r, 3))  if __name__ == "__main__":    main()
目的：用 3σ 法则检测指标异常，用滑动窗口对重复告警去重，再用相关系数给根因分析提供嫌疑排序——完整跑通 AIOps 的“检测→降噪→定位”三段式流程。
  1. def calc_stats(values):计算均值和标准差，相当于建立“正常体温区间”。
  2. z = abs(series[i] - mean) / std把偏离量换成 z 分数，超过 k 就视为异常。
  3. if idx <= until: continue窗口内已报过警的点直接跳过，这就是告警去重。
  4. def correlation(a, b):计算两个指标的皮尔逊相关系数，越接近 1 嫌疑越大。
  5. pay[i] += 60模拟第 40 分钟起支付服务劣化，把“故障”注入数据。
  6. random.seed(42)固定随机种子，让每次运行结果一致，便于团队复盘。

常见误区

误区刚接触 3σ 时觉得 3 太大，把 k 改成 1，以为越敏感越好。结果告警刷屏，同事骂声一片，反而没人看了。

正解阈值本质是灵敏度与误报的平衡。k=1 时正常波动也会报警，十分钟后值班人员对告警彻底免疫，真正故障来了反而被忽略，这就是“告警疲劳”。3σ 基于正态分布约有 0.3% 的误报概率，是一个经验平衡点，具体取值要结合业务容忍度调整，而不是一味求严。

为何常见：直觉上“敏感=安全”，忽略了告警疲劳这个隐性成本——报警系统的信用一旦透支，再难修复。

误区每次收到告警都当 P0 故障处理，立刻建群拉人，结果半小时后发现只是监控探针抖动，白白消耗团队精力。

正解告警是“症状”不是“诊断”。一次告警可能是短暂抖动、网络尖峰，甚至监控自身的问题。正确做法是先看关联指标和调用链，用根因分析确认影响范围，再决定要不要升级处理。AIOps 的价值正是给告警附上“上下文”，帮值班人员快速判断真伪。

为何常见：传统监控只有孤立的阈值判断，缺少上下文信息，SRE 只能条件反射式响应。

误区以为写个移动平均就万事大吉，不用关心业务周期。结果周末低流量期间频繁误报，大促时又漏报。

正解动态基线的关键是“分得够细”：按服务、机房、时段分别建模，大促日单独一套基线，新版本上线后还要对数据漂移做自适应重算。EWMA 的 α 也要按数据特性调：指标越平稳，α 应越小；业务变化越快，α 应越大。

为何常见：滑动平均的代码最简单，容易误以为“基线的值在动”就是“动态基线”，忽略了分层和自适应的工程细节。

误区觉得混沌工程就是拿一把枪朝生产环境乱开，看哪个服务先倒下。结果有人直接在核心库执行了删除操作，酿成事故。

正解混沌工程是“假设驱动”的科学实验：先定义稳态指标（什么算正常），再设计受控的小范围故障注入，验证系统是否偏离稳态，最后复盘改进并沉淀应急预案。直接随机拔生产库属于灾难演习失控，不是工程。

为何常见：“混沌”一词容易让人误解为混乱，其实它的原意是在不可预测性中建立信心，每一步都要可控、可回滚。

误区看到两个指标相关系数 0.95，立刻断定 A 导致 B，结果把无辜的服务重启了一遍，真正的根因还在疯狂报错。

正解相关不等于因果。高相关可能来自共同的上游因素（比如都受流量暴涨影响），也可能只是巧合。根因分析必须结合拓扑图和调用链方向：谁调用谁、谁的下游先出问题，用方向性证据把“相关”升级为“因果”。

为何常见：相关系数计算简单、数字好看，容易让人忽略方向性证据——而方向恰恰是根因分析最值钱的部分。

面试题

Q1. AIOps 最核心的目标是什么？

单选题 · easy

  • A.用AI完全替代运维人工值班
  • B.自动发现异常并快速定位根因← 正确答案
  • C.让告警系统变得越简单越好
  • D.全自动化修复所有线上故障

答案：B。AIOps 的核心是“检测+定位”的智能辅助，让 SRE 从被动救火转向主动预防。完全替代人工（A）、一味简化系统（C）、全自动修复（D）都不现实，AI 的定位是增强人而非取代人。

Q2. 3σ 法则中，z=(x−μ)/σ 这个分数的含义是什么？

单选题 · mid

  • A.当前值距离均值有多少个标准差距← 正确答案
  • B.当前值与历史最大值之间的差值
  • C.当前指标相对昨日增长了多少倍
  • D.当前值与系统阈值的百分比大小

答案：A。z 分数把“偏离量 (x−μ)”除以“正常波动幅度 σ”，得到的是标准化的偏离程度，即“偏离了几个标准差”。它不是与最大值的差（B）、不是环比倍数（C），也与百分比阈值无关（D）。

Q3. 告警降噪最终要解决的问题是什么？

单选题 · mid

  • A.把告警全部删掉让系统安静下来
  • B.让值班人员少看到无效重复告警← 正确答案
  • C.提高告警发送速度减少网络延迟
  • D.让开发人员写更少的代码少出错

答案：B。降噪的目标是减少告警疲劳，把“重复的、衍生的、低优先级的”告警过滤掉，让值班者聚焦真正需要处理的根因告警。它不是删除全部告警（A），与发送速度（C）或代码量（D）无关。

Q4. 以下哪些属于异常检测的常用方法？

多选题 · mid

  • A.统计学方法如3σ阈值判断← 正确答案
  • B.机器学习模型的回归预测← 正确答案
  • C.固定人工经验拍脑袋设定
  • D.只看用户投诉数量变化

答案：AB。3σ 统计法和机器学习回归预测都是标准做法。人工拍脑袋（C）和只看投诉（D）都属于事后被动响应，不是主动检测的算法手段。

Q5. 动态基线相比固定阈值的主要优势是什么？

单选题 · mid

  • A.不需要任何历史数据即可运行
  • B.能跟随业务周期自动调整范围← 正确答案
  • C.可以省去监控系统的搭建成本
  • D.保证百分之百零误报零漏报

答案：B。动态基线让正常范围随流量、时段、业务周期流动，解决“白天正常晚上异常”这类固定阈值失灵问题。它必须依赖历史数据（A 错），也取代不了监控系统本身（C 错），更不可能零误报（D 错）。

Q6. 根因分析中可以使用的线索有哪些？

多选题 · mid

  • A.调用链追踪各服务耗时数据← 正确答案
  • B.服务拓扑图中的依赖关系← 正确答案
  • C.多个指标变化的相关系数← 正确答案
  • D.盲目重启所有服务直到故障消失

答案：ABC。调用链、拓扑图、相关系数是 RCA 的三大线索，分别提供“路径、关系、共变”证据。盲目重启（D）是碰运气的救火手段，不是分析推理方法。

Q7. MTTR 中的三个字母分别代表什么？

单选题 · easy

  • A.平均故障恢复时间这个指标← 正确答案
  • B.平均故障检测时间这个指标
  • C.平均无故障运行时间这个指标
  • D.每年系统计划停机时间的指标

答案：A。MTTR = Mean Time To Repair，平均故障恢复时间，衡量从故障发生到系统恢复的耗时。平均检测时间是 MTTD（B 错）；平均无故障运行时间是 MTBF（C 错）；计划停机与 MTTR 无关（D 错）。

Q8. 混沌工程实践的正确打开方式有哪些？

多选题 · hard

  • A.先提出关于系统韧性的明确假设← 正确答案
  • B.在可控范围内逐步引入真实故障← 正确答案
  • C.时刻验证系统稳态是否保持正常← 正确答案
  • D.直接在核心生产库执行随机删除

答案：ABC。混沌工程是假设驱动的科学实验：先定义稳态，再小范围注入故障，并持续验证。直接在生产库随机删除（D）是不可控的危险操作，违背了“受控、可回滚”的原则。

Q9. 告警去重中“滑动窗口”的作用是什么？

单选题 · easy

  • A.规定多长时间内重复告警归一条← 正确答案
  • B.让每条告警在页面停留更长时间
  • C.把历史告警自动转存到对象存储
  • D.定时清理告警系统产生的日志

答案：A。滑动窗口定义一个时间区间，窗口内同一指标的重复越界只保留第一条告警，等窗口滑过再计新告警。它不是延长展示（B）、存储归档（C）或日志清理（D）。

Q10. 两个指标相关系数高达 0.95，能据此得出什么结论？

单选题 · hard

  • A.两者一定存在直接的因果关系
  • B.两者线性相关但不一定是因果← 正确答案
  • C.两者没有任何统计上的相关性
  • D.两者必然来源于同一个数据库

答案：B。0.95 只说明高度线性相关，可能源于共同上游因素或巧合。要确认因果，必须结合拓扑方向与调用链的时序证据（谁先异常、谁调用谁）。直接断定因果（A）、否定相关（C）或断言同源（D）都站不住脚。