美利集团技术 - 融资平台团建活动十渡合影

作者 | 阿兵（郭斌）

编辑 | 李雨侬

写在前面

今天更多想分享下做支付的经历，回忆下在踏入互联网金融前，我在传统银行里做某某银行海外卡业务，其中涉及到关于柜台支付交易：收，转，支；也曾亲身经历过重大资金损失事故，深深的让我对支付交易产生敬畏，从此，我的思考是凡是涉及到钱的工作，必须严谨、认真、多检查、多测试。

入职美利后，再次玩起了“支付”，美利金融起初刚成立，一切都是从 0 开始，团队和系统开始搭建，然而业务发展的速度，对支付系统要求非常急迫，从支付场景、交易量、通道稳定、信息安全等多方面快速建立和支持，建设时间短，加上我们的研发对于支付来说都是“小白”，看似做的很快，然而上线后问题故障频发，也发生多起资损事件。

经过 2 年多的支付平台建设，我们迭代了三个大的系统架构，生产中趟过很多坑，但值得宣扬的是我们把每一个坑、事故，都写成了 RCA 报告，通过不断复盘，到现在美利支付取得非常不错的成绩：系统微服务架构布局落地、生产运营系统稳定、支付工作流程规范、数据信息安全等，截止发稿我们的零资损完成了“ 401 ”天。

什么是 RCA ？

上文中提到了 RCA ，这是一个值得宣导的工作态度。RCA 的英文：Root Cause Analysis 中文意思是：根本原因分析。

RCA 是一项结构化的问题处理法，用以逐步找出问题的根本原因并加以解决， 而不是仅仅关注问题的表征。根本原因分析是一个系统化的问题处理过程，包括确定和分析问题原因，找出问题解决办法，并制定问题预防措施。在组织管理领域内，根本原因分析能够帮助利益相关者发现组织问题的症结，并找出根本性的解决方案。

我们对于支付中发生的任何生产问题，都要写成 RCA 报告放到 wiki 上，只有不断认识到根本原因，输出杜绝措施，犯过的错误才可能不再犯，这样才能形成经验，而这些 RCA 文章，也非常方便的给其他开发同学阅读、分享，做到经验传导。

如何理解资损？

资损：资金损失，我们老板对“资损”定义分为正资损和负资损：

正资损：

一般来说公司付款多付出去了，从公司角度来说，产生了直接资金损失，挽损方案可能在通知客户情况下，主动代扣相应款项，但存在用户快速把钱转走，后续需要借助催收。

产生影响：占用公司客服，催收资源；可能存在追不回来的情况。

负资损：

最典型的问题就是重复代扣了客户的期款，从公司的角度来说，看上去公司资金没有损失，损失在客户，我们可以主动还给客户，但往往这是最致命的，客户是每个自然人，脾气、性格都不同，如果遇到比较执拗客户，不愿意谅解，会出现威胁、大骂、甚至发到互联网或自媒体曝光，对公司声誉产生损害。

产生影响：占用客服资源，需要对客户安抚，需要承受客户恶语态度；事故存在发到互联网，对公司产生危机，动用公关资源等。

另外资损事件一次发生，往往可能涉及大量交易及巨额资金（主要看平台交易量），只要发生就是 P0 事故，这里更要考量我们对支付的监控和及时故障报警的能力。

我们遇到的坑

列几个典型真实资损案例，简单做了下复盘：

业务重复发单，导致重复代扣

问题：系统新上线发单，同一个客户发送两次，交易流水不同代扣业务，导致多个客户发送重复代扣。

总结：商户端和支付端两边都存在问题，异地沟通导致一些异常状态处理不对，还有就是人员短缺，基本没有做太多测试。其实还是对于支付的缺乏敬畏，再回过头看，实在是不应该，依然很难过，给客户及公司造成了很大影响，警钟长鸣。

系统异常，重复跑批代扣

问题：由于系统线程池异常，导致订单状态更新异常，重复人工执行代扣；检查历史数据又导致一个批次重复执行代扣。

总结：没有做 CodeReview ，在系统出现异常时着急去扣款，没有明确状态。特别是支付生产一定不能让开发人员操作线上数据，过度自信贻害无穷。

新上线通道交易状态异常、导致重复扣款

问题：因为渠道关闭，紧急开发新通，基本功能测试上线后就出问题。

