一分钟精华速览
容量保障的目标是保证服务在大量用户访问时，依然可以正常为用户提供服务。比如，在“双11”购物节的超高访问量下，各电商系统依然能够稳定地运行，可以说容量保障是所有技术人都应当具备的技能。
知名技术博主老张结合其在电商行业多年的容量保障经验，系统梳理了一套容量保障方法，分享了如何根据业务场景制定容量保障的目标，以及如何从点到面系统地落实容量保障工作。 
作者介绍
前得物稳定性测试团队Leader 张维功 TakinTalks社区专家团成员，网络ID老张，前得物稳定性测试团队Leader，资深测试专家。在全链路压测和稳定性保障领域具有丰富的实践经验。技术专栏超过500w阅读量，在电商零售行业有丰富经历。曾多次以特邀嘉宾的身份在多个技术大会进行分享。目前专注于技术咨询和解决方案领域。
温馨提醒：本文约4800字，预计花费8分钟阅读。 公众号后台回复 “交流” 进入读者交流群；回复“1072”、“预案模版”获取资料；
背景
技术同学特别是做性能测试，SRE和运维相关的同学，经常会遇到几个问题——
技术能否支撑业务增长？很典型的场景是电商大促比如 618 、双11等，一般会有一些业务指标的增长，比如GMV从日常的1亿可能变成 10 亿，业务增长带来日活、月活用户的增长，此时随之而来的问题是：系统的性能和稳定性，能否满足业务增长需要？这是一个很典型的问题。
技术本身存在的瓶颈如何改变？软件系统本身是基于硬件资源来部署和运行的，意味着系统的处理能力是有限的，即技术本身存在一定瓶颈。当我们优化和改善这些瓶颈时，一些新问题也会出现，比如：扩容到底需要准备多少资源？如何分析、验证，才能得到比较精准的数据？
技术如何满足业务的复杂性和突发性？电商业务本身是非常复杂的，加之大促时期丰富的促销/营销活动，比如秒杀、抽奖、转盘等，以及包括搜索推荐、消息推送等营销引流手段，都会带来大量突发流量。面对技术的复杂性、突发性，系统能否正确地来承接突发流量，并解决这些问题？
我提出上面三个问题，其实是想和大家一起探讨思考，容量保障到底是什么，或者说容量保障到底要解决什么问题？
一、我是如何理解容量保障的？
1.1 容量
我认为容量是指软件系统在单位时间内，能够承载并且能正确处理的最大业务量。这里专门标注了业务量，而不是常见的请求量或QPS，因为技术是要支撑业务平稳运行的，需要以正确的业务量为单位来衡量。
1.2 容量保障
而容量保障，我认为是运用各种方法和工具来保障软件系统的容量可以承载并处理各种业务，并且本身还要具备一定的弹性能力。这里的弹性能力是说系统本身要有比较灵活的扩缩容功能，当遇到突发的场景或者故障时，需要具备弹性的自愈能力。
1.3 容量保障的挑战
1）容量的不确定性。前面讲到了电商的业务场景是非常复杂的，存在各种突发流量场景。
2）容量评估的复杂性。本身容量治理是非常复杂的工程，再加上近几年微服务、云原生技术的不断发展，系统架构变得越来越复杂，对庞大的软件系统做容量评估并非易事。
3）容量测试的精准性。容量评估后，我们需要通过各种手段，比如全链路压测、故障演练来测定和验证，之后才能进行后续的容量规划治理。
4）容量规划治理的复杂性。在进行容量规划的过程中，得先解决很多其他问题，比如环境的问题，环境不一样，所需的资源配置不一样，测试的业务场景和实际生产场景之间可能会存在一定差异；而且业务是不断迭代的，线上系统在不断地发版，代码逻辑可能一直在变，所以容量规划本身是一个持续性的技术动作。
1.4 容量保障方法论体系
我将自己工作的实践整理成了下图的容量保障方法论体系： 
我认为容量保障可以从3个角度来看——方法（指导实践）、组织（协调资源）、工具（支撑提效）。
容量保障对象：就是线上的系统要面对的事情，可能有日常事件，计划事件，还有一些突发事件。
容量保障方法：通过事前、事中、事后，还有全局的角度去解决不同的问题。比如事前需求分析、风险评估，事中流量评估、流量测试、定位排查及决策，事后数据沉淀、复盘、改进等，全局的日常容量巡检、容量治理工作，都是持续性的事情。
容量保障工具：需要建立压测平台来做容量测试；需要监控平台做数据采集、指标监控、问题分析；问题优化发版还需要发布平台来做支撑，以及预案平台来支持各种限流、降级和熔断。
容量保障组织：组织需要推进流程规范的标准定义，还有容量规划，确保容量保障工作的持续运营，包括通过复盘、改进、沉淀一些案例库。当然，它也可以是一个虚拟组织。
二、如何进行模型梳理和流量预估？
要做好容量保障工作，我认为在前期的分析评估阶段比较重点的两件事：一个是模型梳理，另一个是容量预估。
2.1 模型梳理
一般做容量保障，从我的实践经验来看，需要梳理的模型大概有三种，分别是业务模型、流量模型和数据模型。 
2.1.1 业务模型
业务模型很好理解，流量保障的对象是软件系统，软件系统是针对业务的高度具象化的产品。梳理业务模型一般大概有这4个步骤：
1、先确定业务范围。 2、从业务范围里确定核心业务。 3、确定对应的核心应用服务。 4、再确定对应的核心场景。 确定完业务模型后，接下来就可以进行具体的流量模型的梳理。
2.1.2 流量模型
流量模型也分很多场景，以电商业务来讲，系统有日常的低谷流量，也有 618 、双11这种峰值流量，即系统在不同时间段所承接的访问量是不一样的，而且这些流量访问的业务配比也不一样，所以，要结合具体的业务场景/业务模型，将采集到的数据流量，参考其转化效果形成流量漏斗。最后结合具体的业务目标，将其转化为技术指标，这部分后面会详细讲解我的实践。
2.1.3 数据模型
前面我们讲到的是评估和分析环节，接下来的测试和准备环节，我们需要准备数据模型。数据模型涉及到以下几点：
1）铺底数据，以常见的电商业务为例，铺底数据可能涉及到商品信息、库存、个人用户信息、收货地址等等。
2）热点数据，比如用户登录后会生成的Token，一般来说会预热到缓存里。
3）测试数据，要根据具体测试场景本身的流量漏斗来准备。以下单为例，用户下单的商品，是否参与店铺满减、是否参与营销活动、下单的用户是否有优惠券、是否是 VIP 会员等等，在同样的下单场景里，不同的时候对应的请求细节是不一样的。所以在准备测试数据时，一定要针对性地一步步做区分。
4）数据治理，实际上可以归类到容量规划和治理环节，后面我会有具体的例子做说明。
2.2 流量评估九步走
流量模型到底该怎么梳理？如何将业务目标转化为技术指标？接下来我将做重点介绍，下图是我总结出来的“流量评估九步走”。 
1、划分流量来源。流量会有不同的入口，从用户的角度来讲，有 web端、移动端、小程序等等不同的入口，对应不同的网关。所以在做流量采集、监控时，一定要划分不同来源，这样才能便于获取到不同入口的流量。
2、确认流量统计类型。请求从流量入口进来之后，到服务端、消息推送、缓存、数据库，请求在整个透传的过程中的数据量级是不一样的。
3、借助监控组件。统计流量数据需要借助一些监控组件，比如链路追踪的有Cat 、 Skywalking 、Jaeger等等，流控组件如Sentinel等，可以在不同层级监控到一些很详细的指标。
4、选取采集场景。我们需要知道获取的这些数据来自哪些采集的场景，比如是在日常场景还是在峰值场景采集到的。
5、汇总流量数据。对采集到的数据进行加工清洗或计算，最终把这些数据汇总后就能得到一个流量漏斗。
6、获取投放引流。需要关注业务对流量的影响，以电商业务为例。在双十一等大促时，业务侧会做较多投放引流，如消息推送、短信提醒等等，会导致短时间内有新的流量进来，所以需要考虑投放引流的时间段、投放的类型以及引流带来的流量量级。
7、确认验收水位。测定系统容量时需有统一的验收标准，当容量达到水准线，我们认为它的结果是预期想要的。根据业务情况，可以从单机水位来确认，即我们常见的资源利用率（CPU利用率或者内存利用率）。
8、执行容量测试。可以通过单接口、单链路、混合链路，甚至全链路压测、预案演练等等不同的方法，验证不同场景的容量。得到数据之后，接下来最后一步就是最终的线上容量规划。
9、线上容量规划。所有的分析评估及容量测试工作都是前置的，最终目的是要确保真正流量来临时，线上系统能稳定运行。因此还得有其他的一些手段，如限流、熔断、降级、隔离等，即常说的预案。预案也需要通过多次演练，以验证有效性和正确性。做完这些后，还得有一定的冗余资源来应对预估之外的情况。
2.3 业务目标转化成技术指标
一般在做指标转化时，要关注三点：业务目标、技术指标、流控指标。 
接下来我将结合电商业务的某个场景，具体介绍业务目标转化为技术指标的实践。
第一步：确定业务目标 以电商业务来讲，比如平均客单价是500元，单日GMV目标是10亿。计算可得到平台单日的支付单量为200万单。
第二步：转化技术指标 首先前面通过监控采集到了该业务的流量漏斗，即转化比例。假设日常支付订单量为50万单，支付转化率为40%，此时可以粗略得到订单支付接口峰值的QPS为200。 然后预估大促时，大家购买的目的性比较明确，转化率达到60%，则峰值支付QPS可能达到1200，得到了一个保底数值。但是做容量测试是要留一定冗余空间的，假设上浮30%，则峰值QPS为1500。 电商的核心转化链路：导购首页—商品详情—创建订单—订单支付—支付成功。这个链路本身从上一级到下一级会有类似漏斗的转化，我们假设每个环节转化率都是40%，根据依赖调用关系及链路追踪监控得到的数据，我们就能计算出所有核心链路的QPS数值。
这就是业务目标到技术指标转化的一个具体案例。
2.4 流量模型示意图
下图是2020年我绘制的一个流量模型。 
当然前期工具没那么完善的情况下可能需要手绘，后期可以尝试把这些数据QPS、TPS等直接自动计算出来，生成一个在线实时变化的模型，但无论是手绘还是用工具来做，它的整体思路是不变的，只是在借助工具的情况下可以做到更好。
三、为什么容量保障杀手锏是预案？该怎么做？
3.1 预案的优势
首先，预案能解决一些不确定性的问题，比如线上发布失败，我们该怎么做？是通过回滚还是通过其他方式来解决？比如监控、异常告警或安全风控拦截，这些异常情况该怎么处理？
其次，预案可以让我们的工作有的放矢，针对各种问题提前进行评估，就能更快知道问题在哪、该怎么解决、由谁来解决问题。
最后，预案也能提升技术效率，无论是定位问题的效率，还是解决问题的效率，甚至还有团队协作的效率，都能带来一定的提升。
3.2 预案梳理思路
总结下来，预案梳理可以从三点入手：从问题开始，从目标切入，从风险着手。 
3.3 预案参考案例
下面会介绍我做的一些预案的例子，以及我们当时踩过的坑。 公众号后台回复“预案模版”领取资料 
3.3.1 日常预案
日常预案会做线上巡检，比如监控巡检，检查线上监控有无异常；比如非 200 的异常占比有多少、具体日志是什么；再比如MySQL、Redis 的巡检等，这些是日常预案要做事情。
还有异常治理，如果巡检出了异常且它不在预期正常范围内，就要针对性地进行分析处理。
因为线上很多业务可能涉及到资金、支付或优惠券，就会做一些防资损日常校验。这种防资损校验，是通过线上白名单的测试账号，专门去做和资产、支付、资金相关的场景，类似日常的功能测试或者冒烟测试。
3.3.2 计划预案
以双11来讲，我们会做全链路压测，还有限流、降级、熔断的操作，以及定时任务错峰执行。因为有一些业务是非实时的，比如我们每天会有报表、对账等业务，在业务的低峰期通过定时Job执行，这时会遇到一个问题，比如当双11零点，流量峰值最高的时候，如果有一个定时Job做扫表或做大量查询，遇到其他的业务高峰就可能会造成交叉影响，所以我们需要做定时任务的错峰执行预案。
3.3.3 突发预案
比如线上突然某部分服务直接宕机或不可用了，第一优先级还是要业务止血，此时会有网关路由到故障服务的流量，切流到其他的备份服务器。
还会做故障的摘除重启，把故障机器重启后，查看是否是机器本身的因素导致的。
还有一些优惠券失效的预案，比如之前双11曾遇到过这种问题，在零点时优惠券全部失效，因为优惠券一般会在缓存里做预热，缓存失效后就直接去查数据库，导致短时间内整个数据库的CPU飙高。像这种问题，针对性的预案是，可以按照用户的ID或其他方式，将优惠券做分片，通过本地缓存的方式，挂载在对应优惠券的服务上。这样也能解决问题。
3.3.4 业务预案
小红点提醒，比如快递、商品推荐、退款到账时的小红点提醒，在大促访问量比较高时，我们会提前集体关闭小红点，消息提醒只会显示一个红点。
还有像电商或者短视频比较常见的，根据喜好推荐不同的商品或视频，如果访问量比较高时，为了降低响应时间，会把商品推荐做短时间的关闭。
当然预案在前期梳理及执行过程中，可能会通过excel表格或手动执行，但是手动执行会存在一些误差，所以后来就将手动预案做成了预案平台，把线上的突发情况或营销活动的预案，都通过系统来做管理，从而避免人为因素带来的一些误操作、耗时长的问题。
四、容量保障创造了哪些价值？
4.1 资源成本降低40%
初期我们的线上服务，在日常流量下的资源利用率是不超过10%的，造成了一定的资源浪费，通过容量保障我们将日常的线上资源利用率提高到了25%以上，在资源利用效率上提升了，也变相降低了硬件成本。
4.2 风险损失降低65%
在解决问题的效率上也有比较大的提升，之前版本迭代线上发布基本每次都会出问题，问题排查耗时一两个小时是常态，有时候也会通宵发版，容量保障工作让我们能15分钟以内解决问题，常见问题也能更快发现、更快解决，降低了整个系统的风险。
4.3 人力成本降低50%
2019年刚开始做生产全链路压测时，当时做一次生产全链路压测基本需要50多人参与，到后面在技术、实践、方法上都比较熟悉后，一次全链路压测基本只需要20来个人参与就能够搞定。所以容量保障整体带来的降本增效的价值，还是比较大的。
公众号后台回复【1072】获取课件 更多内容欢迎点击“阅读原文”，进入「TakinTalks稳定性社区」，获取更多稳定性相关资料和知识。
声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。
本文由博客一文多发平台 OpenWrite 发布！
