【DevOps系列】容量规则平台

1. 什么是容量？

对于我们在线业务系统，容量可以定义成：单位时间能够承受的最大业务量。

比如形象点说：某个电商平台在0点秒杀最大能够承受多少QPS的量。

2. 一般业务系统线上容量会有哪些问题

a. 容量不透明

线上容量很容易进入黑盒状态，没办法确定线上容量到底处于什么状态。

针对单个应用来讲，判断当前的容量状况，需要运维同学查看这个系统实时的负载情况（比如CPU、Load等指标），然后凭经验大概判断下这个系统压力大概处在什么水平上，再得出结论；要判断当前这个容量是否足够支撑平时的业务量，可能还需要查看整个系统最近一段时间（比如一周/一个月）内，负载的变化情况。

单个应用的容量评估都这么费力，那如果是一个完整的业务调用链那就更是难上加难了。

b. 容量不流动

如果站在单个应用的角度来看，健康的状态是系统容量处在一个合理的区间内波动，容量太少了，会导致系统承受不住正常的业务压力，对业务有损；容量估的过多，就会造成严重的资源浪费。

这样会导致什么情况呢。真实的一个案例，有一个应用只有2台机器，非大促时CPU>60%以上持续跑了一段时间，想扩容的时候发现没有资源了，也出现过一个系统放了很多机器，而CPU利用率只有5%不到点，导致了非常严重的资源浪费。

容量不能透明出来，有限的资源不能放到合理需要的地方，这就会造成资源的不合理利用。

c. 容量管控不自动

比如业务需要搞一个促销活动，里面涉及到了A、B、C等多个系统。

A系统负责人说：“A系统需要加X台机器”

审批人：“为什么需要加机器”

A负责人说：“最近要搞促销，我们系统评估了下需要加这么多机器”

审批人：“好，你发个邮件说明下原因”

这个时候B、C负责人也跑过来说需要加机器，理由是因为他们是A系统的下游系统，A扩容了，自然而然B与C也需要扩容相应的资源。

这种资源跟进方式偏人肉，需要投入大量的人力与时间成本，效率也低。

二、关于容量规划平台的一些思考

既然上面容量问题有这么些问题，那是不是可以搞一个容量规划的平台来解决这些问题呢。

这个平台要解决的问题：让容量可视（数据化说明问题）、可控、可调度、减少人力成本、提升资源利用率。

这个平台的目标：透明线上容量（哪个应用当前的水位多少、用了多少台机器、成本多少需要一清二楚）、自动调整系统容量（这个就是所谓的弹性扩缩，系统会自动识别当前的水位情况，结合一些算法比如预设的阀值，流量预测，高低峰机器数等，自动进行决策）、打通资源管控层，搞个最优的调度方案出来。

两个关键字：保稳定、降成本