开篇词 | 互联网时代，人人肩负容量保障的职责

吴骏龙



讲述：吴骏龙大小：10.16M时长：11:05

你好，我是吴骏龙。欢迎你和我一起学习容量保障。
如果你现在还不知道“容量保障”到底是啥意思，那也不用着急。因为，容量保障其实就在你我身边。我们在使用的各种互联网应用，比如你点外卖使用的“饿了么”“美团外卖”等等，比如你使用的各种电商 App，它们的稳定运行，背后靠的都是各类技术保障工作。
而在这些技术保障工作中，最重要的就是质量保障和容量保障这两类：
质量保障，是确保服务功能正确，不出问题。比如，订单系统结算时，要保证金额正确。
容量保障，是要保证服务在大量用户访问时，依然可以正常工作。比如，在“双 11”购物节的超高访问量下，各电商网站依然能够稳定地运行。
而我，先后在 eBay 上海研发中心和阿里巴巴本地生活（前身是“饿了么”）工作近 8 年的时间，做的就是质量保障和容量保障相关的工作。
在 eBay 工作时，我主要负责质量保障工作，在部门内建立了完善的自动化测试体系和持续集成流水线，并将机器学习引入到软件测试工作中，解决了测试报告自动分析的难题。这些成果至今仍然是互联网行业的前沿研究方向。
后来我到了阿里本地生活，当时恰逢异地多活项目落地，随之而来的是全链路压测工作的启动。作为当时团队中的平台开发 Leader，我有幸参与了这项浩大的工程，并主导负责了整个全链路压测的自动化和规范化工作。这是我第一次系统接触容量保障工作的重要环节，它就像是我的孩子一样成长。直到现在，我们曾经的团队成员聚首，对此还会津津乐道。
在全链路压测走向正轨以后，我渐渐发现仅通过全链路压测是无法全面保障系统容量安全的。于是，我将工作重点从全链路压测这个专项，转向了整个容量保障的体系化建设，致力于推动高效和富有层次的容量保障实践，并带队攻克了多项容量预测难题。我自己也作为阿里本地生活的全局容量保障负责人，固守着这一片碧海蓝天。
目前，我在一家创业公司继续我的质量保障和容量保障事业，而容量保障是我深耕最多的领域，也是我投入巨大热情的地方。
那为什么我想要开设这样一门课呢？
在我的职业生涯中，能够非常深刻地感受到，容量保障对于一家互联网公司的重要性，因为几乎每时每刻我都在回答这些问题：我负责的软件系统目前运行的很好，但是公司业务增长迅猛，如果访问量增加 2 倍，系统还能支撑吗？如果无法支撑 2 倍的访问量，哪些服务会首先成为瓶颈？这些服务如果采取扩容措施，需要扩容多少量？大规模促销活动场景下，容量风险如何识别和预防？
与此同时，随着互联网应用复杂度和系统架构复杂度的不断增加，容量保障涉及的工作越来越多，随之而来的误区和困惑也越来越多。
我在多个场合进行容量保障分享时，也经常被问及这样的问题：
我们一直在做性能测试，为啥服务容量还是老出问题？
容量保障，有没有套路可循？
我们公司规模不大，没有专人去做容量保障，有没有成本低点的办法？
我公司规模不大，业务也没有什么大促场景，需要做容量保障吗？
别着急，这个专栏我们就是来解决上面的问题。我写这个专栏的最大初衷，也是希望把我在容量保障领域的经验，总结成方法论分享给你，帮助构建一个全局视角，使你不仅知道容量保障该怎么做，还能深入理解为什么要这样做。
在互联网行业飞速发展的今天，除非我们的系统有非常固定的用户规模和长期不变的业务逻辑，否则，容量保障应当是每个互联网公司都需要广泛关注的工作。无论你是性能测试人员、研发人员、架构师、运维人员，或是现在流行的 DevOps 或 SRE 人员，都应当具备容量保障技能，重视容量保障工作。
看到这里，你是否会有困惑，性能测试、压测、扩容……这些词就代表容量保障吗？容量保障到底是什么呢？在这里，我就给你下个定义吧。
到底什么是容量保障我们拆开来看，容量保障 = 容量 + 保障。
容量是什么？容量是一个在生活中很常见的概念，我们喝水的杯子就有容量，我们每天上班搭载的地铁也有容量。广义的容量可以定义为：容器能够承载物质的量。杯子就是容器，水就是物质，杯子能够装多少水就是容量。
而从互联网技术视角出发，我们可以将软件系统或服务视为容器，流量或业务量视为物质，那么就可以得到互联网软件系统容量的概念，即“单位时间内软件系统能够承载的最大业务量”。
而容量保障，就是用各种方法保证软件系统的容量充足，预防容量隐患的重要工作。
容量保障对于系统稳定性至关重要，如果一辆货车核载 80 吨，而我们塞进了 100 吨的货物，后果可想而知。互联网历史上多家大厂也曾发生过多次因容量问题引发的线上事故，比如某年春晚某头部电商的摇一摇红包活动短暂宕机，微博在娱乐圈出现热门事件时的频繁宕机，都对用户造成了巨大影响。以至于网友纷纷调侃，衡量明星火不火，就看微博是否为他 / 她宕机过。
容量保障难不难？也许你会问，既然容量就是系统能承载的业务量，那我多加点服务器不就行了吗？但我要告诉你，容量保障不是这么简单的，否则就不会有上面那么多困惑了。
互联网场景下的容量保障工作是一项系统性工程，它的难点主要体现在以下几个方面。
1. 容量的不确定性： 一辆货车在交付时已经标注了核载重量，而互联网服务的容量受服务器资源、架构设计、网络传输状况和业务场景等多种条件制约，会呈现出不同的容量表现，很难得到确定解。
2. 容量评估的复杂性： 随着微服务架构的日益盛行，服务链路变得越来越复杂，任何一个环节出现容量瓶颈都有可能放大到整条链路，这给容量评估工作带来了难度。
3. 容量测试的不准确性： 容量测试的场景需要尽可能逼近真实情况，还需要保证被测服务的环境（服务资源、规模、配置等）与真实环境对等，但实际上受制于各种原因，我们很难做到完全仿真，因此容量测量的准确性也是一个挑战。
此外，容量保障还会牵扯到成本管理的问题，这也是一个难点。因为工程师主要面对的是技术问题，更关注技术层面的目标，而公司的管理层则倾向于将项目成果和业务需求作为核心目标。在实际业务发展过程中，尤其是在业务进攻期，系统所需资源比如：服务器、内存、硬盘、网络带宽等，它们的成本很容易被工程师们忽略，或者在很晚才被考虑。
从全局来看，如果前期对研发资源成本缺乏规划，等到业务发展到了一定规模，拿到机器账单的时候，惊呼“机器怎么这么费钱”，再想立即降低成本，可能已经错过了最佳时机，因为技术改造本身是一个相对长期的过程。很多公司的成本管理意识可能就如下图所示，是不健康的。
因此，容量规划是容量保障的一个核心环节和难点，不仅要保证服务能够承载相应的流量，还要确保以尽可能少的资源来承载这些流量；更进一步的，在当今开源节流的大背景下，我们还希望以尽可能低的人力成本，保障容量安全。
说了那么多难点，那么如何将它们变得不难呢？这就是我的这个专栏希望带给你的价值。
课程是如何设计的在这次的专栏中，我将从技术视角出发构建一个容量保障体系化的大图，覆盖容量保障工作的方方面面，逐个击破，尽可能全面地展现容量保障各项技术的全貌。具体来说，会有以下三个部分。
基础篇： 我将以容量保障工作的时间轴为主线，分别就目标、测量、分析、治理这几大工作展开，积累容量保障的通用方法，帮助你完成基础入门。
进阶篇： 我将分几个独立专项话题，对容量保障工作中的一些前沿技术进行深入剖析，包括全链路压测、分布式压测平台的研发工作，以及 AI 预测容量、云原生下的容量保障新趋势等。这其中部分话题在业界甚至是第一次公开，非常值得学习。
案例篇： 从案例场景出发，介绍双 11 大促场景下的容量保障工作如何做好，及小公司如何建立容量保障体系，并对容量保障组织建设给出我的建议。
在这里，我先为你总结一套较为适合互联网场景的容量保障方法论，如下图所示。先从“日常容量”和“大促容量”的目标出发，拆分出三个入口，分别对应计划事件（事先能够预知的新功能或大促活动）、突发事件（事先无法预知的紧急事件）和日常事件（常态化的容量表现）。再自上而下拆解出具体的策略（工作项、工具、规范、案例等），每一项策略再做具体细分，形成一个有机的整体。
在接下来的讲解中，我会再对这个方法论体系中的核心环节进行详细描述，帮助你更好地理解和落地。当然，这套方法论未必适合所有的场景和业务形态，但我认为，即便是在一个全新的领域，它也可以帮助你在最短的时间内，建立一套有效的容量保障体系。更重要的是，它提供了一种核心的思维方式。
最后，我想跟你分享一句我很喜欢的名言，来自列宁：“我们不需要死读硬记，我们需要用基本的知识来发展和增进每个学习者的思考力”。希望这个专栏能够引发你的思考，助你早日成为一名容量保障的“尖兵”。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

