# 集群健康评分

> **将快速检查数据转换为可量化的健康分数，生成集群报告。**
> 输入来自 references/cluster-quick-check.md Step 4 的汇总数据。

---

## 节点评分算法（100 分制，扣分制）

### 初始分：100

### 扣分规则（按顺序计算，不叠加超过上限）

#### Layer 1：云端实例状态

| 条件 | 扣分 | 说明 |
|------|------|------|
| `instance_state` = STOPPED / SHUTDOWN / TERMINATING | 最终得分 = **0** | 实例不可用，终止计算 |
| `instance_state` = REBOOTING | 暂不评分 | 标注"重启中" |

#### Layer 2B：OS 负载（TAT 数据，若 tat_available=false 跳过此段）

| 条件 | 扣分 |
|------|------|
| `load_ratio` > 2.0（LOAD / NCPU > 200%） | **-25** |
| `load_ratio` > 1.5（150%） | **-10** |
| `load_ratio` > 1.0（100%） | **-5** |

#### Layer 2B：内存使用率（TAT 数据）

| 条件 | 扣分 |
|------|------|
| `mem_pct` > 90% | **-20** |
| `mem_pct` > 75% | **-10** |
| `mem_pct` > 60% | **-5** |

#### Layer 2B：磁盘使用率（TAT 数据）

| 条件 | 扣分 |
|------|------|
| `disk_root_pct` > 90 | **-25** |
| `disk_root_pct` > 80 | **-10** |
| `disk_root_pct` > 70 | **-5** |

#### Layer 2B：SSH 守护进程状态（TAT 数据）

| 条件 | 扣分 |
|------|------|
| `sshd_active` = false（非 active 状态） | **-40** |

#### Layer 2A：云端 CPU 均值（GetMonitorData）

| 条件 | 扣分 |
|------|------|
| `cpu_cloud_avg_pct` > 85% | **-15** |
| `cpu_cloud_avg_pct` > 70% | **-5** |

#### Layer 2A：云端内存均值（GetMonitorData）

| 条件 | 扣分 |
|------|------|
| `mem_cloud_avg_pct` > 90% | **-15** |
| `mem_cloud_avg_pct` > 80% | **-5** |

#### 降级补偿

| 条件 | 处理 |
|------|------|
| `tat_available` = false | OS 相关扣分项跳过，结果标注"仅云端指标（置信度较低）" |
| 云端指标 N/A | 云端指标扣分项跳过 |

**最低分：0（不会出现负数）**

---

## 集群评分：木桶原理

```
集群得分 = MIN(所有节点得分)

原理：集群的实际可用性由最弱节点决定。
      1 台崩溃 = 部分请求失败，无论其他节点多健康。
```

---

## 健康等级

| 分段 | 等级 | 显示 |
|------|------|------|
| 90-100 | 健康 | ✅ 健康 |
| 75-89 | 轻微异常 | ✅ 正常（有小问题） |
| 60-74 | 需要关注 | ⚠️ 需关注 |
| 40-59 | 异常 | 🚨 异常 |
| 0-39 | 严重 | 🔴 严重 |

---

## 报告模板

```
## 集群健康报告 [<cluster_name>]
时间：<YYYY-MM-DD HH:MM:SS> （<region>）

📊 集群评分：<score>/100 <等级图标>
   木桶短板：<最低分节点名>（<最低分>分）

节点状态总览：
  ✅ 健康节点：<N> 台
  ⚠️ 需关注：<N> 台
  🔴 异常节点：<N> 台
  ⏹️ 已停止：<N> 台

| 节点          | 状态    | 评分 | 负载/核  | 内存%  | 磁盘% | SSH   | 云CPU% | 异常概述 |
|--------------|---------|------|---------|-------|-------|-------|--------|---------|
| order-api-1  | RUNNING | 95   | 0.3/4   | 42%   | 55%   | ✅    | 38%    | —       |
| order-api-2  | RUNNING | 78   | 0.8/4   | 78%   | 61%   | ✅    | 65%    | 内存偏高 |
| order-api-3  | RUNNING | 55   | 3.2/4   | 88%   | 79%   | ✅    | 92%    | CPU高/内存高/磁盘偏高 |
| order-api-4  | STOPPED | 0    | —       | —     | —     | N/A   | —      | 实例已停止 |

---
<如有跨节点关联问题，在这里列出，否则省略>

⚠️ 检测到集群级问题：
1. [关联] order-api-2 和 order-api-3 同时内存 > 75%，疑似共享资源压力
   → 建议检查共用的 MySQL/Redis 实例（调用 tencentcloud-infra GetMonitorData）

---
💡 建议操作（按优先级）：

🔴 立即处理：
→ order-api-3 CPU 使用率 92%，进程需要深度排查
   输入 "深度分析 order-api-3" 查看 top 进程

🟡 尽快处理：
→ order-api-4 已停止，请确认是否计划内
   若需启动：需确认后通过 tencentcloud-infra 执行

🟢 关注：
→ order-api-2 内存 78%，建议 24 小时内复查趋势
```

---

## 关联问题检测（快速版）

在生成报告前，对以下模式进行快速扫描（详细分析见 cluster-deep-analysis.md）：

**模式 A：内存级联**
条件：`≥ 3 个节点 mem_pct > 75%`
报告中追加："[关联] 多节点内存同时偏高，疑似共享后端压力"

**模式 B：负载不均**
条件：`MAX(load_ratio) - MIN(load_ratio) > 0.5`（正常节点间）
报告中追加："[关联] 负载分布不均（最高 X，最低 Y），建议检查负载均衡"

**模式 C：磁盘增长同步**
条件：`≥ 2 个节点 disk_root_pct > 75%`
报告中追加："[关联] 多节点磁盘使用率较高，可能是统一的日志未清理"

---

## 报告写入 MEMORY.md

每次检查结束后，将简要摘要写入 MEMORY.md 诊断历史：

```markdown
### <YYYY-MM-DD HH:MM> — 集群快速检查
- **集群评分**: <N>/100
- **异常节点**: <节点列表>（若无则填"无"）
- **主要问题**: <一句话描述>
- **操作**: <本次执行了哪些操作，若无填"仅检查，未操作">
```
