很难想象,1992年出生的郑洋飞已经是云原生性能容量团队 Leader、2018年双十一稳定性总负责人,2020年双11的副队长。连续6年双十一,不仅是他带领团队的练兵场,更能从中看到蚂蚁集团技术演进的轨迹。
我问郑洋飞:“进入蚂蚁以来,你觉得做得最好、最值得吹嘘的一件事是什么?”
我本希望从他口中听到双十一“买买买”的热闹红火、以一己之力保障13亿订单量的豪情壮志。但眼前这个青年抓抓脑袋,说了一个陌生的词语:“应该是我接下来做的这个云原生容量技术吧。”
“我是第五个挑战这个技术的人,很多前辈都失败了,但我觉得我能做成。”
抛下从前的光环,郑洋飞急着奔赴下一站。技术之路无穷无尽,蚂蚁集团站在千万人搭起的台基上,准备攀越新的高山。
2013年,实习生郑洋飞还在给服务器做“人肉扩缩容”的琐碎工作。
2015年,他已经被拉上双十一前线,跟主管签下“对赌协议”,负责整个双十一全链路压测的稳定性。从默默无闻的参与者到项目主导者,郑洋飞的视野豁然洞开。
身为90后,这是郑洋飞第一次独挑大梁。
时局艰辛,祸不单行。由于上半年故障问题高发,整个稳定性团队正值士气低落,质疑声接连不断,全团队都憋着一口气。郑洋飞直言:“就是要给蚂蚁争口气,不能让人觉得我们不行。”
少年冲阵斩将,闯入“光明顶”。郑洋飞回忆说,当时光明顶(双十一全链路压测现场)留给支付宝团队的位置很少,阿里经济体大促负责人在现场举着大喇叭,一有问题就声震云霄:“支付宝怎么了?支付宝怎么又跌啦?”
郑洋飞屏息凝神,应对一切,**“在那个会议室里你得处理任何事情,什么情况你都要能 cover 住。”**这时哪还顾得上什么 KPI、什么对赌协议,只要压测曲线一抖动,全团队的心都跟着抖动。
但最终,他们扛住了。当双十一0点的流量洪峰扑面涌来,支付宝顶住了压力,郑洋飞从主管手中接过了自己赢得的赌注:一只 Apple Watch。
**线上购物节的狂欢爆发了,时代的车轮在悄无声息中前进。**跟前一年相比,2015年双十一的全链路压测在几个方面做了大刀阔斧的改进:一是从核心系统扩展到全部系统,二是和整个集团的压测打通联动,三是平台化,也就是打造一个全链路压测的平台工具,将技术人员的一部分工作交付给平台。
此后几年里,全链路压测技术一路演进,从“大促”走向常态和产品化,随着技术的沉淀、对业务理解的加深,郑洋飞的职责也从双十一压测负责人逐渐扩大为双十一稳定性负责人。这几年大促活动的压测工作,用他的话说,“游刃有余,丝般顺滑”。
与此同时,越来越多的技术被融合到平台里。随着连续诞生的大促中控平台、巡检平台、变更核心、限流平台、预案等平台,一线的纯技术保障人员逐年减少,大促技术团队得以解放双手,去攻关更具有技术难度的问题。
“大促要朝着无人驾驶的方向发展”,这是所有双十一参与者的愿景。
一度被称为“压测小王子”的郑洋飞说,大促保障技术的关键点之一,就是容量评估。
换句话说,也就是如何用最低的成本、最快的效率,保证双十一大促的稳定性。随着这类促销活动的常态化,日常流量的突增时时可见,无形中带来了很多容量和稳定性问题。
低成本,快效率,高稳定,围绕着这些目标,郑洋飞和团队在这些年一步步把大促保障技术沉淀下来,打造了多种多样的平台工具。现在横亘在团队面前的,是一个更陌生、难度更高的领域:云原生容量。
**云原生容量技术的作用,正是根据历史趋势和实时预测,计算出每个应用应该合理使用多少资源。**它的工作机制是基于经典和机器学习的预测算法,再加上基于云原生开发的容量伸缩工程技术,完成云原生整体应用容量的稳定性和资源的合理使用。
之所以要做这件事,是因为在线应用资源利用率一直很低,并且由于其长期运行(Long-Running)属性,导致资源规格和副本数在刚申请时就已固定。蚂蚁集团希望找到一套适合金融级规模化的弹性伸缩技术(Autoscaling),结合应用流量特征来对应用规格和副本数进行弹性调整,为传统的在线应用实现 Serverless(无服务器化),从而提升在线应用的资源利用效率,节省成本。
也有人考虑过使用 K8s 等开源社区现成的 HPA/VPA 技术,但在实践中遭遇了难题:第一,大部分在线应用的服务能力和资源利用率关系并非简单线性关系,无法直接像社区 HPA 技术一样通过 Metrics 来驱动;第二,蚂蚁集团的金融属性业务稳定性要求高,历史原因导致的业务复杂性也很高,这使得弹性伸缩变成一件高风险的事,需要建设技术风险控制手段,防止异常导致故障;第三,在线应用扩缩容速度需要10分钟以上,无法满足快速弹性的要求。
出于这些原因,自研设计一套适合蚂蚁生产环境使用的容量托管弹性方案,成为摆在郑洋飞和团队面前势在必行的任务。
**云原生弹性容量技术的架构,主要是由画像系统和 AutoScaler 组成的多层封闭负反馈控制系统。**画像系统通过大数据技术和机器学习算法实现应用的最优规划,AutoScaler 根据画像分析给出的应用画像,来执行多级 HPA 变更和 VPA 变更。画像系统会对应用特征进行大数据积累,加上离线和实时算法分析,通过积累应用的数据规律和生产环境的数据反馈实现 workloads 的最优求解,也会对画像系统进行变更管理和灰度控制,降低技术风险;AutoScaler 建设多级 HPA 实现水平伸缩,通过 VPA 垂直伸缩,其中多级 HPA 通过 Service Mesh 极大地缩短了应用的启动时间,提供稳定高效的应用扩容速度、降低缩容风险。
一言以蔽之,就是在保证稳定性的前提下,对资源进行最优化的配置,实现经典应用的 Autoscaling。“这项技术成熟后,可以实现容量故障的大幅下降和资源利用率的提升。”郑洋飞畅想。
说来轻松,上手谈何容易。在郑洋飞之前已有4个失败的先例,他本人也曾在这上面栽过跟头,无数质疑和反对声涌来,郑洋飞置之不理:“现在的云原生基础设施比以前好很多,我们对问题的定义和理解也变深厚了,并且我们是一支不怕困难的团队,我觉得能做成。”
既然认准了道路,就只顾一往无前。对云原生容量的钻研还在起步,团队的工作已小有成效:2019年,郑洋飞和团队为蚂蚁投入的运维经费节省了大约10%。
他兴奋地挥挥手:“感觉好像手上多了一大笔钱,我想买啥就买啥!”
郑洋飞的经历,勾勒出蚂蚁技术风险部的发展轨迹:“职位能力化,能力平台化”。
多种多样的平台工具,成就了“无人驾驶”的十八般兵器。如果说之前的双十一是硝烟四起的战场,现在的双十一则更像是一场练兵:人力成本大幅度降低,技术风险部常会安排新人上场磨练能力,“太过依赖现成的平台,就没有我们当年那种紧张感了。”
**平台是技术的凝缩,人则是创造和演进技术的关键。**以SRE为例,这个最早由国外互联网公司提出的概念是指 Site Reliability Engineer,“网站可靠性工程师”。SRE 被要求同时具备强大的编程算法能力和网络架构技术,只有顶尖的互联网公司才会出现真正的 SRE。
在蚂蚁内部,SRE 的定义又有不同,指的是 Site Risk Engineer。许多不清楚这个概念的人时常抱以质疑的态度:这是不是单纯的 PE(运维工程师)?是给其他业务“背锅”的?
郑洋飞一锤定音:“SRE 不是一个岗位,而是一种能力。”
“当我们技术风险能力做到足够成熟时,就不需要 SRE 岗位了。”郑洋飞表示,团队这两年已经在逐步地“去传统 SRE 化”,SRE 作为一种能力被编入了软件和平台内,工程师的任务不再是传统运维工作,而是为这些平台提供软件工程服务。
无论在蚂蚁内外,郑洋飞和整个技术风险团队身边从来不缺乏质疑的声音。有些人选择退缩和放弃,也有人矢志不移,举步向前。
**“技术风险部存在的意义,就是认真分析每个故障背后的原因,总结出一套规律,避免这一类故障的发生。”**作为坚守多年的老将,郑洋飞俨然已经是部门内的资深成员,“我就是想证明,一方面我在这里是有成就感的,一方面我们做的事情是能得到价值认可的。”
我问他,什么时候第一次意识到自己的工作和所有人息息相关?
郑洋飞回忆说,某天一项功能发布时出现了问题,咨询和投诉电话立刻打爆了支付宝客服热线,那一天很多客服妹子都没能吃上午饭。“没有身在其中过,就很难意识到自己敲下的每一行代码有着怎样的分量。”
“我不是什么天才少年,肯定不是。”郑洋飞说,“我就是一个普通人。”
他套用了最近正火的杨超越“金句”:老天爷不一定只爱聪明的人,他的万分之一也会宠幸到我们这些笨小孩。“感谢公司给我们这种普通人一个机会。”说到这里,“笨小孩”乐不可支。
人人生而平凡,但偶尔也像群星闪耀。蚂蚁翻越山岭,天地开阔,每颗星星都在自己的位置上发光。
我们是蚂蚁云原生性能容量团队,云原生容量技术的作用,正是根据历史趋势和实时预测,计算出每个应用应该合理使用多少资源。它的工作机制是基于经典和机器学习的预测算法,再加上基于云原生开发的容量伸缩工程技术,完成云原生整体应用容量的稳定性和资源的合理使用。
techrisk-platform-hire@list.alibaba-inc.com