互联网时代，容量保障成为互联网公司稳定性的关键。作者吴骏龙从多年互联网行业经验出发，总结了容量保障的重要性和挑战，并提出了一套适用于互联网场景的容量保障方法论。文章从容量保障的难点出发，包括容量的不确定性、评估的复杂性和测试的不准确性，以及成本管理的问题。作者设计了专栏课程，分为基础篇、进阶篇和案例篇，涵盖了容量保障工作的方方面面。他提出了一套适合互联网场景的容量保障方法论，从目标出发，拆分出计划事件、突发事件和日常事件，再自上而下拆解出具体的策略，形成一个有机的整体。作者强调这套方法论提供了一种核心的思维方式，可以帮助读者在最短时间内建立一套有效的容量保障体系。整体而言，本文深入剖析了容量保障的重要性和挑战，为读者提供了一套系统化的容量保障方法论，对于互联网行业的从业人员具有重要的参考价值。

2021-05-1211人觉得很赞给文章提建议

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《容量保障核心技术与实战》，新⼈⾸单¥29

立即购买

登录后留言

全部留言(7)

最新
精选

zuozewei
个人觉得容量保障属于运维 SRE 范围，即 SRE 性能事件快速响应，其特点是： 1）需要在短时间内解决问题 -快速决断为王。可以扩展，回滚，重定向流量等。 -必须应付压力，熬夜很正常。 2）系统之前处于“良好”状态 -需要快速发现不同于历史的曲线 3）需要立即得到所有干系人员的帮助 -必须具备社交性 4）可靠性和性能问题经常相关
作者回复: 同意你的观点，在最权威的Google SRE实践中，基础设施的容量规划、容量治理和相关演练措施，以及应急响应等工作，都是SRE的重要职责范围。不过，容量保障“不仅仅”属于SRE的范围，我们可以将SRE视为动车组的车头，相关的研发团队和测试团队等，视为动车组的挂载车厢。注意，动车组所有的车厢都是有动力的喔，并不是单靠车头去牵引的，车头的作用是指明方向。
2021-05-29

