支付宝技术风险负责人陈亮：把事情做到极致，技术的差异性才会体现出来

2019 年 6 月 12 日 蚂蚁程序猿

“很多事情，说出来很多人都在做，但是只有真正做到极致，技术的差异性才会体现出来”，蚂蚁金服技术风险部研究员陈亮（花名：俊义）在接受 InfoQ 采访时如是说道。在此前的支付宝技术嘉年华，InfoQ 对支付宝数次技术架构升级的见证者及主导架构师陈亮进行了独家采访，首次系统了解稳定支撑“双十一”等多次实战背后的支付宝技术风险体系。

支付宝技术风险体系

2007 年，陈亮加入支付宝，负责支付宝搜索及通信中间件架构。在之后的十年时间里，陈亮先后负责过支付宝交易拆分整体架构，这成为支付宝数据库拆分架构标准；支付宝三代架构单元化及容灾整体架构，实现异地多活，这成为支付宝单元化架构标准。如果简单总结在支付宝工作的前十年，陈亮表示：

前十年，我一直在做可扩展性相关的工作。

在这期间，问题和需求驱动占据上风。陈亮回忆道：“最初的支付宝是单体架构，一个小型机加两个 Java 写的 APP，那年 DBA 就找过来说如果不进行数据库拆分，很难扛住业务发展”。

经过系列改造，这一工作终于完成。当时，陈亮以为这个架构起码可以支撑支付宝未来五到十年的发展。然而，双十一很快就来了，超大规模瞬时流量的冲击对架构提出了全新挑战，整个团队又开始马不停蹄地进行异地多活相关项目研发。

彼时，支付宝有两个主要应对技术风险的团队，一个叫技术质量团队，另一个则是运维团队。技术质量主要是各种功能测试，并解决程序 Bug、故障等问题；运维团队主要是生产偏基础设施以及应用、DB 运维管理保障，同时也会自发性地做一些技术风险相关的事情，但并未形成体系化的技术风险组织阵型及打法。

2013 年，支付宝技术团队提出质量 2.0 战略，其目的是希望在技术风险领域有一些延展，体系化沉淀 Bug 检测等方面的能力。自此，支付宝的技术风险体系建设逐渐步入正轨。

组织架构演进

2014 年，质量技术部成立希望从全域视角解决技术风险问题。但是，质量技术部并没有运维团队，主要就是通用质量检测和高可用保障相关的技术解决方案，并驱动各业务部门的技术团队落地。当时，质量技术部人员并不多，是一个小而精悍的中台部门。

经过一年多的发展，质量技术部发现仅仅依靠质量技术并不能解决生产上的各种故障风险。虽然，质量技术部会关注生产研发过程，但主要精力在于对各业务技术团队输出技术风险，比如高可用及通用质量检测的解决方案，高可用及资金保障方面尚未出现成型的平台体系。虽然当时的全链路压测和持续集成平台已有所成型，但关于高可用等并没有成型的平台。

当时，技术团队判断，不能只从质量角度看风险，而需要从更高的维度和更全面的视角看待风险。2015 年，质量技术部升级为技术风险部，专注研发及架构技术风险问题，做相应的解决方案和落地平台。

2016 年，陈亮一手打造了支付宝的 SRE（Site Risk Engineer，参考谷歌的 Site Reliability Engineer）体系。技术风险部增加 PE 和 DBA 团队，PE 团队直接对生产环节中的运营、操作等做技术风险防控，整个大团队的职能属于 SRE。据了解，这也是国内第一个 SRE 团队。

陈亮发现，传统的运维思路和文化已经无法彻底解决支付宝的稳定性问题，因此需要成立 SRE 团队。事实上，传统的运维方式侧重于靠人肉解决风险，不管是调参还是更改配置，都无法从本质上解决支付宝的稳定性问题，相反会让运维人员的工作成就感很低。说到底，运维领域的问题终究还是软件问题，需要建立软件平台更好地管理风险。

在组建 SRE 团队的过程中，陈亮认为最难的反而不是技术层面的推进，而是让团队工程师，包括整个公司认同 SRE 的价值，这需要让所有人理解 SRE 可以解决哪些新的问题以及传统的思维方式为何不可取。

据了解，支付宝的 SRE 团队主要由研发、运维和测试人员组成，八成运维人员都需要写稳定性相关的代码。团队组建完成即全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中，防抖要保证任何网络或基础设施抖动，用户都无感知；精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。

2016 年，SRE 团队建设了很多平台和能力。同时，技术团队发现了两个极为重要的现象，一是生产故障不是必然的，通常都是偶然性的；二是生产故障是低频的。这带来的问题就是故障样本很少，没有办法证明在真实故障到来时平台是否具备能力应对。也就是说，SRE 团队建设的防御系统的可靠性，无法充分验证。

2017 年，SRE 团队成立了专门的、独立职能的技术蓝军，其主要的工作就是发掘防御系统的弱点并发起真实的攻击。技术蓝军并不对各业务方负责，只对这套防御系统的稳定性和可靠性负责。

在技术蓝军看来，发生故障是必然的，只是时间早晚而已，技术蓝军会想尽办法触发这些故障，以保障在故障真实发生时，团队有足够的应付能力。目前，全栈级的技术攻防演练每周都在进行，而故障防御系统及不断优化的高可用架构则是由 SRE 团队的红军与各业务深度合作，沉淀、构建出来的。

发展至今，陈亮表示，支付宝技术风险团队的主要工作其实就两件事情：一是保障支付宝生产环境的稳定性；二是保障互联网金融系统的资金零差错。目标非常明确，但如何解决问题并为之规划可行途径是不简单的。

