## 每日备份结果核验 {.case data-case-id="071"} | 字段 | 值 | | --- | --- | | 案例编号 | `071` | | 行业 / 部门 | 互联网 / 运维 | | 角色 | SRE 负责人 | | 难度 | `入门` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取备份系统任务日志） | 备份天天在做，可真到要恢复时才发现上周就失败了——这是最经典的坑。目标：每日定时让获授权 Agent 读取备份系统昨日任务日志并核验结果，逐任务留回执与时间戳，证据留痕；有失败时不静默、绝不当作成功。设一条最高优先级红线：核心系统备份失败，无论重试结果如何一律强制升级 SRE 值班人工确认处置，绝不静默、绝不当成功。指标：昨日备份失败 100% 当日出回执并升级，被当作成功的为 0 例；核验通过回执逐任务 100% 带结果与时间戳。 - **覆盖**：定时在源头白名单化读取昨日备份任务日志、按取数失败/核心失败/非核心失败/全部成功/当日无任务五路分流、核验通过回执逐任务留结果与时间戳、核心失败强制升级、非核心失败汇总通知修复。 - **不覆盖**：自动重跑备份任务、自动清理备份、自动恢复演练、备份策略的制定与修改。 - **假设**：有一个经授权能读取备份系统任务日志的 Agent（通过 App/Extension），App/Extension 在源头只放行任务代号、系统分级、结果与时间戳；核心与非核心清单在调用时作为输入提供。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每日定时由获授权的核验 Agent 经 App/Extension 读取备份系统昨日任务日志，App/Extension 在源头只放行任务代号、系统分级、结果与时间戳四个白名单字段——任务名与真实系统名在源头即被伪名化为任务代号（代号映射由平台侧持有，不进入本工作流），备份路径等敏感配置同样在源头被过滤。逐任务核验。回执遵循最小披露：只用任务代号、分级、结果与时间戳。 核验 Agent 回传 JSON：{stat_date: 日期, tasks: [{task_code: 任务代号, tier: 枚举(核心|非核心), result: 枚举(成功|失败), finished_at: 时间戳}], source_ok: 布尔, fields_missing: [枚举(备份系统)], audit_ts: 时间戳}。状态矩阵：source_ok 与 audit_ts 始终必填；source_ok=true 时 stat_date、tasks 必填（tasks 可为空）且 fields_missing 必为空，tasks 每个元素的 task_code、tier、result、finished_at 全部必填；source_ok=false 时 fields_missing 必为 [备份系统]，stat_date 与 tasks 禁止出现。仅接受这些组合；其余 callback 一律拒绝，原 Effect 保持 awaiting。 触发：定时（计划）发起调用，调用时带入核心与非核心清单、SRE 团队频道、值班频道（值班频道作为调用输入提供，用于升级与失败通知）、核验 Agent。 结果处理（先判取数成败，再按优先级从高到低判红线与其余）： 取数失败（备份系统不可达或日志陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；绝不当作"全部成功"，也不当作"当日无任务"。 核心失败（红线）：核心系统备份任务失败——无论重试结果如何，一律强制升级 SRE 值班人工确认处置，绝不静默、绝不当成功，并留审计时间戳；这是最高优先级，命中即短路，不会落到"汇总通知修复"路径。 有失败（非核心）：非核心任务失败汇总成修复通知发 SRE 团队频道，附任务代号与失败时间戳，留审计时间戳。 全部成功：发核验通过回执，逐任务留结果与时间戳，证据留痕，不静默结束。 当日无任务（查询成功但昨日无备份任务）：发一条"当日无任务"汇总回执并留时间戳，不静默结束。 审批：本工作流不涉及审批放行——核心失败由 SRE 值班人工确认处置，处置动作在对应系统完成，工作流只负责核验、通知与跟踪，不直接执行重跑或恢复。 异常：核验 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：通过回执、升级、修复通知、零结果回执、失败告警各自留审计时间戳后结束。 ``` ![案例 071 每日备份结果核验：定时让获授权 Agent 经 App/Extension 在源头白名单化读取备份系统昨日任务日志（任务代号、分级、结果、时间戳，真实系统名与备份路径在源头伪名化/过滤）并逐任务核验；先判取数成败（备份系统不可达按取数失败告警留审计重试升级绝不当作全部成功），再判红线（核心系统备份失败无论重试结果一律强制升级 SRE 值班人工确认处置绝不静默绝不当成功），非核心失败汇总通知修复，全部成功发核验通过回执逐任务留结果与时间戳，当日无任务发零结果回执；回传不合结构停在原等待点](../../../media/cases/fig-case-071-01-flow.svg){#fig-case-071-01 width=92%} 如上图所示，正常路径与异常同时可见，各结果都有可见回执： 1. **定时触发**：计划到点（每日）发起一次调用，带入核心与非核心清单、SRE 团队频道、值班频道与核验 Agent。 2. **核验备份任务**：获授权 Agent 经 App/Extension 在源头白名单化读取备份系统昨日任务日志，逐任务核验并回传（任务代号、分级、结果、时间戳）；回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **结果分流（先判取数成败，再判红线）**： - **核心失败（红线）**：核心系统备份任务失败，无论重试结果，强制升级 SRE 值班人工确认处置，绝不静默、绝不当成功，留审计时间戳；处置动作在对应系统完成，工作流只负责核验、通知与跟踪。 - **有失败（非核心）**：非核心任务失败汇总成修复通知发 SRE 团队频道，附任务代号与失败时间戳，留审计时间戳。 - **全部成功**：发核验通过回执，逐任务留结果与时间戳，证据留痕。 - **当日无任务**：发一条零结果汇总回执并留时间戳，不静默结束。 - **取数失败**：备份系统不可达或日志陈旧，告警失败并留审计时间戳，按重试上限重试，仍失败则升级到值班频道；绝不当作"全部成功"。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时取数 + 红线强制升级 + 多路分流"流程——它知道"核验备份任务"需要一个发消息并等待回调的 Agent 环节、"先判红线再分流"需要一个条件路由且红线优先级最高、"通过回执与升级通知"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **核心系统备份失败被当作成功**：这是最危险的漏判。靠红线兜底——核心系统备份失败无论重试结果如何一律强制升级 SRE 值班人工确认处置，绝不静默、绝不当成功。 - **备份系统不可达或日志陈旧**：绝不当作"全部成功"或"当日无任务"，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **当日无任务（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录——计划内的停备与漏建任务在回执上长得不一样，由人工分辨。 - **核验 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **核心失败的处置**：重跑备份、清理与恢复等动作由 SRE 在对应系统完成，工作流不直接执行，只编排确认、通知与跟踪。 本案例不设审批环节。核心失败走的是强制升级 SRE 值班人工确认处置，不是审批放行：值班确认的是"人已看到并接手处置"，处置动作在对应系统完成；非核心失败与通过回执直接发频道。因此不设 `request_approval` 环节。若企业要求核心失败处置后必须有人复核闭环，在提示词里写明，AI 会在流程里加一个审批环节。 本工作流对备份系统任务日志的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录——App/Extension 在源头只放行任务代号、系统分级、结果与时间戳，备份路径等敏感配置与真实系统名一律过滤。核心与非核心清单与频道作为调用输入提供；备份系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。备份系统不可达或日志陈旧属于取数失败，走失败回执与升级，绝不当作"全部成功"。 - **回放集与基准**：取最近 30 天备份任务日志快照（含全部成功、核心失败、非核心失败、无任务、系统不可达样本）回放，人工基准答案为按日志判出的结果清单；核验判定与基准一致率 ≥ 95%。 - **红线防线**：基准为核心失败的运行中，100% 强制升级 SRE 值班，被当作成功的为 0 例。 - **取数失败防线**：备份系统不可达的运行中，被当作"全部成功"的为 0 例，100% 出失败告警回执并留审计时间戳。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），并按 10% 抽查四层实际记录；回执内容 100% 不含备份路径等敏感配置与真实系统名。 - **结果可见**：通过回执、升级、修复通知、零结果、失败告警五类结果 100% 各有可见回执，不出现静默成功；通过回执逐任务 100% 带结果与时间戳。 - **分母与口径**：一致率分母为回放任务总数；每次运行记录读取与回执时间戳。 ### 复用与变体 - **同构迁移**：数据库快照核验、日志采集任务核验、证书到期巡检、定时作业结果巡检。 - **分级路由**：连续两天非核心失败也升级值班，单日失败只入汇总通知。 - **写回系统**：处置完成后再加一个 Agent 环节，由它通过 App/Extension 把处置结论写回备份系统任务备注；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=任务代号+统计日），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。