01 | 容量保障的目标：容量保障的目标是什么？该如何度量？

作者回复: 赞，回答完全正确！这个问题的重点在于要考虑到其他页面和链路的调用流量，实际情况中这一块流量是不会直接告诉你的，你需要在梳理相关链路时留意到这一点

作者回复: 我们在制定容量保障的目标时，容易形成的思维定势是从技术指标的视角出发，例如：某个接口要支撑多少TPS、某个服务的SLA要达到多少等。但这些技术指标是怎么来的呢？是根据业务目标转换而来的，是根据竞争对手的水平类比过来的，是根据行业通行标准演化出来的，还是从用户体验角度去考虑的呢？ 软件产品做出来是给人用的，用户体验应当作为容量保障的初心。其实指标还是那些指标，只不过出发点是用户体验，可以品一品。

作者回复: 你好，非常欢迎提供不同观点，我们多多思辨。 关于第一个问题，你说的很对，决定SLA的并不只是容量保障工作，我在文中其实有提到，留意这句话：“不止是容量问题，有很多因素都有可能影响 SLA，比如：线上漏测的Bug、网络抖动、服务器断电等等，因此需要识别出影响SLA的容量问题，再判断是否满足目标。” 第二个问题，我们是依托企业自建的链路追踪系统进行梳理的，对标开源系统的话，有点类似于CAT。如果没有这个系统，仅仅依靠人工梳理会非常费时，当然了，如果企业有上千个微服务，很难想象没有链路追踪系统的情形：）

作者回复: 你好，扩散比的计算本身是不困难的，我们可以先梳理出压测链路，再梳理出这些链路中上下游接口的调用比例，综合起来就得到了扩散比。 难点在于，如何完整无误的梳理出所有压测范围内的接口的扩散比，依赖手工统计的方式往往是吃力不讨好的，我们可以基于链路追踪系统来提供素材（链路及接口调用信息），采样高峰期（或典型业务期）的数据，汇总后得到结果，当然，也可以编写脚本对这些采集到的链路做一些初步的去重，节省手工汇总的工作量。 对于新的业务或功能，可以在上线前根据技术方案先期整理出接口扩散比，减少后期梳理的工作量。