深色模式
定时任务与监控
本页说明
讲什么：完整定时任务清单（任务名/频率/职责/依赖）和监控告警规则与阈值 适合谁：需要查阅系统自动化任务和告警规则的产品经理和运营人员 前置阅读：架构与数据流预计阅读：4 分钟 负责人：技术运维主管
核心要点：出入金系统依赖大量定时任务驱动异步流程，监控告警覆盖流水采集、匹配引擎、银行回调、余额熔断四大类——任务挂起是最常见的异常根因。
定时任务总览
出入金系统依赖大量定时任务驱动异步流程。按业务域分为四大类：
| 业务域 | 任务数量 | 核心职责 |
|---|---|---|
| BST 银证 | ~7 个 | 入金/出金指令发送、结果轮询、状态同步 |
| 入金匹配 | ~3 个 | 流水匹配、异常检测、超时处理 |
| eDDA/eDDI | ~4 个 | 授权轮询、入金代扣指令结果查询 |
| 对账 | ~2 个 | 每日对账、差异检测 |
BST 银证定时任务
天星 BST 任务
| Job 名称 | 职责 | 触发方式 | 重试 | 说明 |
|---|---|---|---|---|
AsbBstCreateJob | 创建入金指令 | 用户入金触发 | — | 调用天星 API 发送入金请求 |
AsbBstCreateResultJob | 轮询入金结果 | 定时轮询 | 最多 60 次 | 查询天星 API 获取入金状态 |
AsbBstDepositJob | 入金到账处理 | 轮询返回 SUCCESS | — | 执行 SBA 入账编排 |
AsbBstTransfer | 出金转账 + 轮询 | 审批通过触发 | 最多 10 次 | 发送出金请求并轮询结果 |
SyncAsbBstWithdraw | 出金兜底同步 | 定时 | 2 小时窗口 | AsbBstTransfer 超时后的兜底 |
天星入金链路：AsbBstCreateJob → AsbBstCreateResultJob（60 次轮询）→ AsbBstDepositJob
天星出金链路：AsbBstTransfer（10 次轮询）→ SyncAsbBstWithdraw（2h 兜底）
招行 / 民生 BST 任务
| 服务名 | 银行 | 职责 | 说明 |
|---|---|---|---|
cmb_stock_trans | 招行 | 银证转账 | SM2 加密 Socket，实时双向推送 |
ms_stock_bank_transaction | 民生 | 银证转账 | SM2 加密 Socket，实时双向推送 |
招行/民生通过 Socket 双向链路实时获取结果，不需要轮询任务。结果通过同一连接直接推送。
详细的 BST 任务链路和银行对比 → 内银系 BST 总览 § 定时任务
入金匹配定时任务
| 任务 | 频率 | 职责 | 说明 |
|---|---|---|---|
| 自动匹配轮次 | 每 3 分钟 | 执行流水-申请匹配 | 对新到的 Flow 和待匹配的 Apply 进行 5 维度匹配 |
AbnormalDepositJob | 定时 | 异常入金检测 | 检测长时间未匹配的 Flow，触发通知 |
| 超时自动驳回 | 定时 | 超期申请处理 | 超过配置天数的未匹配申请自动驳回 |
各银行流水到达频率：
| 银行 | 流水方式 | 到达频率 |
|---|---|---|
| 汇丰 | MT910 实时推送 | 秒级 |
| 花旗/广发 | FPS API | 秒级 |
| 中银 | B2E 批量拉取 | 每日 3 次 |
| 其他银行 | 网银转账通知 | 分钟~小时不等 |
详细匹配逻辑 → 匹配与自动入账
自动匹配运行时间
自动匹配并非 7×24 运行。HKD/CNH 自动匹配窗口为周一 07:00~周六 10:00；USD 为每日 09:00~16:00。窗口外的流水仅进入智能提醒（7×24），不自动入账。详见 人工匹配指引 § 自动匹配 vs 智能提醒。
工银流水监控专题
工银（ICBC）流水系统采用双 AZ 容灾架构，有独特的监控需求。
双 AZ 架构
| 部署组 | 专线 | 说明 |
|---|---|---|
| 正式组 | 专线 1 | 主要流水拉取（拉取频率高） |
| 灰度组（备份） | 专线 2 | 备份流水拉取（拉取频率低） |
容灾限制
两条专线不可互切——正式组只能通过专线 1，灰度组只能通过专线 2。任一专线故障时，对应部署组无法切换到另一条线路。系统通过流水管理服务自动路由缓解此问题。
五类线上问题与处理
| 类别 | 表现 | 原因 | 处理方式 |
|---|---|---|---|
| ① 客户退款 | 正式组和灰度组均告警 | 客户转账后申请退款，银行删除该流水 | 最常见；按告警处理脚本执行（有自动生成 SQL 脚本） |
| ② 退款脚本失败 | 告警但一键处理脚本执行失败 | 灰度组拉取较慢，退款流水后无后续流水，脚本卡住 | 人工排查灰度组流水状态 |
| ③ 多笔相同流水 | 仅正式组告警，灰度组正常 | 两笔流水的时间、金额、remarks 完全一致，系统无法区分 | 修改 close_balance，将其中一条流水紧急入金 |
| ④ 银行推送异常流水 | 仅正式组告警，灰度组正常 | 银行侧先推送错误流水（余额与上一笔一致），后删除 | 确认方法：逐笔对比正式/灰度组流水 + 对比结单；删除未使用流水后重启 |
| ⑤ 跨日流水推送过晚 | 正式组和灰度组均告警 | 银行在 0 点后才推送 T-1 日流水 | 修改前一日 close_balance，将遗漏流水紧急入金 |
关键概念
| 概念 | 说明 |
|---|---|
| 余额校验 | 每笔流水入库时校验：上一笔 balance + 本笔 credit - 本笔 debit = 本笔 balance。退款导致流水被删除时，余额链断裂触发告警 |
is_used 字段 | 标识流水是否已被匹配使用。重新全量拉取后，is_used=0 的流水为未被匹配的流水 |
| 正式组 vs 灰度组差异 | 正式组拉取更频繁（可能逐笔拉取），灰度组拉取较慢（可能同时拉到多笔）。在退款和重复流水场景下两者行为不同 |
工银告警处理 Runbook
第 1 分钟 — 判断告警类别：
| 告警来源 | 大概率类别 | 下一步 |
|---|---|---|
| 正式组 + 灰度组同时告警 | ①客户退款（最常见） | 执行自动处理脚本 |
| 仅正式组告警 | ③重复流水 或 ④银行异常流水 | 逐笔对比两组流水 |
| 自动脚本执行失败 | ② 退款脚本卡住 | 人工排查灰度组状态 |
第 2~5 分钟 — 执行处理：
类别①（客户退款）：
- 确认告警中的 flow_id
- 执行自动处理脚本（脚本会自动生成修正 SQL 并执行）
- 验证：余额链恢复连续，告警自动消失
类别③/④（仅正式组）：
- 数据库中按
created_at对比同日正式组/灰度组流水 - 找到差异流水 → 判断是重复（③）还是幽灵流水（④）
- 类别③：修改其中一条的
close_balance，紧急入金 - 类别④：对比银行结单确认 → 删除
is_used=0的异常流水
- 数据库中按
超过 10 分钟未恢复 → 升级到技术运维值班人员
诊断命令与日志关键字
收到工银告警后，用以下关键字定位问题：
| 场景 | 服务 | 日志关键字 | 说明 |
|---|---|---|---|
| 余额链断裂 | icbc_be_relay | balance mismatch / close_balance | 流水删除导致余额不连续 |
| 流水重复 | icbc_be_relay | duplicate flow / same remarks | 金额+时间+remarks 完全一致 |
| 拉取超时 | icbc_be_relay | timeout / connection refused | 专线连接中断 |
| 灰度组延迟 | icbc_be_relay | canary lag / sync delay | 灰度组流水到达慢于正式组 |
| 跨日遗漏 | icbc_be_relay | missing T-1 / late push | 0 点后拉取未包含 T-1 日流水 |
快速验证
正式组和灰度组流水对比：在数据库中按 created_at 排序同日流水，如果某条流水仅在正式组出现 → 可能是银行推送异常（类别④）。如果灰度组比正式组少 → 可能是灰度组拉取延迟（类别②）。
中银双路流水监控
中银（BOCHK）的流水来自两个独立数据源，需要关联监控。
双路架构
| 数据源 | 类型 | 延迟 | 包含信息 |
|---|---|---|---|
| 银企服务 | 实时 API | 秒级 | 交易金额、币种、时间；部分有客户姓名 |
| FTP 报表 S16 | 定时拉取 | 约 30 分钟 | 补充客户姓名 + 汇款人账号 |
为什么需要双路
银企服务获取的流水信息大多数没有客户姓名，而姓名是自动匹配的核心条件。FTP 报表 S16 的作用就是补充这些关键信息。
FTP 报表运行时间
| 维度 | 时间 |
|---|---|
| 银行侧服务时间 | 周一~周六 8:00~20:00 |
| Futu 侧服务时间 | 7×24（全天候拉取） |
报表文件识别
| 版本 | 文件名格式 | 说明 |
|---|---|---|
| S16（当前） | AGSA/CNo+UC01.TXT, UC02.TXT, UC03.TXT... | 每个时段一个文件 |
| S14（旧版） | AGSA/CNo+AC1.TXT, AC2.TXT, AC3.TXT... | 已停用，仅供回退参考 |
流水关联规则
S16 报表中的流水与银企实时流水的关联方法：
- 取 S16 中的"交易流水号"
- 去除前 5 位
- 将剩余部分去掉前导零 → 得到
seq_no_s16 - 取银企实时流水中的
seq_no，去掉前导零 - 若
seq_no_s16 == seq_no→ 同一条流水，可关联更新
更新逻辑：
| 银企流水状态 | S16 更新内容 |
|---|---|
| 已有姓名（en_name） | 更新余额和银行账户号码 |
| 无姓名（en_name 为空） | 更新姓名、余额和银行账户号码 |
监控要点
| 监控项 | 触发条件 | 处理方式 |
|---|---|---|
| S16 报表延迟 | 超过 1 小时未收到新报表 | 检查 FTP 连接状态；确认是否在银行服务时间内 |
| 流水关联失败 | S16 流水号无法匹配到银企流水 | 检查流水号解析逻辑；可能是银行侧新增了未知格式 |
| 姓名未更新 | 银企流水长时间无姓名 | 检查 S16 是否正常拉取；确认报表中是否包含该流水 |
eDDA / eDDI 定时任务
eDDA（授权）和 eDDI（扣款指令）都用于入金代扣，不是出金协议。
| 任务 | 银行 | 职责 | 说明 |
|---|---|---|---|
| eDDA 授权轮询 | 汇丰/恒生 | 查询 eDDA 授权状态 | 用户发起授权后轮询银行确认结果 |
| eDDI 入金指令查询 | 汇丰/恒生 | 查询 eDDI 代扣结果 | 代扣指令发出后查询是否成功入账 |
| eDDI 入金结果处理 | 汇丰/恒生 | 入金到账 | 确认代扣成功后执行入账 |
| eDDA 状态同步 | 汇丰/恒生 | 定期同步授权状态 | 检测银行端是否有授权变更 |
eDDA/eDDI 和 BST 的轮询区别
eDDA/eDDI 轮询的是银行确认动作（授权是否成功、代扣是否完成），BST 天星轮询的是交易执行结果（入金/出金是否完成）。eDDA/eDDI 轮询频率较低，BST 天星轮询频率较高且有明确的重试上限。
并发告警分诊
值班运营同时收到多条告警时，按以下优先级排序处理：
| 优先级 | 判断标准 | 典型告警 | 为什么优先 |
|---|---|---|---|
| P0 | 资金已动但状态未更新 | 冻结未释放、出金同步超时（2h 用尽） | 资金状态不一致，可能导致重复出金或用户资金被锁 |
| P1 | 通道完全中断 | Socket 断开（招行/民生）、API 连通性异常（天星） | 影响所有后续交易，每分钟扩大影响面 |
| P2 | 单笔交易异常 | 入金/出金轮询超时、入金退款 REFUNDED | 影响单个客户，系统兜底机制通常在运行 |
| P3 | 趋势性预警 | 每日熔断触发、累计报警、审批积压 | 当前无即时影响，但不处理会恶化 |
可安全延后的告警
- 非交易日的 BST 告警 → 确认是伪触发（BST 周末不处理交易）
- 灰度组延迟 < 5 分钟（工银）→ 已知行为，灰度组拉取频率本身较低
- bank_端发起量突增 → 先观察是否为正常业务高峰（如月初/发薪日）
监控告警规则
Runbook 格式说明
以下告警规则按 Runbook 格式组织。收到告警后按「严重度 → 首响人 → 处理步骤 → 升级条件」流程执行。详见告警升级矩阵。
BST 银证告警
天星 BST：
| # | 告警项 | 触发条件 | 严重度 | 处理 |
|---|---|---|---|---|
| 1 | 授权创建超时 | Mandate PROCESSING 超过阈值 | 高 | 检查天星 API 连通性 |
| 2 | 授权失败率突增 | 单位时间 FAIL 数超限 | 高 | 排查银行侧异常 |
| 3 | 入金创建失败 | AsbBstCreateJob 连续失败 | 高 | 检查请求参数和 API |
| 4 | 入金轮询超时 | 60 次轮询用尽 | 高 | 人工查询银行侧 |
| 5 | 入金退款 | 收到 REFUNDED | 高 | 冲正 + 通知用户 |
| 6 | 出金轮询超时 | 10 次轮询用尽 | 高 | 进入 SyncAsbBstWithdraw |
| 7 | 出金同步超时 | 2h 窗口结束 | 严重 | 人工确认银行侧状态 |
| 8 | 冻结未释放 | 出金失败但冻结未回滚 | 严重 | 手动释放冻结 |
| 9 | 每日熔断触发 | 累计达 stop 阈值 | 中 | 评估是否恢复 |
| 10 | 累计报警触发 | 累计达 alarm 阈值 | 中 | 运营关注 |
| 11 | 重复交易检测 | ID 重复 | 高 | 检查去重逻辑 |
| 12 | API 连通性异常 | 响应超时/错误率升高 | 严重 | 联系天星技术支持 |
| 13 | 银行端发起量异常 | source=2 量突增 | 中 | 排查业务波动 |
招行/民生 BST：
| 告警项 | 触发条件 | 严重度 | 处理 |
|---|---|---|---|
| Socket 连接断开 | 与银行 exit_server 连接中断 | 严重 | 自动切换备用 server，同时告警 |
| 超时率升高 | -5 回调码占比超阈值 | 高 | 检查网络和银行侧状态 |
| 拒绝率升高 | -6 回调码占比超阈值 | 高 | 联系银行确认拒绝原因 |
入金告警
| 告警项 | 触发条件 | 严重度 | 处理 |
|---|---|---|---|
| 流水堆积 | 未匹配 Flow 数量超阈值 | 高 | 检查匹配任务是否正常运行 |
| 异常入金 | AbnormalDepositJob 检出异常 | 中 | 运营审核异常入金 |
| 自动入账失败 | 匹配成功但入账失败 | 高 | 检查 SBA 编排状态 |
出金告警
| 告警项 | 触发条件 | 严重度 | 处理 |
|---|---|---|---|
| 审批积压 | 待处理任务数超阈值 | 中 | 增加运营处理力量 |
| 大额出金 | 单笔金额超监控线 | 中 | 运营关注并确认 |
| 冲正操作 | 有出金被冲正 | 高 | 确认冲正原因 |
每日运营时间线
BST 和其他银行通道有各自的处理窗口，以下是典型交易日的时间线：
| 时段 | 事件 | 说明 |
|---|---|---|
| 07:00 | 招行/民生 BST 处理窗口开启 | |
| 08:00 | 天星 BST 处理窗口开启 | |
| 07:00 | eDDI（汇丰/恒生）处理窗口开启 | |
| 09:00~10:00 | 中银 B2E 第一批流水到达 | |
| 11:00 | 出金批次切割 | 11:00 后新提交的出金进入次日批次 |
| 11:00 后 | 出金文件导出 | 按方式导出转账文件上传网银 |
| 13:00~14:00 | 中银 B2E 第二批流水到达 | |
| 下午 | 支票存入 | 工作人员到各分行存入支票 |
| 16:00 | eDDI 处理窗口关闭 | |
| 17:00~18:00 | 中银 B2E 第三批流水到达 | |
| 22:00 | 天星 BST 处理窗口关闭 | |
| 次日 04:00 | 招行/民生 BST 处理窗口关闭 | |
| 次日凌晨 | 每日对账任务运行 |
非交易日
周末和公众假期（以港交所日历为准）BST 不处理交易。eDDI 仅工作日。FPS 理论上 7×24 但实际运营审批仅工作日。
告警升级矩阵
当告警触发后，按以下流程升级：
| 严重度 | 响应时效 | 首响人 | 升级条件 | 升级对象 |
|---|---|---|---|---|
| 严重 | 15 分钟 | 值班运营 | 15 分钟内无法恢复 | → 技术运维 + 对应银行服务开发者 |
| 高 | 30 分钟 | 值班运营 | 30 分钟内无法定位原因 | → 入金/出金产品经理 |
| 中 | 2 小时 | 值班运营 | 工作日内无法处理 | → 运营主管 |
严重级告警（需 15 分钟内响应）
- Socket 连接断开（招行/民生 BST）
- API 连通性异常（天星）
- 出金同步超时（2h 窗口用尽）
- 冻结未释放（出金失败但资金仍被冻结）
高级告警（需 30 分钟内响应）
- 流水堆积（待处理流水数超阈值）
- 入金/出金轮询超时
- BST 超时率/拒绝率突增
- 自动入账失败
- 冲正操作
- 入金退款（REFUNDED）
中级告警（需 2 小时内响应）
- 异常入金检出
- 审批积压
- 大额出金
- 累计报警/每日熔断触发
如果需求变更：调整监控告警配置
代码位置：
- 入金监控任务：
deposit/doc/crontab.sh（所有 Cron 定义） - 流水堆积监控：
deposit/src/app/Console/Commands/Monitor/FlowMonitor.php - BST 审批监控：
withdraw/src/app/Console/Commands/Monitor/AutoBsApprovalMonitor.php - auto_settings 告警：
withdraw/src/app/Business/AutoSetting.php→autoOut()方法（余额不足时自动告警） - 告警发送：通过飞书消息（
sendFeishu()方法），告警接收人配置在auto_settings.alarm_staff_name
常见变更场景：
- 修改流水堆积阈值 → 修改
FlowMonitor.php中的阈值常量 - 修改告警接收人 → 通过 CRM 自动出金设置页面修改
alarm_staff_name，或用AutoSetting::setAlarmStaff()API - 新增监控维度 → 创建新的 Monitor Command 类，注册到
crontab.sh - 修改告警间隔 → 修改
AUTO_SETTING_ALARM_INTERVAL（当前 1 小时，避免重复告警）
文档维护提醒
以下信息容易过时，建议每季度核对一次：
| 检查项 | 核对方式 | 负责人 |
|---|---|---|
| 银行维护窗口时间 | 向银行对接人确认是否有变更 | 银行对接人 |
| eDDA 支持银行列表 | 与汇丰/恒生通道实际配置比对 | 入金产品经理 |
| 出金通道费用 | 与银行最新费率表比对 | 出金运营主管 |
| 告警阈值 | 与 FlowMonitor.php / auto_settings 实际值比对 | 技术运维 |
| FPS ID 和收款人名称 | 与银行确认是否有更新 | 银行对接人 |
读完之后
| 我想... | 去看 |
|---|---|
| 了解 BST 任务的银行级详情 | 内银系 BST 总览 |
| 了解入金匹配逻辑 | 匹配与自动入账 |
| 看告警触发后的操作指南 | 人工匹配指引 |
| 查错误码和状态码 | 统一错误码中心 |
| 了解 CRM 各模块操作 | CRM 操作地图 |
| 了解 eDDA 排障流程 | eDDA 排障指引 |
这个页面有帮助吗？