容量规划：基于历史 + 业务预测

公式简化版：

明天该有多少容量 ≈ 当前峰值 × (1 + 增长率) × 余量系数

要素：

当前峰值：metrics 出来的实际峰值（CPU / 内存 / QPS / DB 连接）
增长率：业务方预估的下季度 / 半年增长
余量系数：突发流量、活动促销、报表跑批等不规律高峰

经验：给自己留 50%–100% 余量——业务突然涨 + 运维出错 + 故障转移容量需求都是这层吸收的。

压测（Load Testing）

容量规划离不开压测——不压测的"理论容量"几乎一定错。

主流工具：

工具	模型	备注
k6	JavaScript 脚本	Grafana Labs 出品，开发者友好
Locust	Python 脚本	分布式好用
JMeter	GUI / XML	老牌，重
wrk / wrk2	C 命令行	极简极快，适合微基准
Gatling	Scala DSL	报表精美

k6 例：

// k6 script
import http from 'k6/http';
export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 0 },
  ],
};
export default () => http.get('https://api.wadely.com/health');

k6 run script.js

压测时同时盯应用 metrics + DB metrics + 网络——瓶颈通常不在你猜的那里。

自动扩缩容

类型	作用
HPA（Horizontal Pod Autoscaler）	Pod 副本数随负载自动调整（K8s）
VPA（Vertical Pod Autoscaler）	Pod 资源 request/limit 自动调整
Cluster Autoscaler / Karpenter	Node 数量自动扩缩

实操：

# K8s HPA 例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp
spec:
  scaleTargetRef: { kind: Deployment, name: webapp }
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

⚠ HPA 要配合资源 requests 配得合理——request 设太高 = HPA 永远不触发；太低 = Pod 抢不到资源。

FinOps：成本工程化

FinOps（Finance + DevOps）是把云成本治理变成持续工程实践。FinOps Foundation 是这个领域的事实标准社区，由 Linux Foundation 旗下托管。

三个阶段（FinOps Framework）：

1. Inform（看清）：账单可见、成本归属（哪个团队 / 服务）
2. Optimize（优化）：找浪费、调资源、买预留
3. Operate（运营）：做成持续机制

看清：从混乱账单到结构化

每家云商都有：

AWS Cost Explorer / Cost and Usage Report
GCP Billing Reports / BigQuery export
Azure Cost Management
阿里云费用中心
腾讯云费用账单

但默认视图通常按服务划分而不是按业务团队。要做的：

打 tag：每个云资源都打 owner/team/env/service tag
导出账单到 BigQuery / Athena 之类做自定义分析
每月"成本周报"：发给团队 / 老板，让数字可见

第三方工具：

Kubecost：K8s 成本可视化（按 namespace / Deployment）
CloudHealth / Spot.io / Densify / 各云商自家平台：跨云成本管理

优化：常见浪费

成本浪费 80% 集中在几个模式：

预留实例没买：on-demand 价格通常比 1 年预留贵 30%–60%（具体看产品和地区，看官网）
Spot / 抢占式没用：能容忍中断的工作（批处理 / CI / 实验）→ Spot 显著便宜
跨可用区流量：不必要的 cross-AZ 调用 → 流量费滚雪球
僵尸资源：人离职 / 项目停了的 EC2 / EBS / 弹性 IP 还在跑
存储分层：冷数据放标准存储 → 用归档层
过度配置：HPA 上限拍脑袋设大、VPA 没调
日志过度保留：日志保留几年 + 索引贵 → 短热 + 长冷分层

运营：把成本治理变成日常

每个团队自己看自己的账单（不再是"运维统一交"）
新服务 review 时估算成本（在 RFC / ADR 里写一栏）
成本异常告警（环比超过 X% → 通知）
专人或委员会每季度过一次大头花费

几个常见坑

完全 on-demand：错过预留 / Spot 优惠
用 NAT Gateway 跑大量流量：NAT 流量费贵
Cross-AZ DB 复制流量：每月几千美元的故事不少见
不限制 dev 环境配额：开发跑大集群忘记关
存储默认未做分层：冷数据用标准存储

系列结束 🎉

「公司运维」36 篇全部完成。

加上「快速搭建」15 篇，运维系列共 51 篇。从买台 VPS 到能撑公司 IPO 的运维体系，地图基本完整。

下一步可以：

把任何一篇深挖（每篇都能扩成一本独立的书）
在做实际项目时回头当 checklist 用
有新工具 / 新模式时回来更新

运维不是装好工具就完事——是长期适应业务变化的能力。

容量规划 + FinOps 入门