你好，我是吴骏龙。今天我会与你探讨一下小公司如何做好容量保障。
首先，我想先明确一个前提，那就是小公司到底要不要进行容量保障，很多人会觉得小公司进行容量保障的必要性不大，理由无外乎有：
我的观点是，是否要进行容量保障，和公司“大”与“小”无关，而是与业务形态和发展趋势相关。
我经历过一家初创型的电商公司，这家公司在早期整个技术团队不超过30人，服务都是单体应用的架构，业务以到家的形态为主，基础设施用的也是某大厂的云设施。传统认知上，这是一家典型的小公司，但随着业务的不断发展，业务高峰期间系统服务的压力越来越大，经常发生服务稳定性的问题，以至于高层很快决定将容量保障列为了技术团队最重要的工作之一。
这个例子完整的解答了对于容量保障工作必要性的讨论。
首先，是不是要做容量保障，和公司的规模其实没有什么关系，而是和公司的业务特点有关，比如我在开篇词中曾提到的一个关于某企事业单位内部系统的例子，它的用户量和用户群体都比较稳定，业务场景几乎不变，虽然这个单位的人员规模很大，容量保障的意义也比较有限。相反，如果是面向外部用户的互联网系统，业务场景有明显的流量峰值，再小的公司也一定会进行容量保障，只是做法不同罢了。
其次，容量保障和质量保障是同等重要的，因为它们都有可能会影响到服务的可用性，最终影响用户体验。两者之间不是“有你无我”的关系，而是“既要也要”的关系。
弄明白小公司进行容量保障的必要性以后，我再来解读下一个问题：如果你的公司规模不大，在容量保障工作中无法投入太大的成本，有没有什么经济实用的方法可以操作呢？答案当然是有的，下面我分别从四个不同的角度，具体展开讲解。
对容量保障工作来说，投入和产出一般是呈正比的，在投入有限的情况下，我们自然不可能做到面面俱到，这时候就要抓大放小，去做那些性价比高的事情，适当牺牲掉一些细节，这就是粗放式保障的思维。
那具体怎么去实施呢？或者说，哪些环节可以粗放式保障呢？我可以给你一些启发。
在服务容量的观测能力方面，对容量指标的监控告警就可以是粗放式的，你可以针对服务的各项容量指标划定一个警戒值，比如CPU利用率≥80%，响应时间99线≥500ms，成功率≤95%等，超过警戒值后，监控系统直接发出告警。
在我的经验里，大多数线上容量问题都是可以通过这些指标数值上的简单对比，在第一时间感知到的，性价比很高。而从另一个角度，对于那些趋势型的指标监控，还有带有业务语义的监控，实现的成本高，还要理解业务逻辑，就可以次要考虑。
容量测试也是一样，没有条件做全链路压测怎么办？那就加强基线容量测试，如果基线容量测试还没有人力去做，那就直接在生产环境的服务灰度阶段，通过对响应时间等指标进行同比，来发现容量隐患，这种变相的基线容量测试也可以一定程度上发现一些高危问题。发现问题后，可以先回滚服务，再对容量隐患进行排查，修复后重新上线。
粗放式的容量保障并不是无谓地放弃一些工作，而是有策略地选择性价比高的“大头”去优先保障，以较低的成本堵住最严重的容量风险。
如果你的公司的业务流量是有明显的高峰期和低峰期差异的，那么你就不得不面对容量保障里很头疼的一个问题，为了保证高峰期的容量充足，必须维持一定规模的服务器资源，但到了低峰期，这些资源又很富余，显得很浪费。无论公司大小，只要是类似的业务流量形态，都会面对这个问题。
小公司一般不太会投入重金去建设自有机房，使用云服务厂商提供的服务资源是普遍做法，幸运的是，各大云服务厂商都提供了一些机制，帮助我们节省容量保障的成本，而且几乎没有什么侵入性。
比如阿里云就提供了“停机不收费”的服务，通过计算力与存储分离的方式，我们可以将指定的计算资源在需要的时间段释放，同时保留存储内容，下次开机（即恢复计算力）时可以继续使用。对你来说，这就相当于在低峰期对服务进行缩容，你所要做的，仅仅是评估出在低峰期缩掉多少资源比较安全，这个成本是不高的，因为不需要很精确，而且可以演练。
那么，如果遇到大促活动，在成本有限无法实施精确的容量预测和容量规划的情况下，你也不想提前冗余很多的服务资源，这时候有什么好办法吗？
正如我在“云原生下的容量保障新趋势”一讲中所提到的，云服务商也提供了弹性伸缩的服务，通过设置伸缩规则，在业务流量增长时能够自动增加实例，以保证计算力充足，反之则自动缩减实例。弹性伸缩是可以计量收费的，也就是说，伸缩机制本身不会收费，只有实际创建的实例才会收费。
弹性伸缩机制对容量保障的成本节约主要体现在，它将一部分容量预测不准确所带来的潜在风险，用云基础设施的能力去承载。这有点像是买保险，用一个大池子去分摊个体的风险，对个体来说，只需要支出很少的费用，就能获得较大的保障。
我们处在一个拥抱开源的繁荣时代，开源已经不仅仅是个人爱好的驱使，很多优秀公司都在通过开源的方式宣传和完善它们的产品。用好开源工具，不但能节省成本，还能推动行业的发展，毕竟，你也是开源的一份子。
在容量保障工作中，很多环节都是可以利用开源工具去实施的。最典型的，容量测试可以使用JMeter去完成，这是老牌的开源压测工具了，功能非常丰富，还支持通过插件扩展，纵使它的阻塞式IO施压模型较为陈旧，对资源消耗较大，但在并发量不大的情况下，这部分的劣势其实并不显著。相反，JMeter强大的可扩展性，加上开源社区的支持，极大的降低了使用者的成本。
在容量预测和容量规划工作中，对服务容量建立模型的过程，也可以借助开源工具完成，常见的有TensorFlow、PyTorch、Spark MLlib等工具，小到多项式拟合，大到神经网络，都有现成的封装，这样你就可以把精力完全投入在调参和验证上了。
当然，开源工具的社区维护特点，决定了它不太可能快速支持一些特殊的定制化需求，如果这种定制化需求是你的刚需，那么建议可以考虑自己进行二次开发，相比于完全重新去编写一个工具，附加值依然是很高的。你会发现，很多大厂在工具建设的早期其实也是遵循这个思路的，比如京东的全链路军演系统ForceBot的第一代就是基于nGrinder定制的，360的性能云测平台大白是基于JMeter定制的，等等。
如果你公司的业务不是特别敏感的话，将容量保障工作外包，也不失为一种简单粗暴的方法。大型云服务商和一些专业的独立咨询机构，都有提供类似的服务，会有专属的团队介入对齐目标，分析容量现状，实施容量规划和验证，最后交付验收。花点钱，都帮你搞定了。
不过，如果你公司的业务流量在平时始终存在明显的峰谷特征，那么容量保障就是需要长期进行的常态化工作。在这种情况下，我个人就不太建议采用购买解决方案的方式了。
因为要做到可持续的容量保障，所有技术人员都必须具备良好的“容量意识”，比如在编写代码时就要考虑到高性能，在架构设计时就要考虑到减少容量瓶颈，等等，而容量意识是需要技术团队在实战中锻造出来的，甚至要经历过一些教训才能成长，这是购买解决方案所无法带给你的。
今天我主要与你探讨了如何在小公司建立经济实用型的容量保障体系。需要明确的是，要不要做容量保障，与公司规模大小其实关系不大，而是和业务形态和业务特点有关；而怎么做容量保障，会关系到成本和人力投入，小公司可以有小公司的做法。
粗放式保障是小公司进行容量保障的基调，抓大头放小头，采用性价比最高的方式，堵住最可能发生的容量隐患。然后可以逐渐再去覆盖次重要的容量保障部分，慢慢地精细化。容量保障的各个方面都可以采取粗放式保障的思路，在这一讲中我列举了容量观测和容量测试的实践案例，你也可以思考一下在容量保障的其他环节怎样抓大放小。
各大云服务厂商针对服务容量提供了丰富的调整策略，“停机不收费”和“弹性伸缩”是目前应用得比较多的策略，合理利用这些策略，不仅能够保障容量安全，还能最大化地节省费用，降低投入。
在开源时代，容量保障工作的方方面面几乎都有各种开源工具能够支持，由于小公司队伍精简，组织扁平，对于工具平台化的需求一般不高，因此针对开源工具进行简单的二次开发，基本能够满足使用，性价比较高。
最后，如果容量保障不是日常需求，那么一次性投入购买解决方案也不失为一种选择。但如果公司的容量保障是长期工作，那么还是应当脚踏实地的做好积累，提升容量保障的技术水平和全员意识。
如果你恰好身处小公司，希望今天的讲解能够为你带来一些容量保障建设的落地思路；如果你身处大型公司，也希望今天的内容能够为你打开不一样的眼界和领悟。
今天我们聊到了不少粗放式容量保障的方法，你觉得容量保障还有哪些环节是可以循序渐进，逐步从粗放式发展到精细化的呢？欢迎与我分享你的想法和经历。
评论