容量保障落地四步走

• 明确目标和衡量结果的指标；
• 制定落地实施方案并进行验证；
• 针对验证结果进行分析是否达到预期；
• 项目完结后不断复盘迭代进行维护优化；

明确容量保障的目标和指标

1. 降本：在保障线上业务稳定运行的情况下降低保障的成本（容量规划）；
2. 预防：解决已知的线上容量问题，提前进行风险评估预防未知的问题（容量治理）；

• SLA(服务等级协议)：主要是 SLI+SLO。详细内容请我之前的文章:《SRE实战手册学习笔记之切入SRE》；
• QPS/TPS/99R/Error%：这些关键指标表明系统能否在业务可接受范围内支撑预期的流量并且成功率较高；
• 用户体验：这看似是一个定性的描述，其实可以拆解为几个更详细的指标和改进措施，举个例子：

容量测试如何进行实施验证

确定容量测试实施范围

1. 故障驱动：即出现了容量问题，针对性进行验证；
2. 风险驱动：评估容易出现问题的风险点，将其纳入容量测试范围。常见的风险点如下：

1. 1. 关键路径上的关键服务：比如电商的订单、库存、支付服务；
   2. 有明显峰值流量的服务：比如秒杀、限时抢购、抽奖等服务；
   3. 对时延比较敏感的服务：一些底层或公共技术组件比如网关；
   4. 资源利用率较高的服务：比如搜索/推荐服务对内存要求比较高；
   5. 其他：新上线服务、已经存在风险的服务、历史经常发生故障的服务；

科学合理开展容量测试

1. 设计测试方案；
2. 测试方案评审；
3. 前期测试准备（比如脚本和数据）；
4. 容量测试执行；
5. 测试结果记录分析；
6. 不断复盘持续改进；

针对验证指标进行容量分析

1. 响应时间：相比于平均响应时间，更应该关注分位线，比如95rt，99rt；
2. 请求&业务成功率：性能测试追求的是更高的tps和更低的rt，但是所有的技术指标都是建立在业务成功的基础上（举例：下单接口状态码返回200，但业务提示未查询到库存，这就是典型的技术正确业务失败(未成交)）；
3. 资源使用率：常见的有cpu%和memery%，很多同学认为要降低资源使用率，其实不然。原因有如下几点：

1. 1. 不同的业务对资源的耗用和要求不同，比如搜索和推荐业务是计算密集型，常规的读写业务是cpu密集型；
   2. 资源使用率只是一个结果和现象，表明当前服务的某个资源并不繁忙，并不能说明其他地方不存在性能瓶颈；

4. 性能拐点：这是很多同学容易陷入的误区，非要不断加压找到性能拐点。其实服务性能是否达到瓶颈，需要依靠服务端的各项指标结合业务场景去判断，而不是不断加压来判断。
5. 指标抖动：这个也称之为指标毛刺，因为常见的可视化监控系统都是通过各种图表折线来展示。很多时候线上的容量故障都是由于无人在意也不明原因的“毛刺”导致的。指标出现抖动说明存在超出我们预期的情况，如果不重视，久而久之很容易出现问题。

容量治理最常见的几种方法

• 性能提升三板斧：扩容、升配、加缓存；
• 容量治理四板斧：限流、熔断、降级、隔离；

1. 扩容：应用计算能力受限于硬件资源，只要应用服务具备弹性扩容的特点，完全可以用扩容来提升性能；
2. 升配：应用计算能力受限于硬件资源，提升硬件资源的配置从某种程度上来说就是在提升应用服务的处理能力；
3. 缓存：缓存的作用就是减少请求的访问链路和过程耗时，降低耗时就是在提升单位时间内应用服务的处理能力；
4. 限流：控制访问应用的流量在系统承载范围内；

1. 1. 在业务请求入口（网关）限流，避免内部互相调用放大流量；
   2. 限流是个演进状态，从连接池、IP、指定SQL到更细的层级粒度做限流；
   3. 每个调用层都做限流，每个应用先保证自己可用，对其他依赖调用要做到“零信任”；

5. 降级：强依赖通过熔断做紧急处理，弱依赖提前主动降级；

1. 1. 主动降级：提前进行风险识别，然后针对性降级，可降低已知的风险；
   2. 紧急降级：假设出现重大的问题，才需要决策是否启用的方案（风险较大）；
   3. 预案平台：预案平台的目的是留痕，方便后续把限流降级等配置恢复回来；

6. 熔断：熔断下游强依赖的服务 ；

1. 1. 例如：双11零点前半小时， 动态推送，把日志关掉；
   2. 真正流量来的时候，留一台机器来观察错误和异常的日志；

7. 隔离：通过身份识别做好核心/非核心业务隔离；

1. 1. RPC group分组：假设有100个节点，40个给核心业务(交易)，60个给其他业务；
   2. 业务身份：中台架构可通过业务身份把订单秒杀等应用打上标记，便于隔离区分；