技术演进

四年前，我们最初只敢做故障定位，现在真的是在做演练。

回顾整个过程技术实力的变化，陈亮表示支付宝的攻防演练是技术演进的缩影。至今，攻防演练已经进行了四届，时间也从一天拉长至四天。

起初，陈亮介绍，攻防演练主要针对容灾方向，虽然也会做一些线上的断网演练，但当时的体系还不具备直接在线上进行稳定性演练的条件，主要是范围很窄的故障定位。第二年，团队构建了新的基础设施——灰度环境，该环境与生产环境完全隔离，但可以引入环境流量进行生产验证。同时，该环境具备 24 小时压测流量，团队可以在各个环境下进行稳定性攻防，并要求在十分钟内恢复稳态，此时已经从只敢做定位变成真正做演练。

如今，攻防演练的时间已经拉长至四天，支付宝技术风险团队会在虚拟环境演练整体的故障恢复能力。通过 AIOps 和 TRaaS，整个团队的目标已经变成五分钟内自愈，最新的攻防数据显示已有近八成业务通过自愈恢复。更为复杂的容灾演练也从一年 12 次演变为百余次，容灾成功率从 50% 提升至 90%。在这个过程中，支付宝沉淀了很多与技术风险相关的能力，以下将简单介绍 AIOps 和 TRaaS 两个维度。

支付宝技术风控平台 TRaaS

过去，我们对新技术的接受和采纳程度一直很高，但可能缺少分享。如今，我们将整套攻防演练沉淀下来的风控体系对外开放。

去年，在杭州的蚂蚁金服 ATEC 科技大会上，支付宝正式推出技术风险防控平台 TRaaS（Technological Risk-defense as a Service）。经历过无数考验的 TRaaS 是把支付宝整个分布式架构和技术风险能力组合在一起的免疫系统，将高可用和资金安全能力结合 AIOps，使系统实现故障自愈，具有免疫能力。

之所以决定开放整套由攻防演练沉淀下来的风险平台，陈亮表示，这在一定程度上受到支付宝开放战略的驱动。过去，支付宝曾将中间件、PaaS 平台等开放给客户。其次，对金融领域的用户而言，稳定性需求真实存在，且一直没有特别好的解决方案，支付宝愿意将数年积累的技术能力产品化并对外提供。

简单来说，TRaaS 具备三大特性：高达 99.999% 的高可用性；千亿级资金秒级实时核对；5 分钟发现，5 分钟自愈的免疫能力。

首先，依靠支付宝的三地五中心异地多活容灾架构及全链路压测的考验，TRaaS 最终实现了高达 99.999% 的高可用性，即极高可用性，也就是说系统年度停机时间将不超过 5 分钟。

其次，作为 TRaaS 平台负责人，陈亮回忆道，在整个资金防控体系的演进过程中，支付宝最初与众多银行一样，靠人力进行对账。之后通过自动化的方式将全量数据库表导出后做计算来进行核对。后来，业务量更大，就引入了 T+H，核对时间也从天变到小时级，并在此过程中增加了异常管理。最后演进到实时业务核对，增加了熔断决策、资金免疫以及智能监控等方面的功能，从而形成了 TRaaS 强大的千亿级资金秒级核对能力。

最后，TRaaS 集成了支付宝在 AIOps 层面的探索。

AIOps

如前文所言，自愈是支付宝 AIOps 方向的重要探索。目前，自愈的恢复能力控制在 5 分钟左右。随着 AI 算法的不断优化，陈亮认为，这一时间未来有望继续缩短。陈亮表示，在系统建设的过程中，AI 算法肯定发挥了较好作用，但通过 AI 实现自愈可能会局限于某些场景，这就需要借助 SRE 的能力用软件工程的方法建模。支付宝也会通过 AI 的方式实现根因定位、告警处理等功能。

采访中，陈亮提及，AI 在 DevOps 领域最大的价值可以概括为提升效率和扩展边界。一方面，通过历史监控数据对模型进行训练，AI 可以辅助工程师进行业务监控，进而提高监控效率；另一方面，AI 有效提高了监控点的配置数量，覆盖的业务范围更广，这是依靠现有人力很难实现的。

支付宝的生产环境非常复杂，要想实现 AIOps，最大的技术挑战源于超高规模的数据并发，技术风险团队想要实现业务高可用就需要找到造成某种故障的全部可能原因，比如造成付款下跌的全部原因，该过程在内部被称为“找分母”，AI 在这一阶段发挥了重要作用。

以资金安全为例，对于同一笔业务，SOA 架构的上下游会出现两张表，而表单中同一笔订单的金额必须保持一致。当表单数据足够多，就意味着可供训练的样本数量足够庞大，此时可以通过 AI 的方式找出每笔金额不一致交易的故障原因，进而不断完善该故障的“分母”。

对于 TRaaS 平台的未来规划，陈亮表示，在条件成熟且允许的情况下，TRaaS 平台会集成支付宝技术风险团队在攻防领域的全部能力，包括灰度架构、演练平台、自愈平台、报警处理平台及变更平台等。

未来规划

未来，技术风险防控体系将具备更多智能特性，尽量减少人工干预，最好的情况是实现无人值守。陈亮透露，这将是整个团队未来至少两年内的主打方向——让所有变更无人值守。当然，无人值守很简单，关键是风险控制能力要上去。

在支付宝技术风险能力的构建过程中，陈亮坦言，未来希望将技术风险和 AI 的能力云原生化，并将其与 Service Mesh 相结合，让业务专注研发业务代码，其他的全部交给云。