1. 课程导入

在银行核心系统、支付清算平台、信贷与风控系统中，一笔交易从发起、路由、记账到清算，往往跨越多个服务、数据库与中间件。当生产环境出现“客户扣款成功但账户未入账”“批量代发部分失败”“日终对账不平”等事故时，仅靠日志检索和口头描述很难还原真相。交易回放与事故复盘，正是把“不可见的资金流转过程”重新变成“可观察、可验证、可追溯”的工程能力。

一、什么是银行交易回放与事故复盘

交易回放，是指在受控环境中，依据真实交易发生时记录的输入报文、上下文参数、时间戳、路由决策和外部依赖响应，重新驱动交易处理链路，观察其状态变化与输出结果。它强调“可重复、可对比、可隔离”，而不是简单重跑一笔业务。

事故复盘，则是在事故发生后，围绕时间线、影响面、根因、处置动作和改进项进行结构化还原。复盘不是追责会，而是用证据链回答三个问题：发生了什么？为什么发生？如何防止再次发生？

两者关系密切：回放为复盘提供可验证的实验证据，复盘为回放定义需要重点验证的假设。没有回放，复盘容易停留在“猜测根因”；没有复盘，回放容易变成“无目标的技术演练”。

二、学习目标：从“会查日志”到“会建证据链”

本课程面向银行科技条线的开发、测试、运维、SRE 与业务运营人员。完成学习后，你应当具备以下能力：

• 定义能力：能准确区分交易回放、事故复盘、故障复现、压测回放等概念的边界与适用场景。
• 建模能力：能围绕交易唯一标识、全局流水号、状态机、上下文快照建立可回放的数据模型。
• 工程能力：能设计回放环境隔离、数据脱敏、依赖 Mock、结果比对与差异定位方案。
• 复盘能力：能组织时间线、影响面、根因分析与改进项跟踪，输出可审计的复盘报告。
• 工具能力：能使用日志平台、链路追踪、数据库快照、消息队列回放等工具完成实战操作。

三、课程整体框架：四层递进

四、典型场景：一笔跨行转账的“消失的十分钟”

某银行在日终对账时发现，一笔跨行转账在客户侧显示成功，但对方行未收到资金。运营人员初步判断为“通道超时”，但开发人员回放该交易后发现：交易在网关层已生成全局流水号，在路由层被分配到备用通道，备用通道返回“处理中”，而主通道随后又返回“成功”。系统因缺少幂等控制，重复记账一次，导致内部账户与通道流水不一致。

交易ID: TX202405180001
全局流水号: GSN-889900112233
时间线:
  10:00:01 网关接收请求，生成GSN
  10:00:02 路由决策：主通道A，超时阈值800ms
  10:00:03 主通道A超时，触发备用通道B
  10:00:04 备用通道B返回“处理中”
  10:00:05 主通道A延迟返回“成功”
  10:00:06 记账服务执行两次入账
异常码: DUPLICATE_POSTING
根因: 缺少基于GSN的幂等键与状态机终态校验

这个案例说明：交易回放的价值不在于“重跑一次”，而在于把路由决策、超时重试、幂等控制、状态机流转等隐藏逻辑暴露出来，让复盘从“通道超时”这种表面结论，深入到“幂等设计缺失”的根因层。

五、常见误区与复盘要点

• 误区一：把回放当压测。压测关注容量与性能，回放关注逻辑正确性与状态一致性，两者目标不同，环境要求也不同。
• 误区二：只回放成功交易。事故往往发生在异常分支、超时重试、补偿流程中，失败交易和边界交易才是回放重点。
• 误区三：复盘只写时间线。没有根因假设、验证证据和改进项跟踪的复盘，只是一份“事故日记”。
• 误区四：忽略数据脱敏与合规。生产数据进入回放环境前，必须完成脱敏、权限审批与审计留痕。