智能巡检
用一条条配置好的业务规则,周期性扫描业务数据,命中阈值就主动告警,给出可落地的处置建议,并跟进到闭环。
本技能自包含:不依赖任何外部插件、脚本或数据库连接。只需要拿到巡检对象、可用数据与业务口径,就能跑完整条链路。全程只读取数,不对生产数据做任何写操作。
何时用 / 何时不用
何时用
| 触发场景 | 用户可能的说法 |
|---|---|
| 周期巡检业务数据 | 「帮我巡检一下有没有异常」「周期性检查业务数据」 |
| 库存类预警 | 「有哪些库存预警」「哪些物料快断货了」 |
| 订单异常 | 「有没有超时未发货的订单」「异常订单排查」 |
| 账款超期 | 「设置一个超期提醒」「哪些客户回款超期了」 |
| 指标异常波动 | 「这周销量为什么突然掉了」「指标波动检测」 |
| 数据质量缺失 | 「哪些单据关键字段是空的」「数据缺失检查」 |
| 规则配置与治理 | 「把这条巡检规则写出来」「这个告警太吵了,加个静默」 |
| 告警跟进与复盘 | 「这些告警处理得怎么样了」「帮我出一份巡检报告」 |
何时不用
| 不适用的情况 | 建议做法 |
|---|---|
| 只做一次性取数,不需要阈值判断与告警 | 直接查数即可;巡检的价值在于规则可周期性复用 |
| 只要一份分析报告,不涉及异常命中与处置 | 走报告类做法;本技能的产出物是告警单与闭环台账 |
| 要求秒级实时监测,或要求直连生产库写回数据 | 本技能是周期性批式巡检 + 只读取数,实时流与写操作不在范围内 |
| 数据来源与口径都拿不到 | 先解决数据可得性,不要用假设数据造出告警单 |
| 用户只想「被提醒一下」,没有任何可执行动作 | 可以只出告警单,但必须说明为什么没有处置建议 |
执行流程(分步,带确认门)
> 全局原则:每步先问清再动手。信息不足就停下来问用户,不要编造指标、阈值、对象或数字。
第 0 步 · 对齐巡检目标与数据来源
| 项 | 内容 |
|---|---|
| 输入 | 用户的巡检诉求、可用的数据来源 |
| 动作 | 确认巡检对象、数据从哪来、数据时间范围与时区、数据里能唯一定位「对象」的字段 |
| 产出 | 一段「巡检范围说明」:盯什么对象、用什么数据、覆盖哪段时间、多久巡检一次 |
| 判据 | 对象、数据、时间范围三者都明确;任一缺失就回到用户确认,不进入下一步 |
信息不足时逐条问,不要一口气问十个问题:
- 这次要巡检的对象具体是什么?
- 数据从哪里来,能否给出明细或汇总数据?
- 数据覆盖的时间范围是什么?
- 多久巡检一次,还是这次只做一次?
- 命中异常之后,由谁负责处理?
确认门 0:把「巡检范围说明」复述给用户,确认后才继续。
第 1 步 · 建立巡检规则
| 项 | 内容 |
|---|---|
| 输入 | 巡检范围说明 + 用户的业务经验(安全线、容忍度、历史常识) |
| 动作 | 为每个监测对象写一条规则,每条规则必须补齐五要素:监测指标、判定条件、阈值、巡检周期、生效范围 |
| 产出 | 「巡检规则清单」(可复制成表格),每条规则含规则 ID、五要素、默认等级、去重窗口 |
| 判据 | 任一条规则缺五要素中的一项,或阈值来源说不清,就不算完成 |
规则写法与阈值定法见 references/rule-design.md。要点:
- 阈值优先取历史分位(如近 90 天 P95)或业务安全线(如安全库存天数),再用同期对比做校正。
- 阈值必须在规则里写清「从哪来」,禁止凭感觉拍一个数。
- 用户说不清阈值时,先给一个基于历史数据的候选值,并标注「候选,需业务确认」。
确认门 1:把「巡检规则清单」给用户过一遍。用户逐条确认或修改后,规则才生效;未确认的规则标为「草稿」,不参与巡检。
第 2 步 · 周期性取数与比对
| 项 | 内容 |
|---|---|
| 输入 | 生效的规则清单 + 可用数据 |
| 动作 | 按规则的周期取数,按生效范围筛选,按监测指标口径计算实际值,与阈值逐条比对 |
| 产出 | 「取数比对记录」:规则 ID、对象、实际值、阈值、是否命中、计算口径备注 |
| 判据 | 每个规则、每个生效对象都有一条比对记录;口径与规则定义一致,不得临时改口径 |
硬性要求:
- 数值必须来自真实数据。数据缺失、字段为空、口径不明时,标记为「数据不足」而不是当成「未命中」。
- 一条规则在某个对象上数据不足,要在报告里单列,不能静默跳过。
- 取数时间点要记录,便于下一期对比与复现。
第 3 步 · 命中判断与去重
| 项 | 内容 |
|---|---|
| 输入 | 取数比对记录 |
| 动作 | 先判定命中,再按去重窗口抑制重复告警,最后叠加静默与升级策略 |
| 产出 | 本期「待发告警清单」 |
| 判据 | 同一对象的同一异常,在去重窗口期内只出现一条告警;被静默抑制的告警必须留下抑制记录 |
去重与静默规则:
| 机制 | 规则 |
|---|---|
| 去重键 | 对象 ID + 规则 ID + 异常类型 |
| 去重窗口 | 默认 1 个巡检周期;同一键在窗口期内已告警则不再重复告警 |
| 状态变化 | 窗口期内偏差显著变大或等级升高时,不受去重抑制,按「升级」再发一次 |
| 静默 | 计划内低峰期、盘点期、维护窗口、已确认的已知例外,可配静默;静默必须写明起止时间与原因 |
| 升级 | 高等级告警在约定时长内未被认领,升级给上一级负责人并记录升级动作 |
第 4 步 · 分级(高、中、低)
| 等级 | 判定参考 | 期望响应 |
|---|---|---|
| 高 | 直接影响客户交付、资金回收或安全生产;偏差幅度大且仍在恶化;影响多个对象 | 当天认领并处置,未认领即升级 |
| 中 | 趋势明确恶化但尚有缓冲;影响单个重要对象;影响面可控 | 一个巡检周期内处置 |
| 低 | 小幅偏离或一次性波动;无客户与资金影响 | 记录并观察,连续多期同向恶化再升一级 |
分级判据要写进规则,不要每次靠临时判断;同一条规则在不同周期里应给出可解释的分级结果。
第 5 步 · 归因(四问)
对每条命中逐条回答四问,四问答案不完整就不算完成归因:
| 四问 | 要写清什么 |
|---|---|
| 触发了什么 | 哪条规则、哪个对象、哪个时间点被命中 |
| 差多少 | 实际值、阈值、绝对偏差与相对偏差,必要时附上变化趋势 |
| 为什么 | 能查到原因的写原因与证据;查不到的写「待查证」并列出下一步核查动作 |
| 影响谁 | 影响的客户、物料、订单、责任人、金额或交付节点,尽量给出量化影响面 |
禁止把「为什么」写成猜测后当成结论。区分「已核实原因」与「推测原因」,两者在告警单里分开写。
第 6 步 · 输出告警单与处置建议
| 项 | 内容 |
|---|---|
| 输入 | 命中与归因结果 |
| 动作 | 按统一结构逐条出告警单,并写处置建议;先发高等级,再发中低等级 |
| 产出 | 「告警单」若干 + 本期「处置建议」 |
| 判据 | 每条告警都有对象、规则、偏差、等级、影响面、归因四问、处置建议、闭环状态 |
告警单结构与处置建议写法见 references/alert-playbook.md,模板见 assets/alert-ticket-template.md。
处置建议必须回答三个问题(不写「建议关注」这类空话):
- 今天先做什么?(一个明确动作,可执行、可验收)
- 谁来做?(责任角色或责任人)
- 需要什么决策?(是否需要上级拍板、是否需要跨部门配合)
确认门 2:发布告警单前,把高等级告警与涉及资金、客户、交付的告警单独列给用户确认。用户确认发送范围与优先级后,再对外发出。
第 7 步 · 跟进闭环状态
| 项 | 内容 |
|---|---|
| 输入 | 已发出的告警单 + 处理进展 |
| 动作 | 维护每条告警的闭环状态,记录认领人、动作、结果;对超时未认领的触发升级 |
| 产出 | 「闭环台账」:告警 ID、等级、责任人、状态、最近更新、是否超时 |
| 判据 | 每条告警都有明确状态与责任人;状态为已关闭时必须写清处置结果与验证方式 |
状态取值固定为四种:未处理 / 处理中 / 已关闭 / 误报。说明:
- 未处理:已发出但无人认领,或认领后无动作。超过约定时长即升级。
- 处理中:已认领并有明确动作与预计完成时间。
- 已关闭:处置完成,且经过一次复检确认指标回到阈值内或风险已被接受。
- 误报:经核实不构成异常。误报必须填写原因,并按
references/alert-playbook.md回写规则。
第 8 步 · 周期巡检报告
| 项 | 内容 |
|---|---|
| 输入 | 本期比对记录、告警单、闭环台账,以及上一期报告 |
| 动作 | 汇总本期扫描范围、命中规则数、按等级分布、Top 异常明细、处置建议,并与上期对比 |
| 产出 | 「巡检报告」,按固定周期(如每周/每月)输出 |
| 判据 | 报告里的每个数字都能追溯到对比记录或告警单;与上期的对比结论必须基于口径一致的数据 |
报告结构见 assets/alert-ticket-template.md。报告要回答「这期比上期是变好了还是变差了」,不能只罗列数字。
产出物规格
| 产出物 | 必含字段 | 使用时机 |
|---|---|---|
| 巡检范围说明 | 巡检对象、数据来源、时间范围、周期、责任人 | 第 0 步,确认门 0 |
| 巡检规则清单 | 规则 ID、监测指标、判定条件、阈值、阈值来源、周期、生效范围、默认等级、去重窗口 | 第 1 步,确认门 1 |
| 取数比对记录 | 规则 ID、对象、实际值、阈值、是否命中、口径备注、取数时间 | 第 2 步 |
| 告警单 | 告警 ID、对象、规则、偏差、等级、影响面、归因四问、处置建议、状态 | 第 6 步,确认门 2 |
| 处置建议 | 今天先做什么、谁来做、需要什么决策 | 第 6 步,随告警单 |
| 闭环台账 | 告警 ID、等级、责任人、状态、最近更新、是否超时、关闭依据 | 第 7 步 |
| 巡检报告 | 扫描范围、命中规则数、等级分布、Top 异常明细、处置建议、上期对比 | 第 8 步 |
产出格式要求:默认用 Markdown 表格与清单,便于直接复制到文档或工单系统;字段名统一,不随周期改名,否则上期对比会失效。
质量红线(禁止事项)
- 不许编造数据:实际值、阈值、偏差、影响面金额,全部必须来自真实数据;拿不到就写「数据不足」。
- 不许编造阈值来源:每个阈值必须说明来自历史分位、业务安全线还是同期对比;说不清就标注为候选值待确认。
- 不许把猜测写成结论:原因未经核实,一律标注「待查证」或「推测」,并与已核实原因分开写。
- 不许同一异常重复轰炸:去重窗口内同一对象的同一异常只发一次;偏差显著恶化或等级升高才按升级再发。
- 不许跳过确认门:规则未确认不巡检,发送范围未确认不外发高等级告警。
- 不许用「注意」「关注」当处置建议:必须落到具体动作、责任人与所需决策。
- 不许静默跳过问题:数据缺失、字段为空、口径不明必须单列,不得算作未命中而消失。
- 不许破坏口径一致性:同一指标在不同周期必须用同一口径;口径变更要写明变更时间与原因,并说明对历史对比的影响。
- 不许只读不改规则:误报必须回写规则(调阈值、加例外、改口径或下线规则),否则误报会长期存在。
- 不许越权写数:本技能全程只读取数,不做任何写操作,不代替业务系统执行处置动作。
参考文件索引
| 文件 | 内容 | 什么时候读 |
|---|---|---|
references/rule-design.md |
巡检规则设计方法:规则五要素、阈值定法、等级与升级策略、去重与静默、上线前回测 | 第 1 步、第 3 步、第 4 步 |
references/alert-playbook.md |
告警处置手册:告警单结构、归因四问、处置建议写法、闭环流转、误报回写、报告汇总 | 第 5 步、第 6 步、第 7 步、第 8 步 |
assets/alert-ticket-template.md |
可直接复制的告警单模板与巡检报告模板 | 第 6 步、第 8 步 |
关于产品(可选接入)
本技能自包含、可独立使用,不依赖任何外部系统,也不要求接入任何特定平台。
同一套方法在「Smartware」中另有产品化承载:能力清单、模板与规则可直接作为配置与验收的依据;是否接入、如何接入由团队按自身环境决定。