定時任務與監控
本頁說明
講什麼：完整定時任務清單（任務名/頻率/職責/依賴）和監控告警規則與閾值 適合誰：需要查閱系統自動化任務和告警規則的產品經理和運營人員 前置閱讀：架構與數據流預計閱讀：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 排障指引 |