支付宝技术力养成记

钟啸灵

支付宝的每一个产品背后，离不开IT团队的有力支撑，他们如何铸就这种技术能力？

余额宝从来不缺话题，纵然外面“吵得天翻地覆”，在阿里小微金融服务集团（以下简称“小微金服”，支付宝的母公司）内部，技术高层却一如既往地低调。

在杭州黄龙时代广场B座，小微金服的总部，首席架构师程立近年来第一次打破沉默。

虽然程立不是支付宝创始的3个人之一，但他见证了支付宝技术团队从20人增加到如今的1000多人（占支付宝总人数的1/3以上）。在这段岁月里，程立不但参与和推动了公司内部三代技术架构平台的更迭，也亲历了各式各样的产品的成功与失败。在程立看来，互联网金融产品成功的关键点在于用户价值，“产品背后的价值分析可能会非常复杂，但是用户价值必须非常清晰，明眼人可以一眼看穿”。

为了打磨这些有价值的产品，支付宝需要沉淀一定的技术支持力量。在经历了一系列平台和产品的演进后，支付宝的技术团队逐步建立了具有自己特色的管理模式。

看清目标摸石头过河

作为一家纯互联网公司，支付宝的技术团队从一开始就以互联网创新方式进行运作，在这里，传统的IT组织结构被抛弃，更强调效率的网状的协同组织架构是主角。在这里，平台技术部负责共享平台和基础技术，与专业的技术团队和业务团队一起进行业务创新。拿余额宝来说，它的项目团队由理财技术部、平台技术部和其他业务的技术部组成，同时会成立一个10人左右的专业委员会负责跟进每个子项目。项目团队的负责人主要负责整体架构以及管理项目的推进情况，激发大家对下一个产品的想象。“我们对团队进行更分散的设置，让技术和业务结合更紧密，更快地推动业务。”程立说，“不过，技术平台的稳定性、团队整体的协同性并没有任何减弱”。

一个项目成立开始并不意味着一定会成功，有的项目甚至没机会推出市场，或者推出市场后便悄然无声。“每年技术团队内部都有产品规划和重点产品，但是失败的产品比成功的产品多得多。”程立表示。

支付宝一直努力建立自己的信用体系，2008年左右也尝试过推出一个支付宝用户的信用评分体系，不过当时的产品遭遇滑铁卢。后来，技术部门通过沉淀的信用数据进行挖掘应用，促成阿里小贷的成立。“我们的方式是，看清楚目标，接下来每一步摸着石头过河，不断地在业务上试错。”程立表示。

这样的情形不断上演，“今天人们看到的都是余额宝的成功，却不知道余额宝之前有过很多不成功的产品。”程立感叹。早在几年前支付宝便希望进入理财领域，当时曾推出基金支付，希望支付宝用户可以通过支付宝购买基金，不过这个产品推出后一直不温不火，要么产品由于各种原因无法开放给用户使用，要么上线后客户不认可没有用户量。这样的情况一直持续到余额宝的推出。“从用户的体验和用户价值看，一个非常复杂的产品往往不会成功，它必须足够简单，富有价值感。”

为了推动持续不断的创新，支付宝的管理团队每年、每半年、每季度都会进行头脑风暴。同时会在一段时间内举行“敢问系列”会议，探讨“我们有没有将服务能力发挥出来，风控能力是否能为客户提供价值”。此时，所有的技术专家和管理层会聚在一起进行各种形式的讨论。这样的碰撞也可能来自平时技术人员三言两语聊天聊出来的点子，比如，核心数据库的秒级故障切换技术就源于一次团队外出两位技术人员的闲聊，回来后这个想法迅速被论证、认可与并予以实施。而海量秒级监控平台则是一位大学毕业不久的工程师鼓捣出来的玩意儿，这些都成为高可用支付平台的关键支撑技术。这些点子的价值一旦被证实，便会迅速通过技术实现和推出。

虽然整个技术团队的工作方式是纯互联网式的，不过面对具有金融属性的产品，他们在内部则会奉行稳健的金融思维——更关注产品的安全、合规和稳定。当一项设想实现后，产品经理会看产品体验是否足够好，而风险团队会关注安全性，合规团队会看是否符合法规，而架构团队则关注设计是否会破坏整体架构。“团队内部会有竞争，会讲求快速创新，但又关注协同，关注严谨，这是内部的一种文化。”程立表示，“这个过程会有一些冲突但我们尽量进行平衡，并对产品做不断调整”。

