揭秘:技术风险如何保障支付宝的稳定性?

简介: 支付宝有一个“疯起来连自己都打”的项目,现在,它要招募应届生了!这是一个什么样的项目?它需要什么样的应届生?别着急,让我一一道来。

就现在!蚂蚁「校招季」重磅来袭!除了介绍蚂蚁的技术大咖,我们还邀请了一些通过校招来到蚂蚁的过来人分享他们的通关经验和心得,这里随时可能有行业技术大咖和你的直系学长学姐出没哦~ 「校招季」栏目会持续输出有关“蚂蚁校招”的丰富内容,敬请期待!

之前,我们介绍过支付宝有一个“疯起来连自己都打”的项目,现在,它要招募应届生了!

这是一个什么样的项目?它需要什么样的应届生?别着急,让我一一道来。

“疯起来连自己的都打”的项目

如果一个技术团队不干别的,专门“搞破坏”,这是一种怎样的存在?这真的不是“天方夜谭”,在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻,而防守方则是技术红军。

蓝军自诞生之日起就带有浓厚的神秘色彩,办公室大门总是紧闭,因为白板上不定时更新着每天攻击的红军队伍,以及发起攻击的时间,这是演习中需要严格保密的关键情报。

“像是以一己之力对抗整个蚂蚁金服的技术人员。”在蓝军眼中,故障必然会发生,只是时间早晚而已,所以只能想尽办法去触发这些故障,这样,在故障真实发生的时候,才有足够的应付能力。

技术攻防演练每周都在进行,除了每年6月初的“期中考试”周,12月第三个星期为年度技术“期末考试”周,技术蓝军随时都会组织突袭攻击“测验”,通过实战中发掘出来的脆弱点牵引红军进行能力升级。

蓝军正在研究突袭计划

在线、实时、随地、无差别、突袭……蓝军的攻击总让人防不胜防。

2018年年中,蓝军在周末发起突袭,刚好红军的一位同学正在举办婚礼,为了不影响新郎迎娶新娘,由红军组成的程序员伴郎团纷纷从包里掏出电脑,蹲坐在角落里,噼里啪啦敲着键盘进行修复。

作为报复,红军也祭出了“尖端武器”——自适应容灾、防抖(保证任何网络或基础设施抖动,用户都无感知)等系统,这让蓝军吃尽苦头,几乎每一记攻击都像打在棉花上,毫无作用。

除了设计缜密的防御措施防止蓝军的袭击,拜关公求庇佑也是红军的“习俗”。

为了确保挫败蓝军的突袭,红军除了在防御系统上下足功夫,还会在每年期中和期末的攻防演练前举办仪式——拜关公,除了叩拜,还得摆上旺仔牛奶、格子衬衫、键盘、香烟等贡品。

在支付宝,蓝军从属于蚂蚁金服技术风险部(SRE),而红军则包括SRE及各业务部门的技术团队。除了红蓝攻防,技术风险团队还做些什么呢?

技术风险都做些什么

支付宝的线上系统极其复杂,每一笔交易背后是数亿行代码、成百上千个系统,经过无数的链路,再加上海量线上实时交易,谁也无法预测下一秒是否会出现什么样的问题。如何消除人们的焦虑呢?这时就轮到技术风险团队登场了。

技术风险工作就是使用技术手段,把各种软件、硬件、人为引入的可能出现业务受损的的风险降到最低。在支付宝,它服务于从基础设施到上层应用的所有系统,从写第一行代码到最终上线的整个研发流程。

目前,技术风险工作主要由SRE来承接,日常的工作包括变更风险防御、快速应急、红蓝攻防、资金安全等,同时像双11大促,春节红包等高并发高性能的场景是技术风险工作的大考。

SRE是 Site Risk Engineering 的缩写,主要工作是围绕线上风险问题,研发技术架构和解决方案,去解决各种各样的风险问题。

变更指的是代码上线到实际生产环境的过程,我们需要围绕变更建立各种技术手段,减少变更导致的故障,研发变更相应的平台。据统计,80%的系统生产故障都来自于代码变更,因此无论怎么重视也不为过。支付宝建立了一系列制度保证系统内的任何变更都符合可监控、可灰度、可回滚的“三板斧”要求。

