设想你所在的小区有一个物业管理中心。墙上挂满各类传感器：烟雾探测器、水表、电表、门禁磁条。光有这些“眼睛”还不够，物业必须定下一套「报警规矩」：什么情况算异常？异常了先通知谁？哪些噪声可以不理？这套规矩，就是监控告警世界里的「告警规则」。它负责把冷冰冰的指标数字，翻译成一个个可执行的告警事件——如同把“室温 62 度”翻译成“3 号楼 203 疑似火情”。但凡事讲平衡：规矩太灵敏，天天误报，保安被累死；规矩太迟钝，真出事没人知道。一个成熟的自动监控系统，要像经验丰富的物业一样，懂得分级、抑制、找对人，让每一次响铃都有价值。

岗位关联

告警规则是 AI 系统可观测性的“神经末梢”。掌握它，你才能在设计监控体系时既不漏报故障、又不淹没于噪声，这是 AI 工程师走向生产环境必备的工程素养。

目录
  1. 可视化演示
  2. 告警规则基础
  3. 阈值告警
  4. 异常检测告警
  5. 组合条件告警
  6. 告警分级体系
  7. 告警抑制策略
  8. 值班路由机制
  9. 多级告警落地
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态展示阈值/异常检测/组合条件三类告警规则，指标流经阈值线时触发P0/P1/P2分级告警与抑制路由，切换规则类型观察检测差异。

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

告警规则基础

想象小区物业值班中心的墙上，挂满了传感器读数：烟雾浓度、水流速度、电压高低。光有这些“眼睛”还不够，物业必须立下规矩——什么情况算事儿、谁去处理、要不要通知业主。这套写在值班手册里的判断逻辑，就是告警规则的雏形。它把冷冰冰的数字翻译成“可以行动的指令”。

在 AI 系统中也是一样。Prometheus、云监控等工具持续采集 CPU、内存、QPS、延迟等指标，但没有人会 7×24 小时盯着曲线看。告警规则回答三个问题：这个指标重不重要（监控什么）、多严重才报警（触发条件）、报警后走什么流程（后续动作）。它把纷繁的指标流转化为一条条告警事件流，是自动化运维得以成立的前提。

告警规则的本质是“指标 → 判断 → 事件”的映射。设某时刻 t 的监控指标值为 m_t，规则函数为 R，则告警的产生可以写成：

就像物业把“室温超过 60 度”写成一条规矩，AI 系统的每条告警规则也是值班手册上的一条判断句。规则的好坏直接决定值班员的判断质量——定得太松，火灾没人发现；定得太紧，狼来了喊多了就没人信了。

At=R(mt)∈{0,1}A_t = R(m_t) \in \{0, 1\}
规则 R 吃进一个指标值，吐出一个 0 或 1：1 代表“该报警了”，0 代表“一切正常”。
  1. 监控指标 m_tt 时刻被观测到的数值，例如某台机器此刻的 CPU 使用率 75%。
    mtm_t
  2. 规则函数 R一段判断逻辑，输入一个指标值，输出“是否告警”的结论。
    R(mt)R(m_t)
  3. 告警事件 A_t输出结果为 1 时触发一次告警事件，0 时保持静默。
    At=1A_t = 1

阈值告警

最朴素的报警规矩是划一条线：“室温不许超过 60 度”。超了就响铃，没超就不管。这条线简单、直观、谁都能看懂，它就是阈值告警——监控告警里最基础也最常用的规则形式。

在系统中，阈值告警为指标设定上限或下限，比如 CPU 使用率超过 80% 触发告警、磁盘剩余空间低于 10% 触发告警。阈值告警还可以配置多个级别：70% 发提醒（warning），85% 发告警（critical），95% 发严重告警（fatal），像交通灯一样分层预警。其判断逻辑是一句简单的比较：

但业务往往有波峰波谷：白天 QPS 高、夜间低，大促时流量是平时的十倍。一条固定的线容易“白天误报、夜间漏报”。于是有了动态阈值——按时间段（工作日晚高峰）或业务量（当前 QPS 区间）自动调整基线，以及多级阈值——设多道线分级报警。阈值告警的进阶方向，是让那条线自己学会“看情况”。