为了保证内部技术团队的持续创新力，支付宝在构建完整的培养机制。除了设立支付宝大学培训机构，还采用师傅“传帮带”徒弟的方式培养技术人员。2013年，技术团队做了一个“名师出高徒”的评选，选拔了小微技术领域最拔尖的6位专家，每个专家会6名徒弟组成一个研究小组，探索前沿的创新应用。与此同时，支付宝也会在世界范围内寻求技术人才，以扩大前沿技术的探索。

不断被考验的架构

在程立看来，正是有了目前的架构支撑，支付宝从支付到金融走得很轻松。

支付宝的架构能力已经得到业内认可。从成立至今，支付宝经历了三代的架构更迭。最初一批技术人员来自淘宝网，比较互联网化，不过他们被要求不仅要像互联网那样快速拥抱变化，还要有金融意识，讲求安全和严谨。

最初他们只服务于淘宝网，仅提供担保交易和支付功能。到了2005年，随着市场变化团队的定位也在转变——不仅服务于淘宝网，还要服务整个互联网的电子商务支付。为此支付宝进行了两项调整，一是将支付宝平台从淘宝网独立出来；二是向互联网平台开放支付宝的支付与账户体系。随着向各个行业的渗透越来越深入，技术团队不但要为每个行业定制更有针对性的解决方案，还需要设计一些通用的应用满足客户的普遍需求。在刚开始的阶段，他们每遇到一项业务需求，便开发一个应用程序提供支撑。不过随着时间的推移，整个支付宝的系统逐渐由一堆互不关联的应用构成，随着系统规模的扩展，各项应用之间存在大量的重复功能开发。

这种情况到在2010年被打破，在当年的“双十一”大促那天，系统处理了3000多万笔交易，系统的处理能力瞬间被撑大到平时的3倍以上，架构能力被发挥到了极致。程立清楚地记得“那是一个非常非常非常惊险的一天”。凌晨第一个高峰飙起来后，各种各样的问题潮水般涌向技术人员，所有人处于一个精神高度紧绷的状态，在大促快结束时，有一个数据库只有30秒的挽救时间，当时他们做了一个重要决策挽救了这个数据库。

在回忆那个惊险一天时，程立清楚记得，大促之后，大家非常兴奋地庆祝，并把香槟洒在每个人身上。更让程立记忆犹新的是，那一场大战让他们意识到当时的架构到了负荷极限，得想办法往下走。

回溯过往，技术团队已经经历了第一代烟囱式的架构、第二代SOA架构，现在开始了第三代的云支付平台。此时，技术团队的架构构建能力已经非常熟练，只用了不到半年时间制定一个长达三年的前瞻性架构规划，通过对架构进行划分和分解，由若干项目群进行持续三年的运作，最终在2013年成功构建成云支付架构。2013年的“双十一”大促，这个架构从2010年仅能支撑3000多万笔，提升到可以应对1.88亿笔交易，正式宣告了第三代架构的封顶工作已经完成。而“双十一”也成为技术团队检验和提升架构的能力的重大机会。

在第三代架构支撑下的支付宝系统也成为了一个“永动机”。此前，在第二代架构时代，每年支付宝会在凌晨停机几次，将停机需要做的升级等事情在8小时内集中完成。但是第三代不再存在这个障碍，技术团队将系统进行分布化设计，如果不是人为操作失误，任何故障都可以做到分钟级的快速切换。

为了持续提升技术团队在系统上的技术能力，技术团队每年会制定一个与业务愿景相匹配的愿景。对于第三代架构，技术团队希望建立一个亿级金融平台，如果具体分解到每一年的目标中，2013年技术团队的目标是1234，1是打造一个统一共享的金融业务核心，2是聚焦海量数据处理能力和云服务平台。3是达到每秒30000笔支付的目标，4则代表小微金服系统99.99%的可用率目标，这些也都一一达成。

未来技术团队将继续针对互联网金融进行技术攻，程立希望，通过互联网的方式降低用户使用金融服务的门槛，同时继续加强平台和产品的风险管理能力。