基于回归分析算法实现应用服务容量管理的实践结论，期待交流

1.为什么要写这篇文章

目前业内诸多实践案例都曾采用回归分析的思路实现应用服务容量管理，我也是其中之一。在长期的实践过程中，发现了该方法的诸多问题，但是这些问题在曾经的分享中未被提及，这是为什么呢？这些问题曾一度让我怀疑该思路的正确性。（甚至有想要对业内喊话否定该思路的冲动想法）。所以迫切的需要与业内一些实践者共同探讨，解决问题，加速双方在容量管理领域的能力建设。

#如果你没有实践过，可以直接跳到第四章节

2.实践结论与抛出的问题

2.1 你们是否也建设了单机引流压测平台？验证单机容量。（在滴滴的实践中，曾用引流压测验证单机容量，回归分析思路虽然对业务无侵入，但从滴滴实践来看，额外的平台建设成本也不小）
2.2 经过单机引流压测你会发现这样一类应用——计算密集+缓存型，此类型应用会随着CPU利用率增长而拥有更强的响应能力，无法采用回归分析思路实现容量管理。（此类应用否定了回归分析的实践）

2.3 流量模型发生变化会导致预测值与实际值相差变大，而业务场景一旦发生变化意味着流量模型发生变化，那么之前的容量模型将失去预测的意义。（对于业务场景经常发生变化的应用，也否定了回归分析的实践）

2.4 对于哪些历史样本数据不满足回归分析需求的应用服务，是如何进行容量管理的？例如R平方小于0.5、或CPU趋势随机波动、样本数据值太小。

2.5 回归分析思路是否也可以应用到其它架构组件实现容量管理？例如专线带宽、MySQL、Redis等组件。

2.6 基于回归分析实现的容量管理，与全链路压测是如何共同决策应用服务容量的？（矛盾点是两者流量模型可能不一致，同一个QPM容量目标下得到的所需设备量相差很大）

2.7 当一个应用max_QPM，与P90_QPM，相差数倍时，在进行容量规划时，你会以那个为准？决策逻辑是什么？

2.8 同一个应用服务下资源利用率不均衡，你们是如何处理的？
2.9 个别应用服务提供服务的方式是定时、偶尔访问量极高，你们会要求业务削峰填谷吗？他们会处理吗？
2.10 个别应用服务仅提供少量服务，资源接近空跑，你们会要求业务合并此类应用吗？
2.11 在生产环境中，哪些场景需要调整容器的limit、request值为不一致状态？

2.12 云原生背景下，资源交付速度非常快；那么是否还需要这种计划型、提前规划型的容量管理方法呢？如果不需要，那么正确的方法又是什么呢？

3.私信交流

对上述问题感兴趣的实践者可以随时私信我，次日必答复。期待我们的交流。
#最好是已实践者

4.推荐资料（想要用该思路建设容量管理平台必看的资料，已做过筛选）

京东（叶传伟-2020）：https://wenku.baidu.com/view/d7527ad365ec102de2bd960590c69ec3d5bbdba5.html?wkts=1724560655617
百度（郑刚等人-2016）：https://item.jd.com/10534157282.html、https://item.jd.com/55251554844.html
滴滴（张晓庆-2019）：https://cloud.tencent.com/developer/news/490098
携程（陈剑明-2016）：https://zhuanlan.zhihu.com/p/25341948
58集团（龚诚-2021）：https://www.modb.pro/doc/31407
容量保障核心技术与实战（吴骏龙-2021）：https://time.geekbang.org/column/article/372509