鼎味监控场景包：通用平台的接入方
2026-09-29 · 候选接入设计；主讲通用能力见监控与自动处置平台。 本文只定义业务绑定，不新增通用内核对象，不批准资金政策、生产阈值或自动执行权限。设计维护为主架构会话，场景语义由各业务Owner负责。
1. 场景包边界
鼎味以版本化场景包登记对象类型、数据接入、业务词汇、信号口径、策略模板及受控动作。不在平台内核写“如果退款”“如果配送”的条件分支。
正常到期裁决、关单、核算等仍由既有业务流程自动推进。监控检查这些流程是否按其合同推进；自愈调用原Owner的恢复命令，不通过告警规则决定顾客是否同意、订单能否取消或钱应退到哪里。
语义依据：确认政策、交易不变量、事实归属。D-01至D-14的未决项不会因存在监控模板而关闭。
2. 接入职责与转译
- 业务Owner提供带对象身份、版本、时间和质量的受控事件/查询、正常完成条件、合法恢复命令及证据。自动数据化不是任意读取业务表或根据文案猜测状态。
- Analytics提供已有分析指标和数据质量信号，维护其统计口径；实时业务对象的期限检查不必绕经延迟报表。平台维护Signal登记/检测映射，不重复制定GMV或资金守恒口径。
- 场景包把对象、单位和动作描述转为客服可理解的选择；客服在授权参数内配置范围、条件、通知和获准套餐。编译、试算、自然语言回读和发布使用通用规范策略，不要求客服配置Prometheus。
- 一笔资金或某位顾客不能被整体成功率掩盖。汇总指标用于发现规模和趋势，对象级检查保护每笔义务；明细经授权下钻，不把客户手机号和所有订单号放入时序标签。
- 模板版本、业务政策版本和用户配置修订分别保留。订单适用的截止取自身快照；监控阈值T是处置等待预算，不重写顾客原截止，也不新增默认生产数值。
3. 候选场景绑定
这不是平台的起始指标目录，而是通用契约完成后的代表性接入检查。是否启用、具体阈值和套餐授权需逐项验证。
| 场景及Owner | 观察与检测意图 | 允许的候选套餐 | 恢复证据与禁止捷径 |
|---|---|---|---|
| 单量触发增援；Commerce/Analytics提供口径，现场运营接收 | 使用已有日累计信号，选择范围/分组、阈值与周期首次模式；200单仅为用户举例 | 已批准通知组→等待接收→超时升级→记录现场协作结果 | 不要求累计量下降，不以消息送达证明到岗；不自动更改排班、薪资或承诺人力 |
| 到期裁决积压；Demand/Commerce | 按各安排截止快照检查应裁决未完成对象，聚合积压及最老年龄 | 查询原安排和裁决；在原门禁下补扫/继续原协调 | Demand到期、执行停止及Commerce对应步骤分别核验；不取消已接受安排，不替顾客确认 |
| 取消/换菜停滞；Commerce/Fulfillment | 持久步骤年龄、停止结果未知、后继衔接阻塞 | 查原停止请求与步骤检查点，执行原合法恢复命令 | 前驱不可执行和后继授权分别核验；不恢复旧终态、不重复切配 |
| 收退款UNKNOWN；Commerce | 未知笔数/金额/年龄及对象级超时 | 只查询原目标并交Owner验证，预算耗尽升级 | 渠道验真、目标金额等证据及原资金占用；不重发非幂等请求，不凭告警消失释放额度；D-05/08仍约束 |
| 到货与质量依据缺失；Supply | 预计时点与实际接收/检验分别观察；识别采集失联 | 重取数据、核对接收接口、通知供给/质量人员 | 数据缺失不是货未到；不自动记录到货、放行或解除隔离 |
| 配送节点风险；Fulfillment | 已承诺时段与实际进度的对象检查 | 查原任务、通知调度、恢复获准的技术投递 | 现场交付依据，不改顾客时段，不把派工当送达 |
| 渠道积压/映射冲突；Channel | 同步水位、原请求状态及冲突对象 | 有有效映射及幂等依据才重试原目标，否则人工核验 | 外部/内部接受回执，不重复生成订单 |
| 数据与通知链失联；Platform/Analytics | 来源时效、质量、投递回执、分析发布水位 | 补采集、受控重建、查询原通知及获准备用渠道 | 新鲜数据覆盖与实际回执；重算不重放业务副作用 |
4. 三条端到端推演
已有单量触发增援
选择已登记的商业订单日累计信号 → 核对统计日、成立/取消口径、过滤范围和分组 → 预览已有数据（不重新接入）→ 配置阈值与通用周期首次模式 → 引用备勤响应方案并绑定同范围责任组 → 试算命中对象、通知内容与升级分支 → 启用后产生本期触发记录 → 通知送达、人员接受、到岗/协作结果分别核验。
“超过200单、每统计日一次”是设计样例，不批准生产阈值和次数政策。演示采用已成立订单累计、不因后续取消回减的口径；最终信号口径由源Owner确认。若实际目的是缓解打包积压，应另选待打包量，而不是更改累计单量的含义。
无人接受时按响应方案升级，不能显示“已增援”；到岗不是源指标恢复。次日仍需独立判断，昨日未完成工作继续有责任。每日第一次、重新越线和持续异常均来自平台模式，不在内核写单量专用分支。尚未确定的接收/升级时限不预填成正式承诺。
到期流程未正常完成
源安排记录到期事实及原政策版本 → 对象检测发现合法应推进步骤超过已设预算 → 通用平台形成事件并自动建主工单 → 值班责任与补扫套餐按版本绑定 → 套餐核验当前状态/原请求/权限 → 调用Owner恢复能力 → 分别检查到期、停止、关单等必需证据 → 条件满足才判定恢复并按工单规则验收。
若源记录已提前确认，恢复动作必须拒绝到期取消，事件需重新诊断；若执行已经开始、停止未知或数据过期，保留原证据并转有权人员处理，不能由监控强改状态。默认16:00来自确认政策，不由套餐另设。
退款结果未知
Commerce发布原目标UNKNOWN观察 → 对象等待策略达到预算 → 平台事件与工单 → 受限查询套餐 → 渠道观察交Commerce验真 → 检测读取Owner当前事实 → 已有合法确定结果才更新告警恢复。若为确定失败，应按模板创建/关联后续处置，不把“未知已消除”说成“顾客已退款”。
未知持续、渠道失联、金额或目标冲突均进入人工核验；有限查询预算不能转换成失败事实。是否发起退款、退款时点和去向仍受D-05约束，监控包不取得新的资金政策授权。
5. 通用性反证与接入门槛
先用HTTP可用性、设备观测异常、通用作业超时三个无零售语义的场景验证相同的接入—策略—告警—处置—验证契约，再验证本包。若增加一个鼎味场景必须修改核心状态枚举或增加特判，先检查契约缺口，不默认业务特化正确。
接入前核对：Schema/单位与时间、数据质量、范围授权、对象去重、政策快照、原请求查询、并发门禁、动作幂等、证据及升级责任。每个套餐单独决定只读/受控自动/需复核/禁止，不批量启用。
现有原型仅有本地合成规则、显式扫描和有限工单操作，不具备平台编译发布、真实采集、隔离执行或生产排班能力。后续映射必须按本文和通用主讲重新设计，不能从旧原型倒推已完成架构。