12 | 大促容量保障体系建设:怎样做好大促活动的容量保障工作(上)
吴骏龙
你好,我是吴骏龙。
在我的容量保障生涯中,有很多属于自己的记录:完成了上百次全链路压测、发现和改进了近千个容量问题、编写的压测平台总共支撑了近万亿次请求量……这些记录仍在延续。但在这些记录背后,也有我的一把“辛酸泪”:有未能发现容量隐患挨骂的,有把生产环境压挂了背锅的,有几次甚至都想撂担子不干了。但如果你问我什么时候压力最大,那我的答案只有一个,在大促期间做容量保障工作的压力最大。
为什么压力会那么大,因为大促活动和平时的业务场景很不一样,归纳一下,主要有三个特点。
首先,大促活动有一些日常没有的特定场景,比如秒杀活动、特殊的营销活动等,在没有常态数据可供参考的情况下,增加了容量保障的难度。现在一些大厂会倾向于复用之前的活动策略,比如支付宝的五福、红包雨等等,每年都是类似的套路。这除了有营销运营方面的考虑外,也是希望能有历史数据的沉淀,更好地预测用户流量。否则,每次都是新的玩法,容量保障的难度是非常大的。
其次,在大促场景下,一些业务指标会发生悄然的变化,比如转化率就是一个明显的例子,进入活动会场的用户数量较平时大幅增加,但这些新增的用户不一定都会真正下单,这样转化率就会变低,这时容量测试的目标也需要进行相应调整。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文分享了在大促活动中建设容量保障体系的关键技术工作。作者强调了明确背景与目标的重要性,并提出了对业务目标进行量化,并将业务目标转换为技术目标的方法。文章重点讨论了大促活动中的重点链路梳理和服务架构治理。在重点链路梳理方面,作者详细阐述了如何梳理高并发链路,并以红包雨场景为例进行说明。在服务架构治理方面,重点介绍了调用关系图、部署图和时序图的作用。此外,针对存量服务的架构治理工作,建议按业务领域打散到每个业务团队,以专项的形式进行,甚至是组织头脑风暴来尽可能全面的分析问题。总的来说,本文通过丰富的实际案例和经验分享,为从事容量保障工作的技术人员提供了宝贵的参考价值。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《容量保障核心技术与实战》,新⼈⾸单¥29
《容量保障核心技术与实战》,新⼈⾸单¥29
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
- 于加硕该怎么说呢,吴老师,站在SRE的角度这篇文章我读了小10遍,我梳理下本文逻辑 活动保障前 指导思想: 业务指标转化为技术指标,技术指标联系业务场景 能力建设: 1.与业务沟通,获取业务信息,产出业务指标 2.与技术沟通,获取调用关系图用于识别活动上下游关系、依赖方等,将业务指标转化为技术指标,并产出活动保障所需的仪表盘 获取部署图,来确定容量保障的范围 获取时序图,识别出同步链路、异步链路、旁支链路、高并发链路,识别出爆点重点防护, 3.架构治理、代码治理,作为一个运维,目前玩不了
作者回复: 总结的非常好!这一讲我基本上是按照每年阿里本地生活的大促保障模式,抽象归纳出其中的精华内容。这些内容肯定不是单一的角色能够全部完成的,但会由一个大促保障的PTM(Project Technical Manager,注意不是TPM)去驱动和统筹,由高级别管理人员背书。
2022-11-21归属地:上海1 - 于加硕单说核心链路梳理这一块对于业务运维来说就有难度2022-07-201
收起评论