服务器成本优化
背景
2021.11月会上，在公司开源节流方向指引下，技术委员会执行小组提出将成本优化作为2021Q4的重点项目跟进，服务器成本作为其中重要的一项，需要在公司层面提供一套可行的标准和方案，供业务线制定各自的计划并落地。
现状
概要：
- 总成本TOP3：短信、号码、电商
- 腾讯云已支撑公司大部分业务
- 云产品成本TOP3：主机、带宽、Redis
- k8s主机：cpu 30%+；内存 50%+；硬盘 25%+
- 大数据主机：CPU 70%+；内存 70%+；硬盘 50%+
- 非容器主机：参差不齐
- 带宽：按流量计费
- Redis：超大型redis治理
问题
- 公共平台在推动服务器优化的过程中，标准不明确
- 业务线暂未制定各自服务器成本的核心指标
- 执行过程中，公共平台角色错位，导致冲突
- 公司层面没有将服务器成本优化与绩效考核挂钩
调研
服务器利用率
调研了国内的几个大厂，基本上都有自己的一套定义服务器利用率的方法，然后根据利用率的情况进行治理。
- 腾讯：CPU周峰值：低于45%需要治理。
- 美团：MAX(cpu_util,net_util,io_util,disk_util,mem_util)，低于20%需要治理。
- cpu_util：10秒种一个点，每1分钟取该分钟内6个点中最大的一个，将每分钟内最大的点从大到小排列后在一天的1440个分钟里取最大的60个数，求平均。
- mem_util: 1分钟一个点，取TP90，也即90%的时间低于此值。
- io_util：max(disk.io.util)，选用io_util最大的块设备取值。
- disk_util：磁盘空间利用率
- net_util：对于物理机，net_util = traffic/网卡工作带宽；对于虚拟机，net_util = traffic/最小保障带宽。其中最小保障带宽为宿主机网卡工作带宽/VM个数。
- 滴滴：最近30天，CPU平均利用率≤5%，峰值≤30%，进行降配；内存使用过低（目前无原则），考虑降配；业务偶发高峰，可不降配。
- 新浪：服务器利用率（CPU/内存/硬盘/网络/成本综合考虑，具体公式不详）≥45%
业务成本核心指标
- 单订单成本（电商类）
- 千元收入成本
- 百万请求服务器成本
标准讨论
服务器利用率
- 生产环境：在不影响业务开展需要的TP999/SLA的情况下，综合考察利用率
- 虚拟机：cpu利用率30%60%之间，内存利用率处于40%70%，数据盘利用率30%~60%之间
- k8s的node节点，由公共平台负责
- 非k8s服务器，由对应业务方负责，公共平台负责提供监控数据
- redis：日常峰值QPS≥30% || 内存≥50%，默认最低规格，有需要随时扩容
- mysql：日常峰值QPS≥30% || 存储 ≥30%，默认最低规格，有需要随时扩容
- mongodb：日常峰值QPS≥30% || 存储 ≥30%，默认最低规格，有需要随时扩容
- elasticsearch：日常峰值QPS≥30% || 存储 ≥30%，默认最低规格，有需要随时扩容
- kafka：日常峰值QPS≥30% || 存储 ≥30%，默认最低规格，有需要随时扩容
- 大数据：考察报表时间段资源利用率
- CPU：60%~90%
- 内存：60%~90%
- 硬盘：75%~90%
- 算法策略：原则上满足模型运算需要最低规格
- 虚拟机：cpu利用率30%60%之间，内存利用率处于40%70%，数据盘利用率30%~60%之间
- 开发测试环境：对利用率不作要求，重点控制规格
- 服务器：原则上单机不超过2C4G
- redis：原则上最低配
- mysql：原则上一个业务线一个最低配实例，业务线内混用
- mongodb：原则上一个业务线一个最低配实例，业务线内混用
- elasticsearch：原则上全公司混用一个最低配实例
- kafka：原则上全公司混用一个最低配实例
- 大数据：原则上提供最低配的大数据集群
- 算法策略：原则上集满足最小数据模型需要最低规格
- 压测环境
- 压测目的：①找出系统瓶颈；②压出系统容量。建议以目标①优先
- 尽量在测试环境完成压测，有需要临时升规格，原则上使用不超过2周
- 生产环境压测应做好隔离，周知基础架构和上下游
核心成本指标
- 公共平台：
- 支撑成本：每百万请求公共平台成本（除去大数据、gitlab、wiki、jira、sso之外分摊成本）
其他
角色定位
- 技术委员会：标准制定
- 公共平台：指标监控
- 业务方：成本第一责任人