总结：新通道紧急开发 3 天时间测试上线，开发自测上线。这是血的教训，导致问题接踵而至，我们通宵加班改数据对数据，苦不堪言。总之支付坚决杜绝不测试、无 CodeReview 就直接上线支付功能。

支付宝交易记录不存在，实际成功

问题：因为用户主动还款，但是前端查询较快，支付宝还未创建完订单数据，结果返回交易订单不存在，实际结果是支付成功。

总结：支付宝微信支付前段操作回盘结果一定要以回调结果为准，还有针对短时间查询要做控制不能时间间隔太短例如 1 - 2 秒。

渠道特殊错误码在测试阶段以及开发阶段沟通不一致导致处理状态问题，引起单边账（生产上有 4 家通道都有类似的问题）

问题：某日建设银行的代扣业务在量大时容易卡单，个别通道在文档里直接返回失败但是没有说明这个错误码不能设置失败，我们在开发和测试中也没有遇到，结果导致单边账问题一直存在。

总结：通道后方对接很多通道，他们会因为量的问题出现一些状态处理的问题引起单笔账，前期还不太好测试，开发过程中要求所有未知错误、状态码都不要设为终态，我们归为“未明状态”；

人工修改数据，导致重复发生

问题：周末线上出现问题，临时修改数据回盘，SQL 不严谨，导致执行更新数据是正常数据。

总结：这是人为操作问题，人在着急的情况下更加容易出错，越紧急，越要严谨，在执行 SQL 及其他人工操作，实施 Double Check ，流程需要规范避免此类低级问题发生。以上只是列举部分案例，市面上大家踩过的坑基本类似，这些都是我们一次次交的昂贵学费，来之不易，遇见了，解决了，更重要的时候防范于未来，防微杜渐。

行动起来

在金融支付行业，资金底线的打法是至关重要的，保证资金不发生损失是任何一家金融支付行业的第一要务，这也是最困难的一个任务之一；让我们行动起来，每一次趟坑，每一次都是阵痛，幸好兄弟们士气不减，抗压能力还算强，责任心也强，这里也表达下我对支付组兄弟们的努力和付出的感谢。

我们从行为约束、流程规范、高效运维、系统优化、业务监控等方面全面发力，痛定思痛，痛下决心，用行动死磕守住资金损失防线。

发起 1000 天零资损项目

支付宝当年初期针对频繁发生的支付事故，发起了 1000 天零资损项目；如今我们效仿也给自己立了一个“ 1000 天零资损项目”，一旦发生资损事件，计数器清零，重新开始；这个计划从“ 4.19 ”开始计算（ 2017.4.19 这一天支付发生重大支付事故，我们把这一天定义为“美利安全生产日”），深夜复盘到凌晨 3 点，我们非常焦急，不能等着系统优化了才去开展行动，前期简单粗暴多岗人肉值班监控，在没有业务监控“扁鹊”系统之前，值班人甚至肉眼盯着日志滚动。

发起资金安全零资损专项整治行动

针对过去支付体系中各环节出现的问题进行全面复盘，一步步从整体、全局、整链路去梳理我们需要做什么，有计划和节奏落地；我们深知这是个大且持久的工程，借此我们定义本次行动为：“资金安全零资损专项整治行动”，见下图：

行为约束

专岗和隔离：不要让开发人员直接碰生产，功能上线后，应该交付给专门的支付运营，过去我们出现过几次开发人员为了快速支持业务，拿着生产账号修改商户和路由参数导致生产事故；因为开发不一定了解线上真实的商户运营的路由策略和要求；我们对开发、运营、产品进行了严格的职责分工，开发线上账号权限全部上收，必须做到“懂开发的不碰线上，碰线上要不懂开发”。

着急开发不着急上线：互联网的快速迭代，对金融领域来说更多应该体现在快速开发上，而不是上线，我们需要有足够的时间去测试，确保金融数据准确，金融系统稳定，所以在我们公司有个格言：着急开发，不着急上线。

规范流程

我们更多谈支付研发路程，之前我们是简单普氏三步：开发 --> 测试 --> 上线；通过不断经验总结，现在的研发六脉：开发 --> CodeReview --> 测试 --> 产品验收 --> checklist 评审上线 --> 真钱测试；CodeReview 阶段：开发完代码自测成功后，在提交给 QA 测试之前，由研发发起代码审核，参与人员包括项目 leader 、开发、测试等，需要跑代码覆盖率、单元测试情况及现场 Review 讲解代码，我们的要求是评审必须要有问题包括代码可读性、重用、依赖、场景缺失等；CheckList 评审上线：上线前准备工作，对照检查项列表，一一核查，确保我们上线没有遗漏；真钱测试：这是非常关键一环，我们申请了专项测试资金，对新上线支付通道和路由策略，用真实交易做线上验证，确保新上线功能运行稳定；

