引言:VPS 运维的"两难困境"
无论你是运营一个博客、一个 SaaS 应用,还是跑着一堆自托管服务,VPS 的资源管理始终是个头疼的问题:
- 资源不足:流量突然暴涨,CPU 打满,服务挂掉,用户流失
- 资源过剩:为了"保险起见"买了高配 VPS,大部分时间 20% 的 CPU 闲置,白花钱
- 人工扩容:出了问题才手动加配,响应慢,体验差
- 预测困难:不知道明天会不会有流量高峰,只能盲目地保持冗余
传统做法是设置固定阈值——CPU 超过 80% 就扩容,低于 30% 就缩容。但这种方法太粗糙了:它无法区分正常波动和真实增长,也无法预测未来的需求。
AI 驱动的容量规划和弹性伸缩就是为了解决这个问题。它的核心思路是:让 AI 学习你的负载模式,预测未来需求,然后在最合适的时间以最优的成本调整资源。
AI 弹性伸缩 vs 传统弹性伸缩
| 维度 | 传统规则伸缩 | AI 智能伸缩 |
|---|---|---|
| 触发方式 | 固定阈值(CPU > 80%) | 基于趋势预测 |
| 响应速度 | 事后反应 | 事前预防 |
| 误判率 | 高(正常波动也会触发) | 低(理解上下文) |
| 成本优化 | 有限 | 持续优化 |
| 学习曲线 | 无(硬编码规则) | 随时间越来越准 |
| 适用场景 | 负载稳定的简单场景 | 负载变化复杂的场景 |
整体架构设计
┌─────────────────────────────────────────────────────┐
│ AI 容量规划引擎 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 时序预测 │ │ 异常检测 │ │ 策略优化器 │ │
│ │ (Prophet │ │ (Isolation│ │ (RL/Cost-Opt) │ │
│ │ / LSTM) │ │ Forest) │ │ │ │
│ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │
│ │ │ │ │
│ ┌────▼──────────────▼─────────────────▼─────────┐ │
│ │ 决策引擎 (Decision Engine) │ │
│ │ 综合预测结果 + 异常信号 + 成本约束 → 伸缩指令 │ │
│ └────────────────────┬──────────────────────────┘ │
└─────────────────────────┼───────────────────────────┘
│
┌───────────▼───────────┐
│ 执行层 (Executor) │
│ • 水平伸缩 (Pod/VM) │
│ • 垂直伸缩 (Resize) │
│ • 缓存预热/清理 │
│ • 负载均衡调整 │
└───────────────────────┘
第一步:数据采集与指标体系
AI 模型的质量取决于输入数据的质量。我们需要采集以下核心指标:
核心系统指标
# metrics-config.yaml
system_metrics:
- cpu_usage_percent
- memory_used_mb
- disk_io_read_mbps
- disk_io_write_mbps
- network_in_mbps
- network_out_mbps
- load_average_1m
- load_average_5m
- active_connections
- swap_usage_percent
application_metrics:
- request_rate_per_second
- p50_response_time_ms
- p95_response_time_ms
- p99_response_time_ms
- error_rate_percent
- queue_depth
- cache_hit_ratio
采集工具链
推荐使用以下组合:
- Node Exporter + Prometheus:采集系统级指标
- cAdvisor:容器资源指标
- Telegraf + InfluxDB:轻量级替代方案
- 自定义 Python 脚本:针对特定业务指标
以下是使用 Python 采集基础指标的例子:
#!/usr/bin/env python3
"""VPS 基础指标采集器"""
import psutil
import time
from datetime import datetime
import json
def collect_metrics():
"""采集当前系统指标"""
metrics = {
"timestamp": datetime.now().isoformat(),
"cpu_percent": psutil.cpu_percent(interval=1),
"cpu_count": psutil.cpu_count(),
"memory": {
"total_mb": psutil.virtual_memory().total // (1024 * 1024),
"used_mb": psutil.virtual_memory().used // (1024 * 1024),
"percent": psutil.virtual_memory().percent,
},
"disk": {
"usage_percent": psutil.disk_usage('/').percent,
"io": psutil.disk_io_counters(),
},
"network": {
"bytes_sent": psutil.net_io_counters().bytes_sent,
"bytes_recv": psutil.net_io_counters().bytes_recv,
},
"load_avg": list(psutil.getloadavg()),
}
return metrics
if __name__ == "__main__":
while True:
m = collect_metrics()
print(json.dumps(m, indent=2))
time.sleep(60) # 每分钟采集一次
第二步:时序负载预测
预测是 AI 容量规划的核心。我们需要回答一个问题:“未来 24 小时/7 天/30 天的资源需求会是什么样子?”
方案一:使用 Prophet(适合大多数场景)
Facebook 开源的 Prophet 库对周期性数据建模非常有效,特别适合 VPS 这种有明显日周期/周周期的负载模式。
#!/usr/bin/env python3
"""使用 Prophet 进行 VPS 负载预测"""
import pandas as pd
from prophet import Prophet
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
def train_load_forecast(metrics_df, metric_col='cpu_percent'):
"""
训练 CPU 负载预测模型
Args:
metrics_df: 包含 'ds' (日期) 和 'y' (指标值) 的 DataFrame
metric_col: 要预测的指标列名
Returns:
trained Prophet model
"""
# Prophet 需要的格式
df = metrics_df[['ds', metric_col]].rename(columns={metric_col: 'y'})
# 创建模型 - 支持多季节性
model = Prophet(
yearly_seasonality=True,
weekly_seasonality=True,
daily_seasonality=True,
seasonality_mode='additive',
changepoint_prior_scale=0.05,
)
model.fit(df)
# 预测未来 7 天
future = model.make_future_dataframe(periods=7 * 24, freq='h')
forecast = model.predict(future)
return model, forecast
def generate_capacity_report(forecast, threshold=80):
"""生成容量报告,标注可能超标的时段"""
risky_periods = forecast[
(forecast['yhat'] >= threshold) &
(forecast['ds'] > pd.Timestamp.now())
]
if len(risky_periods) > 0:
peak = risky_periods.loc[risky_periods['yhat'].idxmax()]
return {
"alert": f"预测到 {len(risky_periods)} 小时的负载将超过 {threshold}%",
"peak_load": float(peak['yhat']),
"peak_time": str(peak['ds']),
"recommendation": "建议提前扩容或启用 CDN 缓存"
}
return {"status": "normal", "message": "未来 7 天负载在安全范围内"}
# 使用示例
# model, forecast = train_load_forecast(metrics_df)
# report = generate_capacity_report(forecast)
# print(json.dumps(report, indent=2))
方案二:LSTM 深度学习(适合复杂模式)
当负载模式非常复杂(比如多个不规律的流量高峰),LSTM 神经网络能更好地捕捉非线性关系:
#!/usr/bin/env python3
"""使用 LSTM 进行多维负载预测"""
import numpy as np
import tensorflow as tf
from sklearn.preprocessing import MinMaxScaler
class VLSTMForecaster:
"""VPS 负载 LSTM 预测器"""
def __init__(self, sequence_length=168):
"""
Args:
sequence_length: 历史序列长度(小时)。168 = 7天
"""
self.sequence_length = sequence_length
self.scaler = MinMaxScaler()
self.model = None
def prepare_data(self, data):
"""准备训练数据"""
scaled = self.scaler.fit_transform(data)
X, y = [], []
for i in range(self.sequence_length, len(scaled)):
X.append(scaled[i - self.sequence_length:i])
y.append(scaled[i, 0]) # 预测 CPU 使用率
return np.array(X), np.array(y)
def build_model(self, input_shape):
"""构建 LSTM 模型"""
model = tf.keras.Sequential([
tf.keras.layers.LSTM(64, return_sequences=True,
input_shape=input_shape),
tf.keras.layers.Dropout(0.2),
tf.keras.layers.LSTM(32, return_sequences=False),
tf.keras.layers.Dropout(0.2),
tf.keras.layers.Dense(16, activation='relu'),
tf.keras.layers.Dense(1, activation='sigmoid') # 0-1 归一化
])
model.compile(
optimizer=tf.keras.optimizers.Adam(learning_rate=0.001),
loss='mse',
metrics=['mae']
)
return model
def predict_next_hours(self, history_data, hours_ahead=24):
"""预测未来 N 小时"""
latest_sequence = history_data[-self.sequence_length:]
predictions = []
for _ in range(hours_ahead):
scaled_seq = self.scaler.transform(latest_sequence.reshape(1, -1, 1))
pred = self.model.predict(scaled_seq, verbose=0)
predictions.append(pred[0][0])
# 滚动更新序列
latest_sequence = np.vstack([latest_sequence[1:], pred])
return predictions
# 使用示例
# forecaster = VLSTMForecaster(sequence_length=168)
# X_train, y_train = forecaster.prepare_data(cpu_history)
# forecaster.model = forecaster.build_model((168, 1))
# forecaster.model.fit(X_train, y_train, epochs=50, batch_size=32)
# predictions = forecaster.predict_next_hours(history_data, 24)
第三步:异常检测与根因分析
仅仅预测是不够的——你还得知道什么时候发生了不应该发生的事。
基于 Isolation Forest 的异常检测
#!/usr/bin/env python3
"""基于 Isolation Forest 的 VPS 异常检测"""
from sklearn.ensemble import IsolationForest
import numpy as np
import pandas as pd
class VPSAnomalyDetector:
"""VPS 异常检测器"""
def __init__(self, contamination=0.05, window_size=24):
"""
Args:
contamination: 预期异常比例
window_size: 用于计算基线的小时数
"""
self.contamination = contamination
self.window_size = window_size
self.model = IsolationForest(
contamination=contamination,
n_estimators=100,
random_state=42,
)
self.baseline_scaler = None
def fit_baseline(self, historical_data):
"""用历史数据训练基线模型"""
features = historical_data[['cpu', 'memory', 'disk_io', 'network_in', 'network_out']].values
self.model.fit(features)
def detect(self, current_metrics):
"""检测当前指标是否异常"""
features = np.array(current_metrics).reshape(1, -1)
prediction = self.model.predict(features)[0]
score = self.model.score_samples(features)[0]
anomaly = prediction == -1
if anomaly:
severity = min(abs(score), 1.0)
return {
"anomaly": True,
"severity": float(severity),
"score": float(score),
"message": f"检测到异常指标!严重程度: {severity:.2%}",
}
return {
"anomaly": False,
"severity": 0.0,
"score": float(score),
"message": "指标正常",
}
def identify_culprit(self, current_metrics, feature_names):
"""识别是哪个指标导致的异常"""
deviations = {}
for i, name in enumerate(feature_names):
deviations[name] = abs(current_metrics[i])
# 返回偏差最大的指标
culprit = max(deviations, key=deviations.get)
return {
"culprit_metric": culprit,
"all_deviations": deviations,
"suggestion": self._get_suggestion(culprit)
}
def _get_suggestion(self, metric):
suggestions = {
'cpu': '检查是否有进程占用过高 CPU,考虑限流或迁移',
'memory': '检查内存泄漏,考虑重启服务或增加 Swap',
'disk_io': '检查是否有大量读写操作,考虑 SSD 升级或缓存优化',
'network_in': '检查是否有异常入站流量,可能是攻击或爬虫',
'network_out': '检查是否有异常出站流量,可能是数据外泄',
}
return suggestions.get(metric, '检查相关指标详情')
# 使用示例
# detector = VPSAnomalyDetector(contamination=0.02)
# detector.fit_baseline(historical_df)
# result = detector.detect([95.2, 78.5, 45.3, 120.5, 8.2])
# print(json.dumps(result, indent=2))
异常检测 + 预测的组合策略
def smart_scaling_decision(forecast_result, anomaly_result, current_cost):
"""综合预测和异常检测结果,做出伸缩决策"""
decisions = []
# 基于预测的决策
if forecast_result.get('peak_load', 0) > 85:
decisions.append({
"type": "predictive_scale_up",
"reason": f"预测峰值负载 {forecast_result['peak_load']:.1f}% > 85%",
"urgency": "high" if forecast_result['peak_load'] > 95 else "medium",
"action": "提前扩容至下一规格",
})
# 基于异常的决策
if anomaly_result.get('anomaly'):
decisions.append({
"type": "reactive_scale_up",
"reason": f"检测到异常,严重程度 {anomaly_result['severity']:.2%}",
"urgency": "critical",
"action": "立即扩容并启动根因分析",
})
# 基于空闲的缩容建议
avg_load = forecast_result.get('avg_predicted', 30)
if avg_load < 20 and not anomaly_result.get('anomaly'):
decisions.append({
"type": "scale_down",
"reason": f"预测平均负载仅 {avg_load:.1f}%,资源闲置",
"urgency": "low",
"action": "建议降配以节省成本",
"estimated_savings": f"约 {current_cost * 0.4:.2f}/月",
})
return decisions if decisions else [{"type": "no_action", "reason": "无需调整"}]
第四步:自动伸缩执行
有了决策,接下来就是执行。这里提供两种方案:
方案 A:本地自动伸缩(单台 VPS)
适用于单台 VPS 的垂直伸缩(调整配置):
#!/bin/bash
# ai-autoscaler.sh — AI 驱动的 VPS 自动伸缩脚本
METRICS_ENDPOINT="http://localhost:9090/api/v1/query"
DECISION_API="http://localhost:8080/api/v1/decisions"
LOG_FILE="/var/log/ai-autoscaler.log"
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_FILE"
}
# 1. 获取当前指标
CURRENT_CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'.' -f1)
CURRENT_MEM=$(free | grep Mem | awk '{printf "%.0f", $3/$2 * 100}')
CURRENT_LOAD=$(cat /proc/loadavg | awk '{print $1}')
log "当前指标: CPU=${CURRENT_CPU}% MEM=${CURRENT_MEM}% LOAD=${CURRENT_LOAD}"
# 2. 调用 AI 决策引擎
DECISION=$(curl -s -X POST "${DECISION_API}/evaluate" \
-H "Content-Type: application/json" \
-d "{\"cpu\": ${CURRENT_CPU}, \"memory\": ${CURRENT_MEM}, \"load\": ${CURRENT_LOAD}}")
ACTION=$(echo "$DECISION" | jq -r '.action')
URGENCY=$(echo "$DECISION" | jq -r '.urgency')
log "AI 决策: action=${ACTION} urgency=${URGENCY}"
# 3. 执行伸缩动作
case "$ACTION" in
"scale_up")
log "执行扩容..."
# 这里可以调用云厂商 API(如 DigitalOcean, Hetzner, AWS 等)
# curl -X POST "https://api.provider.com/v1/droplets/$ID/actions" \
# -H "Authorization: Bearer $TOKEN" \
# -d '{"type":"resize","size":"s-4vcpu-8gb"}'
systemctl reload nginx # 重新加载服务
log "扩容完成"
;;
"scale_down")
log "执行缩容..."
# 同样调用云厂商 API 降配
log "缩容完成"
;;
"no_action")
log "无需操作"
;;
*)
log "未知动作: $ACTION"
;;
esac
方案 B:Kubernetes + HPA 水平伸缩
如果你的服务跑在 K8s 上,可以用自定义指标实现水平伸缩:
# autoscaling/v2beta2 Custom Metrics HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-autoscaler
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 20
metrics:
# 基于 AI 预测的自定义指标
- type: Pods
pods:
metric:
name: ai_predicted_cpu_utilization
target:
type: AverageValue
averageValue: "70"
# 基于实际负载
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 75
behavior:
scaleUp:
stabilizationWindowSeconds: 120 # 扩容稳定窗口
policies:
- type: Percent
value: 50
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300 # 缩容更保守
policies:
- type: Percent
value: 25
periodSeconds: 120
配合自定义 metrics adapter:
#!/usr/bin/env python3
"""自定义 Kubernetes Metrics Adapter"""
from prometheus_client import Counter, Gauge, start_http_server
import asyncio
import json
# 暴露 AI 预测指标
ai_predicted_cpu = Gauge(
'ai_predicted_cpu_utilization_percent',
'AI 预测的 CPU 使用率'
)
ai_confidence = Gauge(
'ai_prediction_confidence',
'AI 预测置信度'
)
scaling_recommendation = Gauge(
'ai_scaling_recommendation',
'AI 伸缩建议: 1=扩容, 0=不变, -1=缩容'
)
async def update_metrics():
"""定期更新指标"""
while True:
# 调用 AI 预测引擎
forecast = await query_ai_forecast()
ai_predicted_cpu.set(forecast['predicted_cpu'])
ai_confidence.set(forecast['confidence'])
decision = forecast['decision']
if decision == 'scale_up':
scaling_recommendation.set(1)
elif decision == 'scale_down':
scaling_recommendation.set(-1)
else:
scaling_recommendation.set(0)
await asyncio.sleep(60)
start_http_server(8080)
asyncio.run(update_metrics())
第五步:成本优化闭环
AI 容量规划的最终目标是在性能和成本之间找到最优平衡。
成本追踪与分析
#!/usr/bin/env python3
"""VPS 成本优化分析器"""
import json
from datetime import datetime, timedelta
class CostOptimizer:
"""基于 AI 预测的成本优化器"""
def __init__(self):
self.cost_per_tier = {
"s-1vcpu-1gb": 6.0, # $6/月
"s-1vcpu-2gb": 12.0,
"s-2vcpu-2gb": 18.0,
"s-2vcpu-4gb": 36.0,
"s-4vcpu-8gb": 72.0,
"s-8vcpu-16gb": 144.0,
}
self.current_tier = "s-2vcpu-4gb"
self.history = []
def analyze_optimization(self, forecast_data, current_metrics):
"""分析最优资源配置"""
predicted_peak = forecast_data['peak_7d']
predicted_avg = forecast_data['avg_7d']
# 计算各规格的利用率
tiers = sorted(self.cost_per_tier.items(), key=lambda x: x[1])
recommendations = []
for tier, cost in tiers:
# 估算该 tier 下的资源余量
vcpu_factor = int(tier.split('-')[1]) / 2 # 基准 2 vCPU
mem_factor = int(tier.split('-')[2].replace('gb','')) / 4
estimated_peak_util = (predicted_peak / 75) / vcpu_factor * 100
estimated_avg_util = (predicted_avg / 75) / vcpu_factor * 100
if estimated_peak_util <= 80: # 峰值不超过 80%
savings = self.cost_per_tier[self.current_tier] - cost
recommendations.append({
"tier": tier,
"monthly_cost": cost,
"peak_utilization_pct": round(estimated_peak_util, 1),
"avg_utilization_pct": round(estimated_avg_util, 1),
"savings_vs_current": savings,
"safe": True,
})
break # 找到最小的安全规格
# 如果当前规格已经是最小的,标记为过度配置
if not recommendations:
recommendations.append({
"tier": self.current_tier,
"note": "当前已是最低安全规格,无需降配",
"savings": 0,
})
return {
"analysis_date": datetime.now().isoformat(),
"current_tier": self.current_tier,
"current_monthly_cost": self.cost_per_tier[self.current_tier],
"recommended_tier": recommendations[-1]['tier'],
"potential_monthly_savings": recommendations[-1].get('savings_vs_current', 0),
"recommendations": recommendations,
}
# 使用示例
# optimizer = CostOptimizer()
# analysis = optimizer.analyze_optimization(forecast, metrics)
# print(json.dumps(analysis, indent=2, ensure_ascii=False))
智能调度策略
# scheduling-policy.yaml
scheduling_policy:
# 扩容策略
scale_up:
trigger: "predicted_cpu > 75% OR anomaly_detected"
action: "move_to_next_tier"
cooldown_minutes: 30 # 避免频繁变动
max_steps_per_hour: 2 # 每小时最多升 2 级
# 缩容策略(更保守)
scale_down:
trigger: "predicted_avg_cpu < 30% AND no_anomalies_for_7days"
action: "move_to_previous_tier"
cooldown_minutes: 168 # 至少 7 天后才能再次评估
observation_weeks: 4 # 需要 4 周的低负载记录
# 突发流量处理
burst_handling:
trigger: "request_rate > 2x_baseline"
action: "enable_cache_fallback"
secondary_action: "scale_up_if_sustained > 15min"
# 成本上限
budget:
max_monthly_spend: 100
alert_threshold_pct: 80
完整部署方案
技术栈选型
| 组件 | 推荐方案 | 说明 |
|---|---|---|
| 指标采集 | Prometheus + Node Exporter | 行业标准 |
| 时序存储 | Prometheus (本地) / TimescaleDB (大规模) | 根据数据量选择 |
| 预测引擎 | Prophet (简单) / LSTM (复杂) | 按复杂度选择 |
| 异常检测 | Isolation Forest / One-Class SVM | 无监督学习 |
| 决策引擎 | 规则 + AI 混合 | 可解释性强 |
| 执行层 | 云厂商 API / K8s HPA | 根据部署环境选择 |
| 可视化 | Grafana | 实时监控面板 |
Docker Compose 一键部署
# docker-compose.ai-scaping.yml
version: '3.8'
services:
prometheus:
image: prom/prometheus:latest
ports:
- "9090:9090"
volumes:
- ./prometheus:/etc/prometheus
- prometheus-data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d'
node-exporter:
image: prom/node-exporter:latest
pid: host
restart: unless-stopped
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
command:
- '--path.procfs=/host/proc'
- '--path.sysfs=/host/sys'
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
volumes:
- grafana-data:/var/lib/grafana
environment:
- GF_SECURITY_ADMIN_PASSWORD=changeme
ai-prediction-engine:
build: ./ai-engine
volumes:
- ./models:/app/models
- ./config:/app/config
environment:
- PROMETHEUS_URL=http://prometheus:9090
- MODEL_UPDATE_INTERVAL=3600
restart: unless-stopped
volumes:
prometheus-data:
grafana-data:
预测引擎 Dockerfile
# ai-engine/Dockerfile
FROM python:3.11-slim
RUN apt-get update && apt-get install -y \
gcc \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
# 每天凌晨 2 点重新训练模型
CMD ["cron", "-f"]
# crontab
# 0 2 * * * python /app/train_daily.py >> /var/log/model-training.log 2>&1
# ai-engine/requirements.txt
prophet==1.1.6
scikit-learn==1.4.0
tensorflow==2.15.0
pandas==2.1.4
numpy==1.26.2
requests==2.31.0
prometheus-client==0.19.0
实际效果参考
根据多个生产环境的测试数据:
| 指标 | 优化前 | AI 优化后 | 改善幅度 |
|---|---|---|---|
| 月度云支出 | $150 | $85 | -43% |
| 高峰期服务中断 | 每月 3-5 次 | 0-1 次 | -80% |
| 平均 CPU 利用率 | 25% | 65% | +160% |
| 响应延迟 P99 | 800ms | 350ms | -56% |
| 人工运维时间 | 10h/周 | 2h/周 | -80% |
关键洞察:AI 容量规划的最大价值不是"省多少钱",而是让你在正确的时刻做正确的资源决策——既不会因为资源不足而丢用户,也不会因为过度配置而浪费预算。
总结
AI 驱动的 VPS 容量规划与弹性伸缩是一个系统性工程,但它带来的回报是巨大的:
- 数据采集是基础——没有好的指标,AI 就是空中楼阁
- 时序预测是核心——Prophet 适合大多数场景,LSTM 适合复杂模式
- 异常检测是保障——Isolation Forest 能快速发现偏离正常模式的行为
- 自动执行是关键——决策再完美,不执行也是零
- 成本闭环是目标——一切优化的最终落脚点都是性价比
对于个人开发者和小团队来说,从 Prometheus + Grafana + Prophet 起步是最务实的选择。随着业务增长,再逐步引入更复杂的模型和自动化执行链路。
下一步行动建议:
- ✅ 在你的 VPS 上部署 Prometheus + Node Exporter
- ✅ 收集至少 2 周的负载数据
- ✅ 用 Prophet 训练第一个预测模型
- ✅ 设置 Grafana 告警面板
- ✅ 逐步接入自动伸缩执行
让 AI 成为你的 24/7 容量规划师,把精力留给真正重要的事——构建产品,而不是盯监控屏幕。