而一旦线上真的出现了问题,就涉及到应急机制了。支付宝有一套完善的线上应急流程,包括怎么快速定位问题,以及一个数据智能化的监控系统,可以迅速从线上海量业务中找出风险异常点。一旦发现任何问题就发出告警通知相应的同学,进行相应的流程进行解决。

平时没有故障的时候做什么呢?就是开头提到的红蓝攻防了。蓝军从第三方角度发掘各类脆弱点,并通过红蓝军技术攻防演练,不断验证防御系统的可靠性。每年的大演练时刻,都会进行全公司的动员,两边排兵布阵,攻守异常激烈。

在“期末考试”中,每支红军在被攻击后,花费多长时间发现故障,又用了多长时间恢复等都会被视作评定指标,而结果会根据“无损”攻防体系相匹配的度量平台,对攻防结果进行排名。

去年“期末考试”冠军得主是红一支付宝军,支付宝资深技术专家兼军长李铮提到,去年12月21日的红蓝大军颁奖仪式上,第一名获得了一副金算盘,以及关公铜像一年所有权,而今年还给最后一名准备了特别“奖品”——一副烂算盘,“真的是很烂的算盘,也就淘宝上才能买到。”

除此之外,资金安全是专门保护支付宝里的资金的系统,在海量线上资金处理时,要保证一分钱资金都不出问题,需要的是海量数据计算和风险挖掘能力。

技术风险的未来:喝着红酒过大促

2018年杭州云栖大会ATEC峰会,时任蚂蚁金服副CTO胡喜在现场2000多人的注视下做了一场技术演示,杭州两个数据中心的服务器网线被人为剪断,在40%服务器突然无法工作的情况下,系统只用了26秒便恢复正常,这次演示展现了蚂蚁金服“三地五中心”架构的容灾能力,也是蚂蚁金融科技开放的技术解决方案之一。

这已经很了不起,不过,和技术风险团队对未来的畅想相比,还有不少距离。

当前,支付宝正在向云原生架构转型,作为守门员的技术风险团队面临着巨大的挑战。这些挑战包括:产品需求变更频繁、软件开发速度也越来越快,这个过程中带来风险的可能性和频率也越来越高;基础架构的迁移要求系统进行全面的测试,带来了巨大的测试工作量;原有的技术风险基础设施和中台部分系统不适应云原生架构,需要重新研发。

不过,李铮表示,挑战同时也意味着机遇,云原生化将给技术风险带来巨大的技术红利。

以双十一大促场景为例,双十一是支付宝创新技术的演练场,每年最先进的技术都会在双十一的舞台上亮相,在2019年双十一大促中,诸多云原生技术就第一次登上舞台。每年双十一的峰值越来越高,而我们的追求是保证效率进一步提升,成本进一步下降。利用云原生技术可以做到更快速的弹性伸缩,在几分钟之内就能完成扩容和拉起服务,这在以前是难以做到的。

随着云原生技术的进一步深化,我们可以畅想,未来双十一保障会变成一件非常轻松的事情。利用如Serverless等技术,做到快速和自动化调度,不需要人的参与,就可以扛住双十一的峰值,实现以前 “喝着红酒过大促” 的梦想。

而要实现这些,关键就是把技术风险能力云原生化,包含三个部分:从云自身看,要对云上技术和变更的完全可控;从技术风险角度看,需要统一技术的数据资产为技术风险服务;从云服务的业务角度看,技术风险功能需要内置,业务系统不用研发甚至不感知就能具备能力。

除了云原生之外,技术风险的另一个发展趋势就是数据化和智能化。

数据智能在技术风险领域可以起到非常大的作用,概括来谈,可以分为提升效率和扩展边界。一方面,通过历史日志和监控数据对模型进行训练,AI 可以自动化一些需要人工的作业流程,比如错误聚类,根因分析,还可以根据历史数据进行预测,比如智能容量评估;另一方面,AI 可以同时进行的任务远远超过人工,覆盖的业务范围更广,可以做到以前人工做不到的事情,比如故障自愈。

