为什么做这样一个产品之容量评估篇

时间过去了快 1 年了，但其实还是会有人问我，你们公司为什么会想到做这样的产品。

其实我在 2020 年曾经写过一篇文章 从产品的本质，谈谈生产环境的全链路压测 。

将近一年的时间里面，我见到了更多的客户和更多的场景，所以想再谈谈产品所解决的问题有哪些（价值）。

有几个情况

非互联网行业的头部大佬，都在拥抱互联网化，通过在线的系统来触达和服务海量的用户。同时，会出现这样的情况:

业务系统越来越复杂

所使用机器越来越多，成本越来越高

微服务的数量越来越多

用的组件也是越来越多

开发人员也是越来越多

涉及到的角色越来越多

这样的一个背景，会面临灵魂拷问：

IT 系统真正能扛住多少的业务量？还有多少冗余？

如果明年业务翻一番，IT 系统能否扛住？如果要扛住这么多业务，要准备多少机器的预算？

预算是否精准？是怎么核算出来的?

曾经亲眼目睹过几个客户在申请机器预算的时候，有类似这样的场景。

IT 团队：xx 新业务要上线，量比较大，需要 200 台应用的虚拟机。

负责分配资源的团队：好的，你们 200 台的依据是啥？，我们也要给老板汇报的，没办法给你这么多，还是先给你 50 吧。

IT 团队：这不行啊，会出问题的啊，你还是多给我们一点吧。

资源团队：出问题了会咋样啊？

IT 团队：那如果是这样的说法，出了问题，责任大家要一起均分才行。

资源团队：你们都没法评估出来量是多少，以及精确的是多少，这样我们也很难做啊。

宝贵的时间就在诸如此类的过程消逝了。。。

在和客户合作了后，会带来一些新的变化。有一些这样的例子。

业务团队：这个业务需要支撑 xx 量级的用户操作，包括读和写，需要系统在满足功能的同时，确保平稳运行。

IT 团队：好的，我们最终会在生产环境上进行仿真流量的验证，这是我们的流量模型 xx 量级的用户读操作，xx 量级的用户写操作

IT 团队进行仿真流量的验证，提前发现了 xx 个存在的问题，并进行了修复和预案的操作；同时在资源层面，当前的资源只能支撑 xx 量级的业务。

IT 团队：当前资源只能支撑 xx 量级的业务，如果需要扩容，需要业务团队和资源团队一起沟通必要性。

业务团队：好的，先以这样的容量来支持业务。但你们需要能确保在业务增加的时候，可以快速弹性扩展，把问题控制在小范围内。

我们会发现，彼此的协作方式，发生了变化 。。。