B. 智能运维 --- 成本优化 --- 容量规划
概述
核心：成本和性能
作用
判断现有系统规模还可以再承载多少流量
对于新增的流量，采购设备时给予指导，花最少的钱办同样的事
流量切换时可以量化
优化服务规模
目标
节省成本
节省人力
前提条件
多少业务，业务量是多少，对应到各个系统的调用量
查询量/数据量
如果出现应用故障，业务的影响面是多少
不同的业务量下，给出容量规划，帮助进行业务评估
步骤
明确目标
收集指标
趋势预测
容量部署
资源
资源
问题
异构机器
有些机架电力不限
有些机架网络不限
资源
CPU
内存
磁盘 容量/DiskIO
网络
同一个服务不同请求所需要的资源不一样
服务类型
计算密集型：CPU
对于计算型业务，如游戏行业，其主要业务就是游戏引擎的计算，主要用CPU支撑；
数据密集型：数据密集型业务也称为DataIntensive，主要体现在大数据应用中，比如著名的搜索引擎就是从海量数据中找到有用信息，通常这类业务非常占用内存资源。缓存也是数据密集型业务，如squid、varnish，典型的应用就是cdn，cdn本质上就是个cache，它将请求的结果缓存到内存中，避免将请求转发到源站。
IO密集型：网络、磁盘
存储型业务，如百度网盘，其主要业务就是存储用户的文件，计算机资源的度量就是存储空间；
对于流量型业务，如优酷，它的主要业务就是通过网卡传输视频文件，主要就是消耗网卡及网络带宽。
同一个服务不同请求或者不同服务不同请求之间所需要的资源差异有可能非常大
方法
离线方法
压力测试：QPS、TPS --- 数据模型
第一个维度，压测粒度
单机压测
单链路压测
多链路/全链路压测
第二个维度，压测接口及流量构造方式
线上流量回放
线上流量引流
流量模拟
第三个维度，施压方式
第四个维度，数据读写 --- A/B测试
在线方法
通过监控扩容
扩容的前提是压力趋近于模块的极限，如某模块每秒最大处理的请求数（qps）是300个，当实际qps接近于250左右时就要考虑扩容了
判断是否区域极限值的方法
在程序的日志文件中增加请求处理时间的字段，这样针对每个请求的处理时间我们便清楚了，如果任何页面的处理时间太长的话就要考虑扩容了。这里所说的处理时间长度没有固定的大小，还是要和业务结合，
大多数模块都会有请求超时的设置，例如某模块设置了请求的最大处理时间是30秒，超过30秒的请求会在日志中写入报错信息，一般会有warning、error或fatal等关键字，我们可以在监控日志中匹配这些关键字来统计单位时间内因超时而报错的请求数，当达到某个极限值时就表示离扩容不远了。
切线上流量，但是要希望一部分的用户体验
预测
基于当前应用的历史数据做预测
同类型的应用预测
最大值/最小值/平均值/分位数
传统容量规划
步骤
收集对未来项目需求的预测需要多少资源？这些资源什么时候需要，以及它们需要在什么物理位置？
使用我们几天拥有的最佳数据来计划明天
预测长度一般都是几个季度到几年
制定资源的采购，构建和分配计划
评审，并且批准这个计划
部署和配置对应的资源
缺点
不可靠性
耗时巨大，同时不够精确
基于意图的容量规划将服务的依赖和资源的参数用编程的方式记录下来，同时利用一个算法自动产生资源的配给方案，包括在哪个集群中将多少资源配置给哪个服务这些细节。
如何表述
抽象一：我需要50个CPU资源，必须在集群X, Y, Z中，为服务Foo使用
抽象二：我需要50个CPU的资源，在地理区域YYYY中的任意三个集群中，为服务Foo使用
抽象三：我想要满足Foo在每个地理区域的需求增长，同时保障N+2冗余度
抽象四：我们想要将Foo以99.999%的可靠度运行
表达产品意图的先导条件
依赖关系：依赖哪些基础服务，并且这些基础服务提供多大的延时。这些限制性条件，决定了应用服务部署的位置。
性能指标：相关性能指标信息需要通过压测获得
优先级：在资源受限的情况下，有限保证哪个服务哪种级别的服务
Auxon：容量规划服务
组件
数据信息：描述某个服务的规模化能力既可以通过压力测试获得，也可以从过去的性能数据中得出
每个服务的需求预测数据：描述了针对服务的需求预测信息。针对需求的预测信息推断资源使用量，但不是所有服务都能这样预测需求。
资源供给：提供基础资源的可用性。
资源价格：提供基础资源的成本信息。
意图配置信息：定义了每个服务，以及服务之间的依赖关系。
Auxon 配置语言引擎：把配置信息获取的信息，转换成机器格式，也就是Auxon求解器所需要的Protocal buffer格式
Auxon求解器：庞大的混合整型线性规划程序。这个程序可以在几百台甚至几千台机器上进行并行求解。
资源分配计划：结果输出
项目推广
设置期望值：既要满足客户基本需求，又做不到全部满足（避免对1～2个大型客户过度定制而失去了通用性）
识别合适的客户
争取客户支持