5.4 值班室：监控、维护与迭代

5.4 值班室：监控、维护与迭代

本节摘要：调度中心长期运行靠值班室看住三类信号——成功率与延迟、清洗各层损耗率、内容指纹漂移。本节给出三信号的实现与告警分级 SOP，以及站点改版后的标准响应流程，把"静默失败"变成"十分钟内感知"。

看板三信号

采集系统最阴险的故障不是崩溃——崩溃会报警——而是静默失败：任务正常返回 200、字段照常有值、数据悄悄错了。三个来源：站点改版后抽取 schema 抓到错误位置、蜜罐式假数据（2.4 节）、数据源内容分布漂移。值班看板的三信号就是为它们设的岗。

信号一：成功率与延迟。 最基础的脉搏。按任务与按站点两个维度统计：成功率跌破阈值（如 95%）、P95 延迟超基线两倍，都该出现在告警里。它的盲区是"成功但错误"，于是需要信号二和三。

信号二：清洗各层损耗率。 3.3 节要求每层损耗进看板，在这里兑现价值：字符层损耗从 1% 涨到 5%，几乎必然是上游编码或页面异常；语义层损耗腰斩，可能是过滤规则误杀。损耗率的基线波动很窄，是最灵敏的哨兵。

信号三：内容指纹漂移。 2.3 节留过伏笔：raw 与 fit 两版 Markdown 的比值、字段非空率的移动平均、平均正文长度的周同比——这些"内容形状"指标的突变，是改版与假数据的共同信号。

from dataclasses import dataclass, field
from collections import deque
import statistics

@dataclass
class WatchBoard:
    """值班看板：三信号采集与基线判定"""
    loss_history: dict = field(default_factory=lambda: {
        "char": deque(maxlen=200), "struct": deque(maxlen=200), "semantic": deque(maxlen=200)})
    baselines: dict = field(default_factory=lambda: {
        "char": 0.01, "struct": 0.03, "semantic": 0.10})   # 由前两周数据标定
    fit_ratio_history: deque = field(default_factory=lambda: deque(maxlen=200))
    fit_ratio_baseline: float = 0.34                        # 2.3节的净化压缩比基线

    def record(self, char_loss: float, struct_loss: float, semantic_loss: float,
               fit_ratio: float) -> list[str]:
        alerts = []
        self.loss_history["char"].append(char_loss)
        self.loss_history["struct"].append(struct_loss)
        self.loss_history["semantic"].append(semantic_loss)
        self.fit_ratio_history.append(fit_ratio)
        for layer, val in [("char", char_loss), ("struct", struct_loss),
                           ("semantic", semantic_loss)]:
            if val > self.baselines[layer] * 2:
                alerts.append(f"P2 {layer}损耗 {val:.0%} 超基线两倍")
        if abs(fit_ratio - self.fit_ratio_baseline) > 0.08:
            alerts.append(f"P1 内容形状漂移：净化比 {fit_ratio:.2f} 偏离基线")
        return alerts

board = WatchBoard()
print(board.record(0.011, 0.032, 0.09, 0.35))   # 输出：[]（一切正常，无告警）
print(board.record(0.052, 0.031, 0.09, 0.34))   # 输出：['P2 char损耗 5% 超基线两倍']
print(board.record(0.012, 0.03, 0.10, 0.19))   # 输出：['P1 内容形状漂移：净化比 0.19 偏离基线']
​

三条示例告警的处置方向完全不同：char 损耗超标查上游编码与异常页；净化比骤降（0.34 到 0.19）意味着页面结构变了——要么改版要么渲染不完整，按 P1 立即处理。

告警分级与值班 SOP

告警不分级，值班就会被狼来了磨麻木。三级够用：P1 数据正确性受损（指纹漂移、字段完整率崩塌、假数据嫌疑）——三十分钟内响应，暂停受影响任务，防止错误数据入库污染版本；P2 效率与风险信号（损耗异常、延迟翻倍、频控信号增多）——当天处理；P3 容量与趋势（磁盘水位、慢速增长）——周会处理。每级配一张动作卡，值班的新人按卡执行：

def dispatch_alert(level: str, signal: str) -> dict:
    """告警分级派单：动作卡而非自由发挥"""
    cards = {
        "P1": {"响应时限": "30分钟",
               "动作": ["暂停受影响任务", "抽样20页人工核对", "定位改版或假数据",
                        "修复并小批量验证", "恢复任务并记录事故"]},
        "P2": {"响应时限": "当天",
               "动作": ["检查上游页面样本", "核对清洗规则版本", "调整参数复跑观察"]},
        "P3": {"响应时限": "本周",
               "动作": ["趋势外推评估", "列入维护清单"]},
    }
    return cards.get(level, cards["P3"])

print(dispatch_alert("P1", "净化比漂移")["动作"][0])
# 输出：暂停受影响任务
​

改版响应：最常见的 P1 实战

站点改版是采集系统的宿命，标准流程把它变成例行公事。第一步确认：对比 raw 层改版前后的 HTML 快照（3.4 节的只进不改在这里救命），定位变化的是类名、结构还是渲染方式。第二步修复：改 schema 的选择器或 wait_for 的等待条件，修复版本号加一（3.4 节的 clean_rules 血缘同步更新）。第三步验证：小批量抓五十页，对照备料单字段完整率与净化比回到基线。第四步恢复：全量任务重启，事故记录归档——记录里写清"发现时间、受影响数据范围、修复版本"，这段记录就是半年后复盘时最值钱的材料。

维护的另一条线是数据漂移的周期巡检：每月对 curated 层做一次分布检查（3.1 节的切片对齐方法重跑一遍），训练侧的同事会在模型效果回退时来问"数据是不是变了"，这份巡检报告就是回答。

常见坑：告警阈值定得太敏感，P2 每天十条。两周后值班员把告警邮件过滤进垃圾箱，真 P1 来时无人响应。宁可阈值宽松漏掉几次 P3，不能让值班疲劳击穿 P1 的响应。

关键直觉：值班看板的设计目标不是"零故障"，是缩短故障的数据暴露窗口。改版事故平均暴露两天与两小时，对下游数据资产的影响差着一个量级——前者意味着污染数据进了两个版本，后者只是延迟了两小时。