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

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

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

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

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

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

推荐阅读