At=I(mt≥T)={1mt≥T0mt<TA_t = \mathbb{I}(m_t \ge T) = \begin{cases} 1 & m_t \ge T \\ 0 & m_t < T \end{cases}
指示函数 𝕀（条件） 在条件为真时取值 1，否则取值 0。本质就是“达到阈值就报，没达到就不报”。
  1. 当前指标 m_tt 时刻的监控指标值，比如此刻的 CPU 使用率。
    mtm_t
  2. 预设阈值 T由运维人员根据历史经验和业务容忍度人工设定的临界值。
    TT
  3. 指示函数 𝕀括号内的条件成立时函数值为 1，不成立时为 0。
    I(⋅)\mathbb{I}(\cdot)
  4. 分情况结果达到或超过阈值输出 1 触发告警，低于阈值输出 0 保持正常。
    {1mt≥T0mt<T\begin{cases} 1 & m_t \ge T \\ 0 & m_t < T \end{cases}

异常检测告警

资深物业知道每户的用水习惯：张姨每天 0.3 吨，今天突然 3 吨，大概率水管爆了。绝对值 3 吨并不高，但对比她本人“反常即故障”——这就是异常检测告警的直觉：不看数字多大，只看偏离常态多远。

技术上有两条路线。统计方法假设指标服从一定分布，维护历史均值 μ 和标准差 σ，新数值偏离超过 3σ 即视为异常，这就是著名的“三西格玛”法则：

更高阶的做法引入机器学习：用 ARIMA、Prophet 等时序模型预测“下一时刻本应是多少”，实际值与预测值偏差过大就告警；或用孤立森林等无监督方法直接识别离群点。季节性因素也自动纳入考量——“中午流量高、凌晨流量低”是正常节律，异常检测模型会用历史同期数据做对比，不会把每天的午高峰当成故障。异常检测像熟悉每家生活习惯的老保安，不看绝对值，只看“你今天反常了没”。

zt=mt−μσ,At=I(∣zt∣>3)z_t = \frac{m_t - \mu}{\sigma}, \quad A_t = \mathbb{I}(|z_t| > 3)
标准分 z_t 表示当前值偏离均值多少个标准差。偏离超过 3 个标准差，意味着这个值出现的概率不足 0.3%，足够可疑。
  1. 历史均值 μ过去 N 个时间窗口内指标的平均水平，刻画“正常长什么样”。
    μ\mu
  2. 历史标准差 σ指标波动的典型幅度，σ 越大说明平时浮动越厉害。
    σ\sigma
  3. 标准分 z_t当前值偏离均值的距离，以 σ 为单位度量，消除量纲差异。
    zt=mt−μσz_t = \frac{m_t - \mu}{\sigma}
  4. 异常判定z_t 的绝对值超过 3，表示偏离超过 3σ，触发告警。
    I(∣zt∣>3)\mathbb{I}(|z_t| > 3)

组合条件告警

物业不会因为一户冒点烟就打消防电话——万一是炒菜呢？规矩改为：“冒烟 + 温度超 60 度 + 持续 5 分钟”三条同时满足才上报消防。这就是组合条件告警：用多个证据交叉验证，降低误报。

在系统中，组合条件用 AND/OR 逻辑把多个指标的判断联接起来，并加入时间窗口。AND 表示“所有条件都满足才告警”，适合降低误报；OR 表示“任一条件满足就告警”，适合覆盖多重故障模式。时间窗口要求异常状态持续至少 D 秒，自动过滤瞬时毛刺：

组合条件的降噪效果显著。“请求量暴涨”可能是活动正常引流，“延迟上升”可能是网络抖动，但“请求量暴涨 + 延迟上升 + 持续 5 分钟”同时出现，基本可以断定后端真的出问题了。就像侦探办案不凭单一线索抓人，组合条件让告警从“可能有事”进化到“确实有事”。

At=I(m1>T1)∧I(m2>T2)∧I(d≥D)A_t = \mathbb{I}(m_1 > T_1) \wedge \mathbb{I}(m_2 > T_2) \wedge \mathbb{I}(d \ge D)
d 是异常持续时长，D 是预设窗口。三个条件用 ∧（与）连接，缺一个都不触发。
  1. 指标 m_1、m_2两个不同的监控指标，如请求量和错误率。
    m1,m2m_1, m_2
  2. 各自阈值 T_1、T_2每个指标独立的触发临界值。
    T1,T2T_1, T_2
  3. 与运算 ∧所有比较条件同时为真时，整体才为真。
    x∧yx \wedge y
  4. 持续时长 d 与窗口 D异常需要维持至少 D 秒，d ≥ D 才算成立。
    d≥Dd \ge D

告警分级体系

灯泡坏了和着火了显然不是一个打法。物业把问题分四级：P1 火灾爆炸级别，电话轰炸、全员出动、消防联动；P4 楼道路灯不亮，记在小本子上顺手修。分级，是为了让人的注意力花在刀刃上。

业界通用 P1 到 P4 四级体系。P1 核心服务不可用，5-10 分钟内必须有人响应并接手；P2 主要功能受损，30 分钟内响应；P3 一般问题当天处理；P4 低优先级任务进入排期。分级不应全凭人工判断，可用严重度评分模型自动计算：

分级还可以动态调整：一条 P2 告警半小时没人处理完，自动升级为 P1；服务恢复后自动降级关闭。分级的本质是“正确地着急”——像医院分诊台一样，先救重症患者，轻症排队慢慢看，避免所有人的手机同时被无关紧要的噪声震响。

S=w1I1+w2I2+w3I3S = w_1 I_1 + w_2 I_2 + w_3 I_3
严重度 S 是影响范围、服务重要性、持续时长三维评分的加权和，S 落在哪个区间就对应哪个级别。
  1. 影响范围 I_1受影响的用户或服务比例，如“影响 30% 用户”得 3 分。
    I1I_1
  2. 服务重要性 I_2该服务在业务体系中的关键程度，核心支付链路得分高。
    I2I_2
  3. 持续时长 I_3异常已经持续的时间，拖得越久越严重。
    I3I_3
  4. 权重 w_j三个维度的加权系数，体现团队对不同因素的重视程度。
    w1,w2,w3w_1, w_2, w_3

告警抑制策略

整栋楼 30 户同时报“冒烟”，物业会合并成一条“3 号楼疑似火灾”，而不是打 30 个电话轰炸值班经理。同一扇门磁一小时反复报警，也只需记录一次。这就是告警抑制——给告警装上“话务员”，把几十通重复来电合并成一单工单。

告警抑制有三个关键手段。去重：相同规则 + 相同对象的告警在窗口期内只发一次，状态重置后才允许再次触发。聚合：把同一时间窗内、同一主机或应用的多条告警合并为一条总告警，如“ECS-01 上 12 条告警”。静默：在发布窗口、演练期间挂起指定规则，避免已知操作触发的假警报刷屏。抑制是否生效的判断：

告警抑制不是掩盖问题，而是“合并同类项”。告警风暴——一个故障触发几百条刷屏——是最常见的监控事故。抑制策略把风暴降为几条可读的信息，保住值班人员对告警的敏感性。就像话务员不会让同一个问题轰炸经理二十遍，而是汇总成“这个问题有 20 户报修，都在 3 号楼”。

Isup=I(tnow−tlast<Tsup)I_{sup} = \mathbb{I}(t_{now} - t_{last} < T_{sup})
距上次同类告警不足 T_sup 秒时，抑制标志位为 1，本次告警被吞掉，不重复打扰。
  1. 当前时刻 t_now此刻的系统时间。
    tnowt_{now}
  2. 上次告警 t_last同一条规则上一次真正发出告警的时刻。
    tlastt_{last}
  3. 抑制窗口 T_sup两次同类告警之间的最短间隔，如 300 秒。
    TsupT_{sup}
  4. 抑制判定间隔小于窗口则抑制（不发出），否则正常发出。
    tnow−tlast<Tsupt_{now} - t_{last} < T_{sup}

值班路由机制

告警分级后要送对人：楼道路灯坏了发给保洁班组微信；水管爆裂直接打电话给物业经理，5 分钟没接自动升级给业委会和开发商。这就是值班路由——解决“告警发给谁、怎么发、没人管怎么办”。

路由机制包含三部分。通知策略：按级别选择渠道——P1 电话加短信双重轰炸，P2 电话，P3 发到 IM 值班群，P4 进工单系统。升级机制：告警发出后 N 分钟无人确认，自动升级到上一级负责人，直至有人接单。排班调度：按值班表把告警路由给当前的 on-call 人员，轮换值守避免永远骚扰同一个人。升级与否的判断：

路由机制让告警形成闭环：发出 → 确认 → 处理 → 关闭，每一环都有人盯。物业的“传话链”也是如此——一级管一级，绝不让重要消息烂在某一个人手里。哪怕最强壮的值班员也有洗澡、睡觉的时刻，机制的力量在于永不遗忘。

Lnext={Lcurtack≤TackLcur+1tack>TackL_{next} = \begin{cases} L_{cur} & t_{ack} \le T_{ack} \\ L_{cur} + 1 & t_{ack} > T_{ack} \end{cases}
t_ack 是告警确认耗时。若在时限 T_ack 内无人确认，告警级别向上升一级，交由更高层级的负责人处理。
  1. 当前层级 L_cur例如第 1 层是值班工程师，第 2 层是团队 leader。
    LcurL_{cur}
  2. 确认耗时 t_ack从告警发出到有人点击“确认接手”所经过的时间。
    tackt_{ack}
  3. 确认时限 T_ack团队约定的响应 SLA，如 10 分钟。
    TackT_{ack}
  4. 升级动作超过时限未确认，则告警上升到更高层级发起处理。
    Lcur+1L_{cur} + 1

多级告警落地

光有规矩不够，物业每季度还要复盘：哪些报警是误报？哪次漏水没发现？误报多的规矩要改，漏报的要补。这就是多级告警体系的“复盘会”——把阈值、异常检测、分级、抑制、路由组合成一套系统，再持续校准。

落地的第一步是体系设计：分层规则架构（基础设施层用阈值、应用层用组合条件、业务层用异常检测）+ 分级体系 + 抑制策略 + 值班路由，组合成完整的多级拦截网。第二步是效果评估，用告警质量指标衡量这套网织得好不好：

评估之后是持续调优：提高阈值降误报、缩小抑制窗口增灵敏度、调整升级时限提响应效率。告警规则不是写一次就完事的静态配置，而是随业务演化不断校准的活系统。就像物业的 PDCA 复盘会——定规矩、执行、发现问题、改规矩——循环往复，报警系统才会越来越聪明，把值班员的精力留给真正的大事。

F1=2×P×RP+R,P=TPTP+FP,R=TPTP+FNF1 = \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确实发生了故障，系统也正确地报了警。
    TPTP
  2. 误报 FP实际没故障，系统却报了警，是噪声的来源。
    FPFP
  3. 漏报 FN故障真实发生了，系统却没有察觉，是最危险的情况。
    FNFN
  4. 精确率 P报出的告警中真实故障所占的比例，衡量“报得准不准”。
    P=TPTP+FPP = \frac{TP}{TP+FP}
  5. 召回率 R真实故障中被成功捕获的比例，衡量“报得全不全”。
    R=TPTP+FNR = \frac{TP}{TP+FN}
  6. F1 综合分精确率与召回率的调和平均，惩罚两者中的短板。
    F1=2×P×RP+RF1 = \frac{2 \times P \times R}{P + R}

AI 应用场景

AIOps 智能运维平台

阶段：应用部署与监控

解决的问题：传统固定阈值规则在业务波动面前误报率高，SRE 团队被告警噪声淹没，真正的故障反而被忽略。

具体案例：某头部电商在大促期间使用 AIOps 平台，将动态基线与组合条件告警结合——“订单量涨 300% 但支付成功率下降”这类复合异常被精准识别，P1 告警从每天 200 条降至 15 条，值班工程师终于能从“灭火”中腾出手来做真正的架构优化。

云厂商托管监控服务

阶段：模型部署与运维

解决的问题：企业自建告警系统需要大量人力维护阈值和值班表，中小团队难以承受。

具体案例：阿里云 ARMS、AWS CloudWatch 等托管服务内置完整的告警规则体系：P1-P4 分级、告警静默（发布窗口自动挂起）、值班轮转与升级策略开箱即用。某创业公司接入后，把原本需要 2 个专职运维的告警管理工作压缩为每周半小时的规则 review。

大模型服务监控

阶段：线上服务运营

解决的问题：LLM 服务的延迟、Token 消耗、安全合规等指标波动剧烈，传统阈值无法适配。

具体案例：某 AIGC 应用监控 prompt 成功率，用异常检测 + 组合条件识别“上下文长度突增 + 响应延迟飙升”的复合故障，并在值班路由中配置了三级升级链路：聊天机器人 → 算法工程师 → CTO 值班室，确保核心 API 故障在 5 分钟内有人响应。

Python 演示

python86 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-"""简易告警规则引擎：阈值告警 + 组合条件 + 告警抑制"""import mathimport time  class AlertRule:    """单条告警规则定义"""     def __init__(self, name, metric, threshold, window=0,                 min_severity="warning", suppress_seconds=300):        self.name = name        self.metric = metric        self.threshold = threshold        self.window = window        # 持续窗口（秒），0 表示立即触发        self.min_severity = min_severity        self.suppress_seconds = suppress_seconds        self.last_alert_time = 0.0        self.active = False        self.active_start = 0.0     def evaluate(self, value, now=None):        """评估当前值是否触发告警，返回 True/False"""        now = now or time.time()        if value <= self.threshold:            self.active = False            return False        if not self.active:            self.active = True            self.active_start = now        if now - self.active_start < self.window:            return False        if now - self.last_alert_time < self.suppress_seconds:            return False        self.last_alert_time = now        return True  class AlertManager:    """告警管理器：管理多条规则并统一输出"""     def __init__(self):        self.rules = []        self.alert_log = []     def add_rule(self, rule):        self.rules.append(rule)     def process_metric(self, metric, value):        """处理一条新指标数据，返回本次新触发的告警列表"""        alerts = []        for rule in self.rules:            if rule.metric != metric:                continue            if rule.evaluate(value):                alerts.append({"rule": rule.name, "metric": metric,                               "value": value, "severity": rule.min_severity})        if alerts:            self.alert_log.append((time.time(), alerts))        return alerts  def main():    manager = AlertManager()    rule_cpu = AlertRule("cpu_high", "cpu_usage", threshold=80,                         window=10, suppress_seconds=60)    rule_mem = AlertRule("mem_high", "mem_usage", threshold=85,                         window=5, suppress_seconds=120)    manager.add_rule(rule_cpu)    manager.add_rule(rule_mem)     print("时间(s)  cpu%   mem%   触发告警")    for sec in range(120):        cpu = 70 + 15 * math.sin(sec * 0.2) + (5 if sec % 30 > 25 else 0)        mem = 75 + 10 * math.sin(sec * 0.1) + (8 if 40 < sec < 55 else 0)        alerts = manager.process_metric("cpu_usage", cpu)        alerts += manager.process_metric("mem_usage", mem)        if alerts:            names = ", ".join(a["rule"] for a in alerts)            print(f"{sec:8d}  {cpu:4.1f} {mem:4.1f}   {names}")        time.sleep(0.01)  # 加速演示  if __name__ == "__main__":    main()
目的：演示一个极简告警规则引擎。AlertRule 实现了“阈值 + 持续窗口 + 抑制窗口”三种逻辑，AlertManager 统一处理多条规则，模拟 120 秒的 CPU/内存指标并输出触发的告警。你可以调整 window 和 suppress_seconds 观察告警频率的变化。
  1. class AlertRule:定义一条告警规则，类比物业值班手册上的一条“报警规矩”。
  2. self.window = window异常需持续多少秒才触发，实现组合条件中的时间窗口。
  3. self.suppress_seconds = suppress_seconds抑制窗口，防止同类告警短时间反复轰炸。
  4. def evaluate(self, value, now=None):核心方法：判断某个指标值是否触发告警。
  5. if value <= self.threshold:阈值判定的第一道关卡，未超线立即复位正常状态。
  6. if now - self.active_start < self.window:超线但还没熬过持续窗口，先不报。
  7. if now - self.last_alert_time < self.suppress_seconds:距上次告警太近，被抑制吞掉。
  8. class AlertManager:告警管理器，负责维护规则集合并分发指标数据。
  9. def process_metric(self, metric, value):把一条新指标数据送给所有匹配的规则评估。
  10. alerts += manager.process_metric("mem_usage", mem)同一时刻处理多类指标，模拟组合监控场景。

常见误区

误区“系统很稳，阈值调高一点，报警少一点，省心！”于是把 CPU 告警线从 80% 调到 95%，确实清净了，直到某次数据库 CPU 持续 98% 半小时没人发现。

正解阈值的高与低本质是灵敏度与噪声的权衡。把火灾报警温度设在 200 度，等真到 200 度时楼已经烧没了。阈值应基于业务容忍度设定，宁可多几条可过滤的噪声，也不要漏掉一次 P1 级故障。

为何常见：人对频繁被打扰的厌恶远超对潜在风险的担忧。误报是“看得见的浪费”，漏报是“看不见的风险”，所以下意识会往高调。

误区“每个指标都配十条规则，覆盖所有场景，肯定稳！”结果几百条规则互相重叠，故障一来同时触发 200 条告警，形成告警风暴。

正解规则数量的增长会带来维护成本和噪声水平的指数上升。业界实践是“少而准”——用组合条件把噪声降下来，用异常检测补盲区，定期 review 删除无效规则。物业把所有传感器都设成 40 度报警，一天响 800 次，保安只会把铃铛摘了。

为何常见：覆盖焦虑。怕漏掉某个场景而过度配置，忽略了每条规则都有误报成本和维护成本。

误区“出问题是大事，必须让所有人知道！”于是 P4 的磁盘清理提醒也要电话+短信轰炸全组，结果真正 P1 故障的电话没人接了——大家都被吵麻了。

正解无差别通知会把重大告警淹没在无关消息里。P1 电话、P2 电话、P3 群消息、P4 工单，这才是合理的分级路由。火灾时给每户都打电话会被当成骚扰，物业广播 + 对应楼层值班员才是有效路径。

为何常见：把“通知”等同于“响应”，忽视了人的注意力是有限资源——一次性喊所有人，等于没有重点。

误区“上了 AI 异常检测，传统阈值规则可以全删了，让模型自己学。”结果内存泄漏这种缓慢爬升型故障，异常检测经常当作“新常态”放行。

正解异常检测擅长发现“模式突变”，但对缓慢漂移不敏感，冷启动时还需要历史数据训练。阈值规则简单、可解释、零成本，二者是互补关系。老保安看“反常”靠经验，但温度计上“超过 60 度”这种硬指标也绝不能丢。

为何常见：对 AI 能力过度信任，忘了任何检测器都有盲区。越智能的方案越需要兜底规则。

误区“发布时设了静默窗口，万一发布出问题不就没人知道了？”

正解静默只掩盖“已预期会发生的噪声”——比如发布重启时连接中断、内存飙升这些已知操作附带的现象。真实的可用性告警（如健康检查失败）不应被静默，且静默窗口有明确的结束时间，到期自动恢复监控。装修期间邻居报的“噪音”不用逐条回应，但真着火了警报还是要响。

为何常见：把“抑制/静默”误解为永久关闭监控，而非“在特定时段有策略地过滤可预期噪声”。

面试题

Q1. 阈值告警的核心判断逻辑是？

单选题 · easy

  • A.指标值超过预设阈值即触发← 正确答案
  • B.指标值等于预设阈值才触发
  • C.指标值低于预设阈值即触发
  • D.指标值任意变化都触发

答案：A。阈值告警的本质是“越线即报警”。超过阈值触发，低于阈值是正常状态。“等于才触发”在连续指标上几乎没有实操意义，“低于触发”只对下限类规则成立，“任意变化都触发”等于没有规则。

Q2. “均值 ± 3σ” 告警属于哪类方法？

单选题 · easy

  • A.静态阈值告警
  • B.异常检测告警← 正确答案
  • C.组合条件告警
  • D.人工审核告警

答案：B。3σ 法则通过历史均值 μ 和标准差 σ 判断新值是否偏离常态，属于统计异常检测。阈值告警用固定线，组合条件用多条件逻辑，均与“偏离常态”无关。

Q3. 以下哪些属于告警抑制策略？

多选题 · mid

  • A.告警去重← 正确答案
  • B.告警聚合← 正确答案
  • C.静默时段← 正确答案
  • D.通知升级

答案：ABC。去重（同类告警只发一次）、聚合（多条合并一条）、静默（维护窗口挂起）都是抑制策略，目的是减少噪声。通知升级属于值班路由机制，是告警发出后的递送手段，不是抑制手段。

Q4. P1 级告警通常要求响应时间是？

单选题 · mid

  • A.24 小时内响应
  • B.10 分钟内响应← 正确答案
  • C.1 周内响应
  • D.无需任何响应

答案：B。P1 是最高级别（核心服务不可用），SLA 一般是 5-10 分钟内确认接手。24 小时对应 P3，1 周对应 P4，无需响应不符合分级体系的意义——P1 存在的价值就是让人立刻动起来。

Q5. 组合条件告警中，AND 逻辑的作用是？

单选题 · mid

  • A.降低误报率← 正确答案
  • B.提高误报率
  • C.增加告警噪声
  • D.缩短检测时间

答案：A。AND 要求多个条件同时成立，单一指标的偶发抖动无法通过全部门槛，从而过滤掉大量误报。相当于物业坚持“冒烟 + 高温 + 持续”才报火警，误报率自然下降。

Q6. 动态阈值相比静态阈值的优势有哪些？

多选题 · hard

  • A.自动适应业务波动← 正确答案
  • B.减少人工调参成本← 正确答案
  • C.完全避免误报
  • D.无需设置任何参数

答案：AB。动态阈值按时间段或业务量自动调整基线，适配大促、深夜等场景，同时减少人工调参频率。但“完全避免误报”过于绝对，任何检测器都有误差；动态阈值也需要配置置信度、窗口等参数，并非零配置。

Q7. 告警质量评估指标 F1 值是？

单选题 · hard

  • A.准确率和召回率的调和平均← 正确答案
  • B.准确率和召回率的算术平均
  • C.精确率和召回率的乘积结果
  • D.召回率直接取倒数计算

答案：A。F1 = 2PR/(P+R)，是精确率和召回率的调和平均。调和平均对两者中的短板更敏感，防止系统“报得很准但漏报严重”或“报得很全但误报满天飞”。算术平均会被高分项拉平均值，乘积则量纲变了。

Q8. 告警升级机制的典型触发条件是？

单选题 · hard

  • A.告警长时间未确认← 正确答案
  • B.告警级别设置太低
  • C.值班人员主动发起
  • D.系统发生重启事件

答案：A。升级机制的核心是“超时未确认自动升一级”——告警发出后在 T_ack 时限内没人点确认，就升级给更高层级。级别太低不会触发升级，主动发起不叫机制，系统重启更与升级无关。

Q9. 告警值班路由机制包含哪些部分？

多选题 · mid

  • A.通知策略← 正确答案
  • B.升级机制← 正确答案
  • C.排班调度← 正确答案
  • D.指标采集

答案：ABC。通知策略决定“怎么发”（电话、短信、群消息），升级机制决定“没人管怎么办”，排班调度决定“发给谁”。指标采集是监控数据的源头，属于告警规则基础的范畴，不属于路由机制。

Q10. “灵敏度与噪声的平衡”是指？

单选题 · easy

  • A.灵敏度越高误报越少
  • B.灵敏度越高噪声越多← 正确答案
  • C.灵敏度与噪声毫无关系
  • D.灵敏度越低噪声不会变

答案：B。灵敏度越高（阈值越低），触发条件越容易满足，伴随的误报噪声也越多。这是监控告警中最核心的权衡：想让系统更敏锐地发现问题，就要接受更多的噪声；想清净，就可能漏报。两者此消彼长。