高效运营

前面提到专岗，权限隔离，这就要求我们开发相应的高效运营系统、工具、标准化运营流程；系统上：开发了商户运营系统、支付统计报表系统等，涉及日常运营操作包括支付查询、路由配置、交易处理、商户管理、通知管理等；流程上：建立定向沟通群包括对内代扣群、代付群，对外第三方通道群，以此避免信息轰炸（之前有非常的小群，特别不利于信息聚焦，有条件的建议使用钉钉沟通），问题第一沟通方 - 支付运营人员，建立工单机制，如果需要开发介入，第二由开发值班人负责快速处理；另外必须把“客户第一”价值观放在心上，支付运营和开发值班人员 7*24 保障手机畅通，下班和节假日必须带上可工作电脑（很多同学下班后不带电话回家，导致出现问题不能及时解决），确保能够快速解决问题；

系统优化

系统上做了两次大的微服化架构迭代，按照第三方支付架构思想建立服务，保障了系统的高可用和快速业务迭代，梳理资损点，专项优化，包括：防重策略：一般叫事中拦截，是一个非常重要的避免资金损失的方案，就是在支付过程中，通过支付的特点来识别是否发生了资金底线风险，如果识别到了，则可以及时拦截，不让事情进一步恶化，分为：代扣防重：订单号防和根据公司支付业务特征防；代付防重：根据公司付款交易特征防重，比如合同放款业务，它的业务特征是有且只会给一个合同放款一次，所以我们在放款交易时会针对交易要素：合同号，金额，卡，身份证号，交易类型进行一次唯一交易核查；

对账机制：支付、渠道、商户、账务的四方校验，确保支付四方都是最终一致结果，经过这样的一轮闭环校验可以避免资金损失；

交易未明保守处理：不要过分信任第三方通道的错误码，根据经验梳理出可以肯定的成功码和失败码，对于可疑码值和网络超时情况，我们定义为“交易未明”，一定不能草率发起重试，需要系统自动通知运营人员人工与第三方核查；比如历史上我们出现过：X付通与农行通道出现问题，给我方返回错误信息“系统处理异常，请稍后重新提交”，结果我们认为支付失败了，发起重新支付，最后遭到客户大量投诉，发生重复代扣；其他还有很多，就不一一列举了。

业务监控

我们自研了“扁鹊”监控平台，我们希望这个系统能够“看病，治病，健康检查”，针对核心交易，按照报警日志格式输出，然后监控平台抽取相应的日志文件信息，通过设置相应的报警策略，一旦发现异常可通过短信、钉钉、邮件进行通知，有了这个平台后，结束了我们人肉监控历史，让我们很容易做到快速发现问题。（针对扁鹊监控更为详细的设计方案，大家稍等后续安排写作分享）

思考总结

支付虽然趟过很多坑，但每一次犯错，都是宝贵“财富”，是我们实战经验的积累，成就了美利一批支付领域专家。业绩可能只看结果，但是成长一定看过程，敢于正视自己的错误，遇见一个，解决一个，不断复盘，我们才能真正懂得“成长”。

文章中一些问题看似都很简单，为什么我们会犯呢，像人工配置的问题、随意上线及修改 master 代码等；如果我们从一开始就严格制定相关规矩，可能就可以避免或者就会降低很多线上问题的发生。人生没有如果，分享我们的错误，发起零资损行动，希望能帮助正在经历像我们当初那样的开发团队，也许就是没有高大上的技术升级，一切坑都是那样真实的发生，可能看似简单却并不容易做到；借我们支付一哥在一次分享时抛出的一句话结尾：好好学习，天天向上，真没有几个人能做到，小事不小，经历过才知道，对支付永远保持敬畏。

***

作者介绍

阿兵（郭斌），有着 10 年的金融领域研发经验，目前在美利金融担任研发 (后端)总监，负责融资平台技术团队，主要业务方向是融资、支付结算、财务核算。美利创立之初就开始加入，作为公司早期程序员，亲眼见证了美利系统建设从 0 到 1 和业务飞速发展，有幸参与中后台战略核心系统建设，在信贷业务架构和微服务架构领域中积累了丰富的实战经验。