支付宝技术风险体系建设历程
极客时间编辑部
讲述：丁婵大小：2.43M时长：05:19
日前，蚂蚁金服技术风险部研究员陈亮（花名：俊义）接受 InfoQ 采访时，透露了其稳定支撑“双十一”等多次实战背后的支付宝技术风险体系。
陈亮谈到，2013 年，支付宝技术团队希望在技术风险领域有一些延展，体系化沉淀 Bug 检测等方面的能力。自此，支付宝的技术风险体系建设才逐渐步入正轨。而在此之前，支付宝有两个主要应对技术风险的团队，一个是技术质量团队，负责各种功能测试，并解决程序 Bug、故障等问题。另一个则是运维团队，主要生产偏基础设施以及应用、DB 运维管理保障，当时并没有完整的技术风险组织阵型及打法。
2014 年，质量技术部成立，这个小而精悍的中台部门希望从全域视角解决技术风险问题。但是，质量技术部并没有运维团队，主要就是通用质量检测和高可用保障相关的技术解决方案，并驱动各业务部门的技术团队落地。随后质量技术部发现仅仅依靠质量技术并不能解决生产上的各种故障风险，应该从更高的维度和更全面的视角看待风险。紧接着，质量技术部在 2015 年升级为技术风险部，专注研发及架构技术风险问题，做相应的解决方案和落地平台。
2016 年，陈亮一手打造了支付宝的 SRE（Site Risk Engineer，参考谷歌的Site Reliability Engineer）体系。技术风险部增加 PE 和 DBA 团队，PE 团队直接对生产环节中的运营、操作等做技术风险防控，整个大团队的职能属于 SRE。
据了解，这也是国内第一个 SRE 团队，主要由研发、运维和测试人员组成，其中八成运维人员都需要写稳定性相关的代码。团队组建完成后就全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。防抖就是要保证任何网络或基础设施抖动，用户都无感知，精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。
SRE 团队建设了很多平台和能力。同时，技术团队发现了两个极为重要的现象，一是生产故障不是必然的，通常都是偶然性的；二是生产故障是低频的。这带来的问题就是故障样本很少，没有办法证明在真实故障到来时平台是否具备能力应对。也就是说，SRE 团队建设的防御系统的可靠性，无法充分验证。
这也是 SRE 团队技术蓝军出现的原因，其主要的工作就是发掘防御系统的弱点并发起真实的攻击。技术蓝军并不对各业务方负责，只对这套防御系统的稳定性和可靠性负责。他们会想尽办法触发故障，以保障在故障真实发生时，团队有足够的应付能力。目前，全栈级的技术攻防演练每周都在进行，而故障防御系统及不断优化的高可用架构则是由 SRE 团队的红军与各业务深度合作，沉淀、构建出来的。
发展至今，陈亮表示，支付宝技术风险团队的主要工作其实就两件事情：一是保障支付宝生产环境的稳定性；二是保障互联网金融系统的资金零差错。目标非常明确，但如何解决问题并为之规划可行途径是不简单的。
回顾整个过程技术实力的变化，陈亮表示支付宝的攻防演练是技术演进的缩影。至今，攻防演练已经进行了四届，时间也从一天拉长至四天。攻防演练从最初主要针对容灾方向，到如今会在虚拟环境演练整体的故障恢复能力。通过 AIOps 和 TRaaS，整个团队的目标已经变成五分钟内自愈，最新的攻防数据显示已有近八成业务通过自愈恢复。更为复杂的容灾演练也从一年 12 次演变为百余次，容灾成功率从 50% 提升至 90%。在这个过程中，支付宝沉淀了很多与技术风险相关的能力。
未来，技术风险防控体系将具备更多智能特性，陈亮透露，整个团队至少两年内的主打方向是让所有变更无人值守。当然，无人值守很简单，关键是风险控制能力要上去。在支付宝技术风险能力的构建过程中，陈亮坦言，未来希望将技术风险和 AI 的能力云原生化，并将其与Service Mesh相结合，让业务专注研发业务代码，其他的全部交给云。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
加菲猫大部分系统都应该建立技术风险体系
收起评论