容量保障落地四步走
上一篇文章介绍了容量保障和容量测试的基本理念和特点，有同学私信我说希望介绍更详细的落地步骤。
这篇文章，结合我自己的实践经验和其他人的应用实践，为大家介绍下容量保障落地的几个步骤和注意细节。
一般来说，无论是什么技术项目，都可以拆成这几个步骤来落地：
- 明确目标和衡量结果的指标；
- 制定落地实施方案并进行验证；
- 针对验证结果进行分析是否达到预期；
- 项目完结后不断复盘迭代进行维护优化；
因此容量保障在实际工作中落地也可以遵循这几个步骤，下面的内容我也会从这几个方面来说明。
明确容量保障的目标和指标
任何项目在实施前都需要明确目标和衡量指标，否则很容易失去方向，最后的结果也会南辕北辙，容量保障也不例外。
同时要明确一点：任何技术都是为业务服务的，技术要支撑业务目标更好的达成，业务目标达成才能体现技术的价值。
那么容量保障的目标是什么？我认为是如下两点：
- 降本：在保障线上业务稳定运行的情况下降低保障的成本（容量规划）；
- 预防：解决已知的线上容量问题，提前进行风险评估预防未知的问题（容量治理）；
我在之前软件工程相关的文章中提到过，要做到更好的质量保障，要考虑三要素：范围、时间、成本。
同理，要做好容量保障，成本因素是不可忽视的问题。这里的成本主要指硬件成本、人力成本以及协调沟通成本。
因为基于硬件部署的服务其本身的性能受制于物理硬件制约，所以成本因素是首先要考虑的。
同时，为了应对线上的一些突发情况或者其他因素，要保障系统可以有弹性的处理能力，因此系统的资源使用率也要保持在一个“安全水位”。
这一点在互联网业务特别是电商大促是一个很典型的例子。
以我之前经历的项目而言，类似电商大促“安全水位”都是保持在40%左右，当然控制的好可以提升为50%（这又是容量治理的范畴了，而且要考虑到一些预案的作用比如限流降级熔断）。
确定了降本和预防的目标后，要针对目标进行量化，以确保目标可以有效达成。如果目标不能量化，那本身就难以实施。
常见的量化指标有如下几种：
- SLA(服务等级协议)：主要是 SLI+SLO。详细内容请我之前的文章:《SRE实战手册学习笔记之切入SRE》；
- QPS/TPS/99R/Error%：这些关键指标表明系统能否在业务可接受范围内支撑预期的流量并且成功率较高；
- 用户体验：这看似是一个定性的描述，其实可以拆解为几个更详细的指标和改进措施，举个例子：
之前公司的APP在访问商品详情页超时时会在页面放一个刷新按钮，用户可以不断点击，这其实相当于用户的未成功请求在不断重复，很影响用户体验。
我们是怎么优化的呢？首先在类似商品详情的页面加一个遮罩，如果访问超时就弹出友好提示，并且在网关层进行合理的限流。这样即降低了系统的实时压力，也提升了用户下单时的感知体验。
容量测试如何进行实施验证
确定了容量保障的目标和量化指标之后，就可以针对性的进行实施验证，这个实施验证过程也称之为容量测试。
上篇文章《容量测试解决了什么问题》已经介绍过容量测试的概念了，这里重点说明下容量测试的几个主要实施步骤：
确定容量测试实施范围
容量测试在落地初始阶段，建议小范围开展，这样可以更快验证和有效反馈，因此确定测试范围是很有必要的。
确定测试范围一般可以从如下两个角度切入：
- 故障驱动：即出现了容量问题，针对性进行验证；
- 风险驱动：评估容易出现问题的风险点，将其纳入容量测试范围。常见的风险点如下：
- 关键路径上的关键服务：比如电商的订单、库存、支付服务；
- 有明显峰值流量的服务：比如秒杀、限时抢购、抽奖等服务；
- 对时延比较敏感的服务：一些底层或公共技术组件比如网关；
- 资源利用率较高的服务：比如搜索/推荐服务对内存要求比较高；
- 其他：新上线服务、已经存在风险的服务、历史经常发生故障的服务；
科学合理开展容量测试
一般来说实施容量测试的步骤和常规的压测没什么区别，主要的步骤也无非如下几项：
- 设计测试方案；
- 测试方案评审；
- 前期测试准备（比如脚本和数据）；
- 容量测试执行；
- 测试结果记录分析；
- 不断复盘持续改进；
有一点需要明确的是：容量测试是一种验证手段，不是测试手段（即先设计高性能高可用的服务，再通过容量测试去验证是否达到预期效果。而不是反复测试找性能瓶颈再想办法优化）。
针对验证指标进行容量分析
其实容量测试的结果分析方法和性能测试没啥区别，没有需要特意说明的，不过这里还是列举几点注意事项供参考：
- 响应时间：相比于平均响应时间，更应该关注分位线，比如95rt，99rt；
- 请求&业务成功率：性能测试追求的是更高的tps和更低的rt，但是所有的技术指标都是建立在业务成功的基础上（举例：下单接口状态码返回200，但业务提示未查询到库存，这就是典型的技术正确业务失败(未成交)）；
- 资源使用率：常见的有cpu%和memery%，很多同学认为要降低资源使用率，其实不然。原因有如下几点：
- 不同的业务对资源的耗用和要求不同，比如搜索和推荐业务是计算密集型，常规的读写业务是cpu密集型；
- 资源使用率只是一个结果和现象，表明当前服务的某个资源并不繁忙，并不能说明其他地方不存在性能瓶颈；
- 性能拐点：这是很多同学容易陷入的误区，非要不断加压找到性能拐点。其实服务性能是否达到瓶颈，需要依靠服务端的各项指标结合业务场景去判断，而不是不断加压来判断。
- 指标抖动：这个也称之为指标毛刺，因为常见的可视化监控系统都是通过各种图表折线来展示。很多时候线上的容量故障都是由于无人在意也不明原因的“毛刺”导致的。指标出现抖动说明存在超出我们预期的情况，如果不重视，久而久之很容易出现问题。
容量治理最常见的几种方法
容量规划是容量保障的核心环节和难点，而容量治理则是一个长期持续的预防性建设工作。
容量治理从更高维度来看也是服务治理的范畴。而这些方法，又可以统称为预案（参考文章:《聊聊稳定性预案》)。
我在之前的文章中曾阐述过我的观点（参考文章:《高可用和性能优化》)：
- 性能提升三板斧：扩容、升配、加缓存；
- 容量治理四板斧：限流、熔断、降级、隔离；
这里摘取部分内容，供大家参考：
- 扩容：应用计算能力受限于硬件资源，只要应用服务具备弹性扩容的特点，完全可以用扩容来提升性能；
- 升配：应用计算能力受限于硬件资源，提升硬件资源的配置从某种程度上来说就是在提升应用服务的处理能力；
- 缓存：缓存的作用就是减少请求的访问链路和过程耗时，降低耗时就是在提升单位时间内应用服务的处理能力；
- 限流：控制访问应用的流量在系统承载范围内；
- 在业务请求入口（网关）限流，避免内部互相调用放大流量；
- 限流是个演进状态，从连接池、IP、指定SQL到更细的层级粒度做限流；
- 每个调用层都做限流，每个应用先保证自己可用，对其他依赖调用要做到“零信任”；
- 降级：强依赖通过熔断做紧急处理，弱依赖提前主动降级；
- 主动降级：提前进行风险识别，然后针对性的降级，可降低已知的风险；
- 紧急降级：假设出现重大的问题，才需要决策是否启用的方案（风险较大）；
- 预案平台：预案平台的目的是留痕，方便后续把限流降级等配置恢复回来；
- 熔断：熔断下游强依赖的服务 ；
- 例如：双11零点前半小时， 动态推送，把日志关掉；
- 真正流量来的时候，留一台机器来观察错误和异常的日志；
- 隔离：通过身份识别做好核心/非核心业务隔离；
- RPC group分组：假设有100个节点，40个给核心业务(交易)，60个给其他业务；
- 业务身份：中台架构可通过业务身份把订单秒杀等应用打上标记，便于隔离区分；
PS：注意！无论是限流还是降级以及熔断和隔离，本质上对业务都是有损的。即在尽可能保障服务可用的情况下提供业务可用，保障业务目标的达成。这是一个需要不断验证和评估投入产出比的过程。
