容量保障核心技术与实战
吴骏龙
前阿里巴巴本地生活P8高级专家
新⼈⾸单¥55
867 人已学习
课程目录
已完结 17 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 互联网时代,人人肩负容量保障的职责
免费
基础篇 (4讲)
01 | 容量保障的目标:容量保障的目标是什么?该如何度量?
02 | 容量测试与验证:怎样科学实施容量测试?
03 | 容量指标分析经典5问:响应时间真的是越短越好吗?
04 | 容量治理的三板斧:扩容、限流与降级
进阶篇 (7讲)
05 | 全链路压测:系统整体容量保障的“核武器”(上)
06 | 全链路压测:系统整体容量保障的“核武器”(下)
07 | 工具进化:如何实现一个分布式压测平台
08 | 容量预测(上):第三只眼,通过AI预测服务容量瓶颈
09 | 容量预测(下):为不同服务“画像”,提升容量预测准确性
10 | 浅谈排队论:数学之美,通过建模计算容量
11 | 与时俱进:云原生下的容量保障新趋势
案例篇 (4讲)
12 | 大促容量保障体系建设:怎样做好大促活动的容量保障工作(上)
13 | 大促容量保障体系建设:怎样做好大促活动的容量保障工作(下)
14 | 容量保障组织建设:容量保障需要什么样的团队?
15 | 小公司也能做好容量保障:建设经济实用型的容量保障体系
结束语 (1讲)
结束语 | 做时间的朋友,成功是持续累积而成的
容量保障核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

15 | 小公司也能做好容量保障:建设经济实用型的容量保障体系

吴骏龙 2021-06-14
你好,我是吴骏龙。今天我会与你探讨一下小公司如何做好容量保障。
首先,我想先明确一个前提,那就是小公司到底要不要进行容量保障,很多人会觉得小公司进行容量保障的必要性不大,理由无外乎有:
公司规模不大,业务量也不大
公司不搞促销活动,流量波动不大
公司用的是云基础设施,它们会负责容量安全
公司技术团队人太少了,肯定是先保证质量
我的观点是,是否要进行容量保障,和公司“大”与“小”无关,而是与业务形态和发展趋势相关。
我经历过一家初创型的电商公司,这家公司在早期整个技术团队不超过 30 人,服务都是单体应用的架构,业务以到家的形态为主,基础设施用的也是某大厂的云设施。传统认知上,这是一家典型的小公司,但随着业务的不断发展,业务高峰期间系统服务的压力越来越大,经常发生服务稳定性的问题,以至于高层很快决定将容量保障列为了技术团队最重要的工作之一。
这个例子完整的解答了对于容量保障工作必要性的讨论。
首先,是不是要做容量保障,和公司的规模其实没有什么关系,而是和公司的业务特点有关,比如我在开篇词中曾提到的一个关于某企事业单位内部系统的例子,它的用户量和用户群体都比较稳定,业务场景几乎不变,虽然这个单位的人员规模很大,容量保障的意义也比较有限。相反,如果是面向外部用户的互联网系统,业务场景有明显的流量峰值,再小的公司也一定会进行容量保障,只是做法不同罢了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《容量保障核心技术与实战》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥55
立即订阅
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
返回
顶部