10
@李上网来⚡
那简言之，质量保障说的是功能，容量保障说的是性能。
作者回复: 理解到位！
2021-05-21

6
liubiqianmoney
除了质量保障和容量保障，其实还有一个稳定性保障。稳定性保障聚焦MTTR和MTBF，在缩短MTTR方面需要做可观测（系统异常可及时发现，并支撑故障定位）、应急响应配套（有故障处理的工具、机制、预案）和事故复盘配套（有复盘工具、复盘方法、运营流程），在延长MTBF方面需要做多活容灾与弹力架构、故障演练、技术风险治理、变更管控。
作者回复: 谢谢你的总结，稳定性保障确实是一个很重要的领域，而且和质量保障以及容量保障都有关联。
2022-02-20

1
汤进贤
老师，目前公司处于发展初期，业务变化比较频繁，版本更新较快，是不是优先保障单服务单接口的性能，待业务稳定后再开始全链路压测的策略会比较适合当下？
作者回复: 没错，这是一个合理的trade-off，在第15讲中我给出了更多方案，你也可以参考。
2023-04-07归属地：广东


牛减
大佬能否也开一门质量保障的？
作者回复: 感谢厚爱和支持，质量保障是一个big deal，它的涵盖面比容量保障更广，我，包括其他老师，也都会以各种形式输出一些质量保障的方法和看法（不一定是专栏，可能是每日一课或其他形式），你可以多多关注
2022-02-19
2

于加硕
喜欢最后一句话，基础知识促进思考力。
2022-06-21


77
电力的breeze么？
2021-05-24



收起评论