📚 课程目录第3章基于规则的静态降噪

3. 基于规则的静态降噪：阈值过滤、频率限制、黑名单/白名单机制

静态降噪，说白了就是给告警系统定死规矩。你想想看，运维告警里有多少是「CPU 使用率 80%」这种破事？其实很多问题根本不需要人看，规则就能挡掉。我刚开始做告警治理时，第一件事就是搭这套静态规则——它虽然笨，但胜在稳定、可解释。

3.1 阈值过滤：最基础的「一刀切」

阈值过滤是最直观的降噪手段。设定一个数值边界，超过就告警，没超过就闭嘴。但这里有个坑——阈值设得太低，告警轰炸；设得太高，漏报。

核心原则：阈值不是拍脑袋定的，得基于历史数据的 P95/P99 值来校准。

我在项目中遇到过一件事：某团队把磁盘使用率阈值设在 85%，结果每天半夜收到几百条告警。后来一查，他们的数据盘每天凌晨做全量备份，使用率会短暂冲到 90%。最后我们把阈值提到 95%，同时加了持续时间条件——持续 10 分钟以上才告警。嗯，这才是合理的做法。

阈值过滤的典型场景：

资源指标：CPU、内存、磁盘、带宽
业务指标：响应时间、错误率、吞吐量
日志指标：特定错误码出现次数

3.2 频率限制：别让同一个问题刷屏

频率限制解决的是「重复告警」问题。一个服务挂了，监控系统可能每分钟发一条告警，5 分钟就刷了 5 条。你想想看，这有什么意义？

我建议的做法是：同一个告警源、同一个告警类型，在单位时间内只发一条。比如 5 分钟内只发一次，后续的告警直接丢弃或聚合。

经验之谈：频率限制的时间窗口不要设得太短（比如 1 分钟），否则高峰期还是会被刷屏。我个人习惯用 5-15 分钟，具体看告警的紧急程度。

频率限制的常见策略：

策略	说明	适用场景
固定窗口	每 T 秒内只允许 1 条告警	通用场景，实现简单
滑动窗口	基于时间戳的滑动计数	需要精确控制频率的场景
令牌桶	允许突发，但限制平均速率	告警风暴时仍能保留关键告警

3.3 黑名单/白名单机制：精准放行或拦截

黑名单和白名单，说白了就是「谁可以发告警，谁不可以」。

黑名单：明确哪些告警不要。比如已知的运维操作窗口、计划内的变更、测试环境的告警。
白名单：只允许某些告警通过。比如只关注生产环境的 P0/P1 告警，其他全部丢弃。

我曾经踩过一个坑：把某个核心服务的告警加到了黑名单里，结果它挂了三天没人发现。后来我学乖了——黑名单一定要有有效期和审批流程，不能随便加。

警告：黑名单是双刃剑。用得好，减少噪音；用不好，就是事故的温床。每次加黑名单，必须写清楚原因、有效期、责任人。

3.4 规则引擎的设计与实现（Python 伪代码）

静态规则的核心是一个规则引擎。它接收告警事件，逐条匹配规则，决定是放行、丢弃还是降级。下面是我常用的一个简化版设计：

class Rule:
    def __init__(self, name, condition, action):
        self.name = name          # 规则名称
        self.condition = condition # 条件函数
        self.action = action      # 动作: 'pass', 'drop', 'degrade'

class RuleEngine:
    def __init__(self):
        self.rules = []

    def add_rule(self, rule):
        self.rules.append(rule)

    def evaluate(self, event):
        for rule in self.rules:
            if rule.condition(event):
                return rule.action
        return 'pass'  # 默认放行

# 示例：阈值过滤规则
def cpu_threshold_condition(event):
    return event['metric'] == 'cpu_usage' and event['value'] > 90

cpu_rule = Rule('cpu_high', cpu_threshold_condition, 'pass')

# 示例：频率限制规则
class RateLimitRule:
    def __init__(self, key_func, window_sec, max_count):
        self.key_func = key_func
        self.window_sec = window_sec
        self.max_count = max_count
        self.cache = {}

    def condition(self, event):
        key = self.key_func(event)
        now = time.time()
        if key not in self.cache:
            self.cache[key] = []
        self.cache[key] = [t for t in self.cache[key] if now - t < self.window_sec]
        if len(self.cache[key]) >= self.max_count:
            return True  # 触发频率限制
        self.cache[key].append(now)
        return False

# 示例：黑名单规则
def blacklist_condition(event):
    blacklist = ['test-service', 'dev-environment']
    return event['service'] in blacklist

blacklist_rule = Rule('blacklist', blacklist_condition, 'drop')

# 组装引擎
engine = RuleEngine()
engine.add_rule(blacklist_rule)
engine.add_rule(cpu_rule)
# 频率限制规则需要特殊处理，这里简化

这个设计虽然简单，但足够应对大部分静态降噪场景。实际生产环境中，我会把规则配置化，存在数据库或配置中心里，方便动态调整。

3.5 规则的局限性：硬编码与维护成本

静态规则最大的问题是什么？硬编码。你写死在代码里的阈值，过两个月可能就不适用了。业务在变，系统在变，规则也得跟着变。

我见过最夸张的一个案例：某公司的告警规则有 2000 多条，全是运维工程师一条条手写的。每次业务变更，就要改几十条规则。后来他们干脆放弃了维护——反正也管不过来。

静态规则的几个硬伤：

维护成本高：规则多了以后，改一条可能影响一片，没人敢动。
缺乏自适应性：业务高峰期的正常流量，可能被误判为异常。
规则冲突：黑名单和白名单同时命中时，谁优先级高？没有统一标准。
不可解释性差：告警被丢弃了，但没人知道为什么。

我的建议：静态规则适合做「第一道防线」，处理那些明确、稳定的场景。但别指望它解决所有问题。后面我们会讲到动态降噪和 AI 降噪，那才是真正能自适应变化的手段。

嗯，说到这里，我想起一个教训。有一次我把一个频率限制规则写死了——5 分钟内只允许 1 条告警。结果那天晚上服务真的挂了，但告警被限流了，只发了一条。值班同学没看到，第二天才发现。从那以后，我所有的频率限制规则都加了「升级机制」——如果同一个告警持续出现，频率限制会自动放宽，确保关键告警不会被永久丢弃。

3.6 本章小结：静态规则的核心逻辑

为了让你更直观地理解静态降噪的整体流程，我画了一张图：

这张图展示了静态降噪的完整链路：告警事件先经过规则引擎，依次匹配黑/白名单、阈值过滤、频率限制，最后输出决策结果。注意规则的优先级——黑名单最高，频率限制次之，阈值最低。没被任何规则匹配的告警，默认放行。

静态规则虽然简单，但它是告警治理的基石。没有这层过滤，后面的动态降噪和 AI 降噪都会面临巨大的数据压力。不过，你也看到了它的局限性——硬编码、维护成本高、缺乏自适应。所以，我的建议是：用静态规则解决 80% 的明确问题，剩下的 20% 交给更智能的手段。