1. 画图之前先把“核心”这两个字掂量清楚做核心系统这行十几年最怕听到一句话“你先给我画张图把核心系统讲明白。”画图本身不难难的是同一张图要同时让三类人看懂业务方要看到产品怎么配、账怎么走技术方要看到交易怎么落、库表怎么切运维和测试要看到日终怎么跑、出问题从哪查。一张图要撑住这三种视角就必须先想明白核心系统到底在银行里扮演什么角色。用一句最直白的话概括银行核心系统就是全行唯一有权改动“钱”的地方。渠道、支付、信贷、风控、报表、数据仓库这些系统手里都有数据但它们手里的余额只是“反映”不是“权威”。客户在手机上看到的余额、柜面打印的存单、对账单上的数字最终都要回到核心系统里那本账上对。所以核心系统在业内还有一个更准确的说法——账务权威源。任何一笔资金变动别的系统可以发起、可以校验、可以展示但只有核心系统能把这笔变动“记进去”并且保证借贷平衡、总分一致、可追溯、可回滚。这个定位一旦立住图就好画了。因为核心系统的所有模块、所有流程、所有参数本质上都在服务四件事第一把客户和产品描述清楚也就是“谁、用什么产品、开了什么账户”第二把每一笔资金变动翻译成会计语言也就是“借哪个科目、贷哪个科目、金额多少”第三把这些分录汇总成总账让全行的资产负债能对上第四在每天结束的时候把所有该算的利息、该提的准备、该结的账一次性算完保证第二天开门时账是平的。不少刚接触这块的同学会把核心系统理解成“一个大号的存款记账程序”这个理解偏差会直接导致画出来的图缺胳膊少腿。存款只是核心系统里最显眼的一块贷款、总账、内部户、产品参数、计息结息、日终批量、对外接口缺了任何一块这张图都跑不通一笔完整的业务。我见过一些方案文档画了满满一页的渠道和微服务唯独没画总账和内部户结果评审的时候被一句“这笔钱从哪个科目出”问得哑口无言。所以这张图的第一层不是技术架构而是账务架构。先有账后有系统先有科目后有服务。这个顺序搞反了后面拆微服务、选数据库、做单元化全是空中楼阁。接下来的内容我会按“总览图怎么分层—模块怎么拆—一笔交易怎么走—利息怎么算—分布式怎么改—问题怎么查”这个顺序把这张图一层一层摊开讲中间穿插参数计算、实操细节和踩过的坑尽量做到你看完能自己动手画一张并且能拿着它去跟业务和技术两边对话。2. 总览图的第一刀按“账”分层而不是按“系统”分层2.1 六层结构从渠道到总账每一层只干一件事我习惯把核心系统的总览图切成六层从上到下依次是渠道接入层、交易路由层、产品服务层、账务处理层、总账汇总层、数据服务层。这个切法的好处是每一层职责单一出问题时能快速定位是哪一层的责任而不是一上来就翻几万行代码。渠道接入层负责协议转换和报文校验柜面、手机银行、网上银行、自助设备、批量代发、第三方支付机构的指令都从这里进来。这一层不碰账只做“翻译”和“初筛”比如报文格式对不对、必填项全不全、签名验没验过。很多生产事故就出在这一层没卡住脏数据一路穿到账务层最后只能靠冲正收拾。交易路由层负责把请求分发到对应的业务处理单元同时做限流、熔断、灰度分流。这一层的关键是“路由规则要可配置”比如按产品码路由、按客户等级路由、按机构路由。规则写死在代码里后期做产品差异化或者迁移切流会非常痛苦。产品服务层是业务逻辑的主战场存款开户、存取款、贷款放款、还款、转账、冻结、解冻都在这一层。它的输入是交易报文输出是“账务指令”也就是一组待记账的分录。注意这一层只负责“算出该怎么记”不负责“真的去记”这个边界一定要划清楚。账务处理层是真正动余额的地方负责分录落库、余额更新、账户状态变更、流水登记。它的核心要求是强一致、可幂等、可冲正。所有对余额的修改必须在这一层完成任何绕过这一层直接改库的操作都是给自己埋雷。总账汇总层负责把分户账的分录按科目汇总生成总账余额做总分核对。这一层是财务口径和业务口径的接缝处也是月末季末最容易被追问的地方。数据服务层负责对外提供账户查询、流水查询、对账单下载、报表抽取。它读的是账务数据但不改账所以可以做读写分离、可以做缓存压力大也不至于影响记账主链路。这六层画在一张图上横向再按业务域切一刀就是客户域、存款域、贷款域、支付结算域、总账域、公共域。纵向分层解决“职责”横向分域解决“归属”两刀切完一张图的骨架就有了。2.2 三条主线交易流、账务流、数据流必须分开画骨架有了接下来要画“流”。我见过太多图把交易流和账务流画成一条线结果看图的人以为记账是同步完成的一做压测就发现不对。实际上一笔业务在核心系统里至少有三条独立的流在跑。交易流是实时的从渠道进来经过路由、校验、业务处理最后返回结果给客户。这条流追求的是响应时间通常要求几百毫秒内完成。账务流是交易流的子过程但它关注的是借贷平衡和分录完整性一笔交易可能产生两条、四条甚至更多分录这些分录必须全部成功或者全部失败。数据流是异步的日终批量、报表抽取、数据仓库同步都走这条线它追求的是吞吐量和最终一致。把这三条流分开画好处是能一眼看出哪些环节是同步阻塞的、哪些是异步解耦的。比如转账交易里扣款和入账必须在同一个事务里完成这是同步的而短信通知、积分累计、报表登记完全可以异步做。如果图上把这几件事画成一串说明设计上还没想清楚哪些能松、哪些必须紧。注意三条流分开画不等于三套代码。很多团队为了图好看把交易流和账务流拆成两个服务结果联机交易里出现了跨服务事务反而把简单问题搞复杂了。分层的目的是理清职责不是制造调用链。2.3 一张图里必须出现的“隐性模块”除了上面那些显眼的模块核心系统里还有几块东西业务方平时看不见但图上不画就会漏掉关键逻辑。第一块是参数管理产品码、利率码、费用码、科目映射、机构参数、渠道参数全在这里参数配错导致的生产问题占比相当高。第二块是内部户管理应收、应付、过渡、垫款、手续费收入这些内部账户是联机交易能平衡记账的关键。第三块是批量调度日切、计息、结息、计提、摊销、总分核对、报表生成全靠它串起来。第四块是权限与授权大额交易复核、冲正授权、参数修改审批这些控制点不画出来审计那一关过不去。这四块内容在图上通常放在侧边或者底部用虚线连到主流程表示它们是“支撑性”的。我建议画图的时候给它们留足位置因为实际排查问题时十次有六次最后查到的是参数、内部户或者批量顺序上。把这些隐性模块显性化图才真正具备“排查手册”的价值而不只是一张汇报用的架构示意图。3. 模块拆解客户、产品、账户、总账四块积木怎么搭3.1 客户信息与账户分离一个客户号撑起所有关系核心系统里第一个要讲清楚的概念是“客户与账户分离”。客户信息记录的是“人”或者“单位”包括客户号、证件类型、证件号码、联系方式、客户等级、风险标识账户记录的是“钱”包括账号、产品码、币种、余额、状态、开户机构。一个客户可以开多个账户一个账户只属于一个客户这是最基础的一对多关系。为什么要分离因为很多业务规则是挂在客户身上的不是挂在账户上的。比如同一客户在本行的所有账户合并计算限额、同一证件号不能重复开一类户、客户等级决定费率优惠。如果客户信息和账户信息揉在一张表里这些规则实现起来会非常别扭。画图的时候客户域通常放在最左边用一个方框表示客户主档下面挂客户关系、证件、联系方式、客户标签几个子块。客户域和存款域、贷款域之间用“客户号”这条线连接。这条线看着简单但它是后面做统一视图、做反洗钱监测、做额度共享的基础。我见过一些老系统客户信息散落在各个业务模块里同一个身份证号在不同模块对应不同的客户号后期做客户合并花了整整一年这种教训值得记在图上。3.2 产品工厂参数化程度决定核心系统的天花板产品工厂是核心系统里最能体现设计水平的一块。所谓产品化就是把“活期存款”“整存整取三年”“通知存款”“个人消费贷款”这些业务形态抽象成一组可配置的参数而不是每个产品写一套代码。产品码是主键下面挂利率参数、计息方式、期限规则、费用规则、账户规则、交易控制规则。我举个具体的参数组合来说明它有多细。一个定期存款产品至少要配币种、起存金额、存期、利率码、计息基准360还是365、计息方式单利还是复利、结息方式利随本清还是按期付息、提前支取规则靠档还是活期、逾期规则、自动转存标志、是否允许质押。这些参数里任何一个配错算出来的利息就是错的而且错得很隐蔽往往要等到客户投诉才发现。产品工厂画在图上通常是一个大方框下面挂一排小方框每个小方框是一类参数。旁边用箭头指向“账户开户”和“交易处理”表示产品参数在开户时被实例化到账户上在交易时被读取使用。这里有个关键设计点账户开户时要把产品参数“快照”下来。因为产品参数会调整如果账户不存快照每次计息都去读最新参数那存量客户的利率会跟着新产品一起变这在业务上是不可接受的。快照这个动作在图上往往被忽略但它是利息计算准确性的前提。3.3 账户模型余额不是一个数是一组数新手最容易犯的错误是以为账户余额就是一个字段。实际的核心系统里一个账户的余额至少包括账面余额、可用余额、冻结余额、透支额度、上日余额、当前余额几个维度有的还会区分已入账未起息、已起息未到期。账面余额是会计口径的实际金额可用余额是客户能动的钱两者之差通常就是冻结金额和未达账项。举个大额存单质押的场景客户账户里有100万质押冻结80万账面余额还是100万但可用余额只有20万。如果图上的账户模型只画一个“余额”字段这个场景就没法解释。账户状态同样是一组标志位正常、冻结、只收不付、只付不收、睡眠、销户、久悬不同状态对应不同的交易准入规则。画图时我建议在账户方框里把“余额结构”和“状态机”作为两个子块单独画出来状态机用箭头表示流转方向比如正常到冻结、冻结到正常、正常到销户。别小看这个状态机很多生产问题就是状态判断漏了一种情况导致该拦的交易没拦住。3.4 总账与内部户所有分录的最终归宿总账这块是技术同学最容易轻视、财务同学最关心的部分。核心系统里每一笔联机交易产生的分录最终都要落到会计科目上科目再汇总成总账。总账余额和分户账余额之间必须满足勾稽关系也就是“总分核对”。内部户在这里扮演关键角色。举个转账的例子客户A向客户B转账100元从账务上看是A的存款账户减少100B的存款账户增加100一借一贷正好平衡。但如果这笔钱要收1元手续费且手续费要先挂账后结算就需要一个“手续费应收”内部户参与分录变成A账户减101、B账户加100、手续费收入户加1。再比如跨行转账钱先出账但对方行还没确认中间要经过“待清算”过渡户这时候过渡户的余额就是需要重点监控的对象。画图时总账域通常放在最下方用一条粗线把所有业务域的分录汇总上来。内部户单独列一组用虚线连到各个业务域表示“哪个业务会用到哪个内部户”。我强烈建议在图上标注每个内部户的用途和余额方向因为内部户挂错方向、用错科目是总分不平的最常见原因之一。4. 一笔转账的全链路图上那条线到底怎么走4.1 联机交易的九个步骤每一步都有卡点把一笔跨行转账拆开看核心系统内部大致要走九步报文接收与格式校验、幂等检查、账户信息查询、交易准入校验、风控与限额检查、账务分录生成、余额更新与流水登记、记账结果返回、异步通知与登记。这九步在图上应该画成一条带序号的线每一步旁边标注关键校验点。幂等检查这一步值得单独说。渠道重复发报、网络超时重试、批量重跑都会导致同一笔交易进来多次。核心系统的做法是要求每笔交易带一个全局唯一流水号账务层对流水号建唯一索引重复请求直接返回首次结果不重复记账。这个设计在图上就是一个“漏斗”形状的检查点所有交易必须先过这一关。账务分录生成这一步是业务逻辑的核心。以扣款转出为例分录通常是借客户存款账户贷待清算过渡户。对方行确认后再做借待清算过渡户贷存放央行款项或者同业存放。这两组分录分属不同时点图上要用两条线分别表示“发起时”和“清算时”不能合并。余额更新这一步必须强调事务边界。账户余额、流水表、分录表三者的更新要在同一个本地事务里完成任何一步失败都要整体回滚。如果这三个操作跨了服务、跨了库就必须引入可靠消息或者对账补偿这时候图上要明确标出“分布式事务处理点”不能含糊带过。4.2 借贷平衡怎么落分录表和余额表是两张皮很多同学画图时把“记账”画成一个动作实际上记账至少涉及两张表分录表和余额表。分录表记录每一笔借贷方向、科目、金额、交易流水号是流水性质的余额表记录每个账户、每个科目的当前余额是状态性质的。两者必须同步更新且分录表的借贷合计必须相等。这里有个实操细节分录表一般不存“余额”字段只存发生额余额是靠余额表维护的。日终的时候会拿当天的分录发生额去和余额表的变动做核对这就是所谓的“发生额核对”。如果某笔交易只更新了分录没更新余额或者反过来核对就会报错。所以画图时我建议在账务层画两个并排的方框一个写“分录发生额”一个写“余额状态”中间用双向箭头连起来表示必须成对更新。借贷平衡的校验点也要标出来。联机交易在提交前要做一次借贷合计校验不等就不许提交日终批量再做一次全量校验把当天所有分录按科目汇总检查借贷是否相等。这两道关卡是账务准确性的底线图上不画等于告诉后来的人“这里可以省”迟早出事。4.3 幂等、冲正、对账一致性三件套缺一不可幂等解决的是“重复请求”冲正解决的是“记错了要撤回”对账解决的是“两边数据不一致怎么发现”。这三件事在图上应该作为账务层的三个独立能力画出来而不是散落在各个业务流程里。冲正的处理方式有两种红字冲正和蓝字反向。红字冲正是用负数金额记一笔反向分录原分录保留蓝字反向是记一笔方向相反的正数分录。两种方式都能把余额改回来区别在于对流水和报表的影响。我个人更倾向红字冲正因为原交易痕迹完整保留审计追溯时一目了然。冲正必须带授权大额冲正还要走复核这个控制点在图上用一个小锁的图标位置标注一下提醒后来者别忘了。对账分三层渠道对账、总分核对、内外对账。渠道对账是核心系统和渠道系统之间的流水比对总分核对是分户账和总账之间的余额比对内外对账是和清算机构、第三方支付之间的资金比对。三层对账的频次和口径不同图上要分别画出来。对账不是为了好看它是发现不一致的最后一道网网眼大小取决于业务的重要程度这个道理在图上标清楚比写十页制度都有用。5. 利息怎么算把公式拆到能敲计算器验证5.1 活期计息的日积数法一步步算给你看活期存款利息的计算业内主流做法是日积数法。核心公式是利息等于累计计息积数乘以日利率日利率等于年利率除以计息基准天数。计息基准通常取360或者365这个参数在产品里配置不同产品可以不一样。举个具体例子。某活期账户年利率0.3%计息基准360天账户余额在30天内一直是10000元没有变动。日利率等于0.3%除以360等于0.000008333。累计积数等于10000乘以30等于300000。利息等于300000乘以0.000008333约等于2.5元。这个数你可以拿计算器直接验证如果系统算出来是2.53或者2.47就要去查计息基准和天数口径。实际系统里余额每天都可能变所以积数是按日累加的每天日终取账户余额乘以当天的天数权重累加到一个积数余额字段上结息日再用积数乘以日利率。这里有两个容易踩的坑一是起息日当天的余额算不算积数不同产品规则不同参数里要配清楚二是结息日当天发生的交易算不算当期通常以日切时点为准日切之后发生的交易计入下一期。画图时计息模块要画出三个输入账户余额变动流水、利率参数、计息基准参数一个输出积数余额和应收应付利息。积数余额这个中间字段很多人不画但它是排查利息差异的关键抓手建议在图上明确标出来。5.2 定期与贷款计提时点不同算法不同定期存款和贷款的利息处理逻辑跟活期不一样它们是“计提制”。定期存款在存期内按月或者按季计提应付利息到期一次性支付贷款则是按月计提应收利息同时按五级分类计提减值准备。计提的意义在于权责发生制收入和成本要落在对应的会计期间不能等到实际收付才入账。以一笔100万元、年利率4.35%、期限一年的贷款为例。按月计提月利率等于4.35%除以12等于0.3625%每月计提利息3625元。分录是借应收利息贷利息收入。客户实际还息时再借客户存款账户贷应收利息。如果客户逾期没还应收利息要转入表外科目同时计提减值准备这时候涉及的科目就更多了。计提这块在图上要画出“计提引擎”这个模块输入是贷款账户的余额、利率、期限、还款方式输出是计提金额和分录。旁边要标注计提频率和计提日通常是每月末或者每季末。计提金额算错直接影响利润表所以这个模块的测试用例要覆盖提前还款、逾期、利率调整、期限变更这些边界场景。5.3 日终批量顺序错了账就平不了日终批量是核心系统每天最重的一段活顺序安排非常讲究。我一般的建议顺序是日切确认当日交易截止、联机交易补记、计息积数累计、结息处理、贷款计提、手续费摊销、总分核对、报表生成、数据抽取、日启切换营业日期。这个顺序里日切必须在最前面因为它决定了哪些交易算今天、哪些算明天。计息积数累计要放在结息之前因为结息要用到当期积数。总分核对要放在所有账务处理之后否则核对的是一本还没记完的账。报表生成和数据抽取放最后它们只读不写不影响账务。日终超时是生产上最常见的批量问题。原因通常有三类单笔交易处理慢导致批量积压、数据库批量更新锁等待、批量任务之间依赖顺序设计不合理。排查的时候先看批量监控里哪个任务耗时异常再看那个任务的SQL执行计划最后看是不是有长事务没提交。图上把批量任务画成一条带时间轴的流水线每个任务标注预计耗时和依赖关系运维同学排查起来会顺手很多。提示日终批量一定要做断点续跑和重跑幂等。跑到一半失败不能从头再来否则已经计提的利息会重复计提。每个批量任务要有独立的运行状态表和幂等键这个设计在图上用一个小的“状态表”方框标出来就行但千万别省。6. 从集中式到分布式改造时图要怎么改6.1 拆分边界按业务域拆不按表拆核心系统做分布式改造第一个难题是拆分边界。我的经验是按业务域拆不按表拆。存款、贷款、支付结算、总账、客户这五个域各自有独立的生命周期和事务边界拆开之后跨域调用相对少。如果按表拆比如把账户表放一个服务、流水表放一个服务那每笔交易都要跨服务事务成本高得离谱。拆分的具体做法是先画领域模型找出聚合根。存款域的聚合根是账户贷款域的聚合根是借据支付域的聚合根是支付指令总账域的聚合根是科目余额。一个聚合内的操作保持本地事务跨聚合的操作走最终一致。图上用不同的颜色块表示不同域域内用实线域间用虚线加箭头标注“异步”或者“补偿”。这里有个现实约束老核心系统的表结构往往是几十个业务共用一套账户表想拆干净需要先做数据解耦。比较稳妥的路径是先做逻辑隔离把不同业务的账户打上业务标识再逐步迁移到独立库。这个过程在图上表现为“过渡态”画图的时候要专门画一张演进路线图把目标态和过渡态分开否则实施团队会拿着目标架构图去改现有系统改到一半发现根本落不了地。6.2 热点账户拆、缓、限三招够用热点账户是分布式核心绕不过去的坎。一个代发工资账户、一个平台商户的收款账户、一个手续费收入内部户短时间内可能有成千上万笔交易打上来行锁竞争直接把吞吐量压下去。常用的解法有三招。第一招是拆把热点账户拆成若干子账户交易按客户号或者流水号哈希路由到子账户查询时再汇总。第二招是缓把高频小额扣减放到内存缓冲累积到一定笔数或者一定时间再批量落库代价是实时余额不精确需要配合可用余额的预扣机制。第三招是限对单账户设置交易频率上限超过就排队或者拒绝用业务手段削峰。这三招在图上分别对应三种不同的画法拆是横向复制多个账户方框缓是加一个缓冲队列限是加一个限流阀门。实际项目里通常是组合使用比如代发工资用拆加缓内部户用缓加限。选型的时候要看业务对实时余额的要求要求强实时的只能拆能容忍秒级延迟的可以缓。6.3 数据库选型与迁移双跑别拿生产当试验田数据库选型这块我的观点比较务实没有银弹只有取舍。集中式商用库的优势是事务强、生态成熟、运维工具全劣势是扩容成本高、单点风险开源分布式库的优势是水平扩展、成本低劣势是跨分片事务弱、复杂查询性能不稳定、运维门槛高。核心系统的账务库如果交易量在可控范围内我倾向于保留强事务能力的方案把扩展性压力往应用层和缓存层转移。如果确实要上分布式库必须先把分片键设计清楚账户号或者客户号做分片键是常见选择但要注意跨分片查询和全局唯一序列号的实现。迁移是风险最高的环节标准做法是新老双跑。具体步骤是先做静态数据迁移客户、账户、参数再做增量数据同步流水、余额然后让新系统以只读方式接查询流量做比对比对一致后再切部分写流量最后全量切换。双跑期间要有自动比对工具逐账户比对余额、逐笔比对流水差异要能定位到具体字段。图上把双跑画成两条并行的流水线中间用比对工具连接切流开关单独标注回退路径用反向箭头画出来。回退方案不画评审过不了这是硬规矩。7. 问题排查实录那些图上看不出来、只有踩过才知道的坑7.1 账务不平的排查路径从科目倒推账户账务不平是核心系统最典型的问题表现是总分核对差异、借贷不平、或者余额与流水不符。排查我一般按四步走先定位差异科目再拉该科目当天的全部分录按交易流水号分组核对借贷然后拿异常流水号去查联机日志最后看是不是有内部户挂错方向。常见原因有五种一是过渡户余额未及时清理比如跨行转账对方行一直没确认钱挂在待清算户上二是冲正交易只冲了余额没冲分录或者反过来三是批量计提重复执行导致费用科目多计四是并发更新余额时丢更新账户余额比流水累计少五是参数配错比如新产品的科目映射指到了错误的内部户。这里面最隐蔽的是丢更新因为它不会报错账面上看余额是正的只是比实际少了。排查方法是拿账户余额和当天所有流水按时间顺序累加一遍对不上就说明中间有更新丢失。根治办法是余额更新加乐观锁或者悲观锁同时在分录表上记录更新前的余额和更新后的余额方便事后追溯。这个字段设计在图上就是一个不起眼的小格子但它是排查利器。7.2 日终超时与批量优化先看锁再看SQL最后看架构日终批量超时我的排查顺序是先看数据库有没有锁等待再看耗时最长的几条SQL执行计划最后才考虑是不是要拆分批量任务。大部分情况下问题出在前两步。锁等待的典型场景是批量更新账户表时联机交易还在跑两边抢同一批行锁。解决办法是日切后先停联机写交易或者把批量更新改成分批提交每批几千条减少锁持有时间。SQL问题的典型场景是全表扫描、索引失效、统计信息过期这些用执行计划一看便知。架构层面的问题通常是批量任务串行依赖太多能并行的没并行这时候才需要动刀子重构。还有一个容易被忽略的点批量任务的日志。很多团队的批量日志只记录“开始”和“结束”中间没有任何进度信息一出问题只能干等。我建议每个批量任务至少记录已处理笔数、当前处理到的主键、耗时这样断点续跑和问题定位都有依据。图上画批量流水线的时候把“进度日志”作为每个任务的标配画进去后期运维会感谢你的。7.3 常见问题速查表问题现象优先排查方向常见根因处理建议总分核对有差异差异科目当天的分录过渡户未清理、冲正不完整逐笔核对分录补记或冲销账户余额与流水累计不符并发更新、批量重复执行丢更新、计提重跑加锁、批量幂等键利息金额与预期有尾差计息基准、天数口径360/365配置错误、起息日算错核对产品参数和日切时点联机交易超时数据库锁、慢SQL、下游依赖热点账户行锁、批量占锁拆子账户、错峰批量重复记账幂等键缺失或重复渠道重发、批量重跑流水号唯一索引、结果缓存迁移后余额有分差精度截断、币种舍入金额字段精度不一致统一精度规则逐户比对产品开通后交易报错产品参数、科目映射参数漏配、科目未授权建立产品上线检查清单日终任务卡住不动锁等待、死循环、依赖未完成长事务、前置任务失败查锁、查依赖、看进度日志这张表我建议直接贴在项目组的墙上新同学入职第一周就让他背下来。不是因为这些问题多高深而是因为它们出现频率太高有一个固定路径能省下大量沟通成本。7.4 几个只有踩过才知道的经验第一个经验新产品的参数配置一定要做“配置即测试”。产品工厂给了业务很大的自由度但自由度越大越容易配错。我的做法是每配一个新产品就用一组标准交易跑一遍开户、存款、取款、结息、销户把结果和手工计算比对比对通过才允许上线。这个动作看着笨但比上线后改数据便宜太多。第二个经验账务层的任何改动都要有“双人复核”和“可回退脚本”。改余额、改状态、改分录这三类操作必须有审批和回滚方案。我见过一次生产事故运维同学手工改了一个账户的冻结金额忘了同步改可用余额结果客户第二天取不出钱排查了整整一天。第三个经验画图的时候给“异常流”留位置。大部分架构图画的全是正常路径一笔交易顺顺利利走完但真正消耗人力的是异常超时怎么办、对方行拒绝怎么办、记账成功但通知失败怎么办、批量跑到一半宕机怎么办。把这些异常分支用虚线画在图上标注处理策略这张图才具备实战价值。第四个经验不要迷信“一图搞定”。一张图能讲清楚主干但讲不清楚细节。我的习惯是一张总览图加若干张局部图总览图讲清分层和流向局部图讲清关键模块的内部逻辑比如计息、分录生成、批量调度。图与图之间用编号关联形成一套图册。这样既保证了整体感又不至于一张图上挤满几百个方框谁看谁晕。最后分享一个我个人画图的习惯每次画完我会拿一笔真实业务从头到尾“走”一遍图边走边问自己“这一步的数据从哪来、到哪去、失败了怎么办”。走不通的地方就是图上的漏洞补上再走一遍。这个笨办法帮我避开了很多次评审时的尴尬也让图真正变成了团队共用的语言而不是挂在墙上的装饰。