本文作者是蚂蚁集团数据研发工程师惠勒，将马斯克五步工作法应用在了实际项目中，实现了支付宝商家账单的重构，希望本文对想要降低系统复杂度的同学或者项目有所帮助。

0. 概述

支付宝中国数据团队在过去的一年里应用马斯克的五步工作法重构了有 10 年历史之久的支付宝商家账单，整体复杂度减少 60%，时效性提升 1 小时，计存成本降低 30%，理解和运维成本大幅下降。复杂度是很多问题的根源，既会增加运维的成本，又降低了支撑业务的效率。 账单重构的经验表明，相当大比例的复杂度是没有必要的，我们应该致力于把复杂的事情变简单，而不是倒过来做“防御性编程”。希望本文对想要降低系统复杂度的同学或者项目有所帮助。

1. 重构背景

1.1 什么是商家账单

商家通过支付宝发生业务，我们对他们提供相应的流水单或者凭证，这就是商家账单。商户可以到B站下载账单和他们自己的业务记录及资金变动期望逐一比对，确认所有业务和资金都按正确的期望的方式完成了处置，这个过程称为商家对账。

支付宝目前提供了丰富账单类型，包括资金流水，交易订单，资产凭证，营销动账，费用账单以及一些列个性化定制账单。实现方式上则有在线实时账单以及基于 odps 的离线的日/月账单，其中在线账单主要用于业务查询，而离线账单则主要用于商家对账，本文所指商家账单主要指离线账单。

图1：B站里的商家账单

1.2 为什么要重构

一句话概括：历时 10 年，积重难返。

商家账单作为支付宝收单业务配套的基础产品，主要的服务对象是商家。和所有 To B 产品一样，其面临着“千人千面的个性化诉求和成本可控的快速支撑”的核心矛盾。在实现过程中，要么在原有逻辑上打个补丁，更多的时候是出于稳定性等因素考虑，不敢动原有的逻辑，于是就新起炉灶搞个新的字段。历时 10 年，资金流水账单搞出了上百个字段，很多字段的加工链路极其复杂。目前整个账单大概有几千个任务，近万的依赖关系，平均加工深度 20 多层，各种横向域之间的耦合，纵向层之间的调用层出不强，用一团乱麻来形容也不为过！

图 2：真实的账单血缘图

图 3：账单架构混乱的示意图

1.3 为什么是现在

主要是因为逻辑过于复杂，当前用于保障账单准确和出账时效的成本已经过于高昂。

离线账单是拿去对账的，这就像有上百万商家拿着放大镜在找问题一样，不仅像金额，时间等字段不能有问题，各种订单号，门店 ID 等字段也偏差不得。而当前账单过于复杂，经常出现变更了这里漏了那里，或者是改了上游影响了好几层以外的下游。目前每年流转到二线研发同学的咨询就有几百例，一线外包和马力等同学接到的账单类问题更是以万计。

时效性方面的压力则有过之而无不及。由于需要对标竞对 T+1 10 点的出账时效，支付宝目前对客承诺 T+1 9 点出账，扣减掉在线账单文件生成和预留的异常处理时间，基本上要求离线账单需要 T+1 5 点 30 产出。作为蚂蚁唯二的两条最高级基线之一，运维同学承担了极大的压力，从 2023 年 9 月-12 月，运维同学在夜间共计响应 150+ 起电话告警，涉及天数 67 天，值班起夜比例为 67/122=54.9%。虽然引发起夜的因素有集群计算资源以及 odps 软件等外部因素，但根子上还是因为加工链路太长，给基线预留的余量不够。

为了彻底解决上述问题，我们决心重构支付宝商家账单，通过降低复杂度的方式，既提升用户体验又降低运维成本。

2. 重构目标

通过降低 50% 的复杂度，达到以下 5 点业务效果

• 准确的

每个字段的含义是明确的，账单数据内部是一致的

• 高时效的

  账单产出提前 1 小时
  

• 好运维的

  重大问题能够快速一键重跑的（72h 降低到 12h 以内），日常的异常情况能够快速处理（1h以内），代码结构是好理解的（模块化的分层架构）
  

• 易扩展的

  可扩展性强，对于各种业务需求的响应速度较快，不需要对代码逻辑大幅改动。有灰度环境的全链路回归链路，减少变更风险
  

• 低成本的

  在保证回刷要求的前提下尽可能降低存储成本（降低 1/3 的存储成本），减少任务数量，降低计算成本（降低 1/3 的计算成本）
  

3. 应用五步工作法重构账单

马斯克在特斯拉和 spaceX 的成功经验告诉我们，应用五步工作法可以把复杂的事情变得简单，把高昂的成本打下来。所谓五步工作法，主要是

3.1 质疑

第一步是质疑：为什么有那么多字段，为什么每个字段有那么多逻辑，为什么加工链路需要那么长。 带着这几个为什么，我们开始做字段梳理工作，核心工作是两项

以最多商户使用的资金流水账单为例，上百个字段中仅有不到三分之一是核心字段，一半左右是个性化字段（使用商户数 100 以下），剩余大几十个都是无人使用字段；字段来源方面则集中在账务，交易，支付，计收费，结算，充转提等几个领域。从这些数字中我们得出以下两个观点

3.2 删减

带着第一步质疑的观点，我们开始做删减，以核心字段为目标，落地如下架构设计 

图4：重构的账单架构图

核心的工作有那么几项

3.3 优化

在整个账单重构过程中，有几个难点我们专门提出来成立了专项进行优化

图5：离线灰度方案

4. 稳定性自愈方案

   商家账单有几千个任务，但我们依赖的这套离线批处理的模式里又有很多不确定的因素：odps 的软件问题，底层计算集群的机器抖动，槽位占用，在线压制等，所以每个月总有那么几十个报错或者变慢的任务需要人工处理。在本次重构过程中，我们联合蚂蚁大数据部相关团队上线了报错自动重跑和变慢自愈恢复等两个稳定性自愈方案。

   报错自动重跑方案的核心是系统自动识别运行日志中的关键词，除非是明确不可重跑的报错（如数据质量问题，权限问题等），都会由调度系统拉起来重跑，实际运行过程中还需要综合考虑基线余量等要素。目前报错自动重跑方案每个月可以减少商家账单几十次的报错处理，减少 4-5 天的起夜值班。

   变慢自愈方案的核心思想是识别相关变慢任务并自动 copy 到双跑链路执行。若双跑任务执行期间原链路恢复，则不做处理；若双跑链路执行完成，原链路仍未完成，则杀死原链路任务，将双跑结果注入原表，将任务置成功。