未来,技术风险防控体系将具备更多智能特性,尽量减少人工干预,最好的情况是实现无人值守,由智能化的风险系统来应对各种风险场景,完成全局最佳的风险决策。这将是整个团队的努力方向——让大促和所有变更无人值守。

寄语应届生:什么样的人适合做技术风险

技术风险团队正在面向广大高校招募应届生,李铮也分享了他认为一个优秀的候选人所需要具备的素质。

首先,要想在技术风险领域有所作为,需要对技术本身非常感兴趣,要灵活运用各种新技术手段去应对各种风险,而风险很多时候都涉及到技术深层次的原因,只有耐下心来掌握其中的原理才能快速解决。

其次是需要有解决问题的能力。因为线上发生的问题可能千奇百怪,你需要去定义问题,然后用创新思维去解决问题,需要思考如何定义风险架构,体系化系统化的把问题根治。

还有一点是主动性,很多人看到风险会有点抗拒,有点往后退,不太愿意面对风险,但技术风险团队的工作就是要直面风险,与风险同行。遇到问题要么自己解决,要么找到其他人配合一起解决,需要这种主动担当的能力,遇到风险能挺身而出,解决危机。

最后是快速学习、快速掌握技能的能力。像上面提到的云原生、数据智能等,如今技术风险领域新的技术层出不穷,像以前一样靠一项技术吃老本是不行的,必须拥抱变化,时刻准备着学习新的技能。

最后,祝愿大家都能找到自己理想的工作~

加入SRE团队

团队介绍:

SRE(Site Risk Engineering)是结合传统软件工程与系统运维形成的新的技术体系,用以组建大规模高可用的分布式系统。蚂蚁SRE团队的使命在于确保业务在快速演进的同时,具备高可用性以及扩展性,规避资金安全、稳定性等线上故障,完成高可用、高并发的技术挑战。

负责蚂蚁金服技术风险业务和平台研发工作,工作包括稳定性、容量、故障自愈、AIOps等方向,构建各种高可用平台系统解决蚂蚁金服核心业务的金融级稳定性挑战,和"双11”级别的高并发巅峰挑战,解决世界级的分布式处理难题,进行相关技术攻关,识别和解决潜在的技术风险。而与你并肩的, 是蚂蚁金服经验丰富的工程师。这里学习,成长,上升潜力巨大。

工作地点:

杭州、上海、北京、成都

岗位要求:

1. 面向2020年11月-2021年10月期间毕业的同学;

2. 具备扎实的Java编程基础。对常见开发框架,如Spring、MyBatis等有深入了解,有中间件框架开发经验或相关开源项目贡献者优先;

3. 熟悉微服务架构、分布式系统原理,有分布式系统研发经验者优先;

4. 有python/go,docker,系统运维等相关技术经验者优先,熟悉serverless、AIOps等技术的优先;

5. 有良好的表达和沟通能力,善于学习,关注前沿,能利用创新手段解决问题者优先。

简历投递:

zheng.lz@antfin.com

相关文章
|
数据采集 监控 安全
优酷质量保障系列(一)—服务端稳定性保障实践
质量保障贯穿全部研发流程,测试作为质量的构建者和守护者,需要保障的不仅仅是提测后的功能质量,而是整个研发过程的质量和效率。分享优酷通过质量保障建设提升研发效率和质量的实践过程。
795 0
优酷质量保障系列(一)—服务端稳定性保障实践
|
存储 运维 Prometheus
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.1监控预警体系建设
299 0
|
7月前
|
缓存 运维 监控
|
运维 监控 测试技术
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(4)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(4)
167 0
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(4)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.4故障演练与紧急预案设计
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.4故障演练与紧急预案设计
202 0
|
监控 测试技术 UED
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
303 0
|
SQL 监控 关系型数据库
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
206 0
|
域名解析 网络协议 数据可视化
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
214 0
|
弹性计算 运维 监控
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(2)
206 0
|
弹性计算 运维 安全
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.1 游戏业务稳定性保障——5.1.1新游上线稳定性保障实践(1)
248 0