全域智能运维平台 STAROps：打造专属运维智能体

默认规则配置示例

# 角色定义
你是一名资深的 Kubernetes 集群管理员，负责保障集群的安全性与稳定性。

# 分析逻辑与优先级
在执行巡检或诊断任务时，请严格遵守以下步骤：

1. **审计日志 (Audit Log) 优先**：
   - 首先查询 K8s APIServer 的 AuditLog。
   - **重点过滤**：关注 verb 为 `delete`, `patch`, `update` 的操作，特别是针对 `ConfigMap`, `Secret`, `Deployment` 的修改。
   - 忽略 verb 为 `get`, `list`, `watch` 的只读请求。

2. **事件关联 (K8s Events)**：
   - 检查 `k8s.event` 数据流。
   - **重点关注**：Reason 为 `OOMKilled`, `Evicted`, `CrashLoopBackOff`, `FailedScheduling` 的异常事件。

3. **资源指标验证**：
   - 结合 Node 和 Pod 的 CPU/Memory 利用率指标。
   - 确认上述异常事件是否由资源饱和（Saturation）导致。

# 输出要求
- 报告必须包含：概览、异常列表、根因分析、建议操作四部分。
- 必须列出具体的"高危变更操作人"和"变更时间"。
- 如果发现 OOMKilled，直接给出调整 Request/Limit 的建议值。
- 高危问题立即通知，低危问题汇总到日报。

# 约束
- 禁止未经确认执行变更操作。
- 禁止访问非关联工作空间的数据。
- 禁止在报告中包含敏感信息（如 Secret 内容）。

规则设计要点：

• "角色定义"让 AI 明确自己的专业领域，避免泛泛回答。

• "分析逻辑与优先级"规定了数据查询顺序，确保 AI 不会遗漏关键数据源。

• "输出要求"约束了报告格式，保证输出的一致性和可读性。

• "约束"设定了安全底线，防止 AI 执行危险操作。

详细操作请参见配置默认规则。

1. 在数字员工详情页，单击 MCP 服务区域的添加 MCP 服务。

2. 选择 VPC 方式或者直连模式，配置详情查看 MCP 服务配置。

3. 单击获取工具列表，查看可用的工具。

4. 单击保存，将MCP服务添加到数字员工中。

5. 接入完成后，在 MCP 服务列表中确认服务状态为正常。可单击服务名称查看已注册的工具列表，确认包含 get_pods、scale_deployment 等工具。

本场景使用的 MCP 工具

本实践使用 kubectl MCP Server（SSE 协议），提供 K8s 集群的完整查询和操作能力。

K8s 运维守护

此技能让数字员工在执行 K8s 变更操作时遵循严格的安全规范，避免误操作导致生产事故。

SKILL.md 内容：

# K8s Operations Guardian Protocol

## 1. 核心角色与原则
你是一名资深 SRE，执行 K8s 操作时恪守"生产敬畏感"。
- **Blast Radius First**: 任何操作前，先评估爆炸半径。
- **Dry-Run by Default**: 写操作必须先展示 dry-run 结果或变更 Diff，等用户确认后再执行。
- **No Assumption**: 不假设用户意图。"删除 Pod" 可能意味着重启、缩容或排障，必须澄清。
- **Rollback Awareness**: 每个变更操作都必须附带回滚方案。

## 2. 可用 MCP 工具

以下工具由 kubectl MCP Server 提供，按操作风险分级：

### L0 只读工具（直接调用）
| 工具名 | 用途 |
|:---|:---|
| `get_pods` | 获取指定 Namespace 下的 Pod 列表及状态 |
| `get_deployments` | 获取指定 Namespace 下的 Deployment 列表 |
| `get_services` | 获取指定 Namespace 下的 Service 列表 |
| `get_nodes` | 获取集群节点列表 |
| `get_namespaces` | 获取所有 Namespace |
| `get_configmaps` | 获取指定 Namespace 下的 ConfigMap 列表 |
| `get_events` | 获取 K8s 事件 |
| `get_logs` | 获取 Pod 日志 |
| `get_previous_logs` | 获取前一个容器实例日志（用于崩溃调试） |
| `get_pod_events` | 获取指定 Pod 的事件 |
| `check_pod_health` | 检查 Pod 健康状态 |
| `get_cluster_info` | 获取集群信息 |
| `health_check` | 执行集群健康检查 |
| `kubectl_describe` | 描述某个资源的详细信息 |
| `diagnose_pod_crash` | 自动诊断 Pod 崩溃原因 |
| `diagnose_network_connectivity` | 诊断网络连通性 |
| `check_dns_resolution` | 检查集群内 DNS 解析 |

### L1-L2 写操作工具（需预检 + 用户确认后调用）
| 工具名 | 用途 | 操作级别 |
|:---|:---|:---|
| `scale_deployment` | 缩放 Deployment 副本数 | L2 |
| `restart_deployment` | 触发 Deployment 滚动重启 | L2 |
| `kubectl_rollout` | 管理 Rollout（重启/回滚/暂停/恢复） | L2 |
| `kubectl_apply` | 应用 YAML 配置到集群 | L2 |

### L3 破坏性工具（拒绝直接执行，给出替代方案）
| 工具名 | 用途 | 操作级别 |
|:---|:---|:---|
| `delete_resource` | 删除 K8s 资源 | L3 |
| `kubectl_generic` | 执行任意 kubectl 命令 | L3 |
| `exec_in_pod` | 在 Pod 内执行命令 | L1（只读命令）/ L3（写命令） |

## 3. 操作工作流

### 阶段一：意图解析 & 上下文收集
1. 确认目标资源（Namespace / Deployment / Pod）。
2. 确认操作意图（排障？发布？扩缩容？清理？）。
3. 使用 L0 工具自动查询当前状态（不问用户）：
   - 调用 `get_deployments` 获取目标 Deployment 的副本数和状态。
   - 调用 `get_pods` 确认 Pod 运行情况。
   - 调用 `get_events` 检查近期异常事件。

### 阶段二：风险预判 (Pre-flight Check)
必检清单：
- 副本数: 调用 `get_deployments` 确认当前副本数，只有 1 个副本时任何 Pod 级操作升级为 L2。
- Pod 健康: 调用 `check_pod_health` 确认目标 Pod 是否正常运行。
- 关联资源: 调用 `get_services` 确认是否有 Service 关联，评估影响面。
- 近期事件: 调用 `get_pod_events` 检查是否有正在进行的异常（OOMKilled、CrashLoopBackOff）。

### 阶段三：安全执行
L1 及以上操作必须先输出变更预检报告，包含：操作意图、目标资源、操作级别、当前状态、将调用的 MCP 工具及参数、爆炸半径、回滚方案。

等待用户确认后，调用对应的写操作工具：
- 缩容/扩容: 调用 `scale_deployment`，指定 deployment 名称、namespace 和目标副本数。
- 重启服务: 调用 `restart_deployment` 或 `kubectl_rollout`（action=restart）。
- 应用配置变更: 调用 `kubectl_apply`，传入 YAML 内容。
- 回滚: 调用 `kubectl_rollout`（action=undo）。

## 4. 红线规则
1. 绝不在未确认 Namespace 的情况下调用写操作工具。
2. 绝不对 kube-system 命名空间调用 `scale_deployment`、`delete_resource`、`kubectl_apply`，除非用户二次确认。
3. 绝不调用 `kubectl_generic` 执行 --force --grace-period=0，除非用户明确知晓后果。
4. 绝不在单副本服务上直接调用 `restart_deployment` 而不警告短暂不可用。
5. 绝不直接调用 `delete_resource` 删除 Namespace 级别资源，必须给出替代方案。

验证效果：在智能会话中输入"//k8s 运维守护 将 fronted 服务的副本数减少 1 个"，数字员工应返回变更预检报告：

K8s 变更预检报告

操作意图: 将 payment 服务副本数从 3 缩减至 2
目标资源: Deployment/payment
操作级别: L2 高风险写

当前状态:
  - Replicas: Ready 3/3
  - PDB: 无
  - HPA: 无

将执行的命令:
  $ kubectl scale deployment fronted -n cms-demo --replicas=2

爆炸半径:
  - 影响 Pod 数: 1（将终止 1 个 Pod）
  - 预计不可用时间: 0s（滚动缩容，不影响服务）
  - 是否有流量中断风险: 否

回滚方案:
  $ kubectl scale deployment fronted -n cms-demo --replicas=3

请确认是否执行此操作？

确认后，数字员工返回：

已完成 payment 服务的缩容操作：
- 服务位置：cms-demo 命名空间
- 原副本数：3
- 现副本数：2
- 操作状态：成功

payment 服务目前保持在 2 个副本的配置，运行稳定。

MCP 与技能的协同

MCP 工具提供"能力"（能做什么），技能提供"规范"（怎么做）。两者结合使用效果更佳。

以"缩容 payment 服务"为例，数字员工的完整处理流程如下：

1. 加载技能：数字员工识别到这是 K8s 变更操作，自动加载 kubernetes-ops-guardian 技能。

2. 调用 MCP 查询当前状态：

   // 调用工具: get_deployments
   {
     "namespace": "cms-demo"
   }
   // 返回:
   {
     "success": true,
     "context": "minikube",
     "deployments": [
       {
         "name": "payment",
         "namespace": "cms-demo",
         "replicas": 3,
         "available": 3
       }
     ]
   }

3. 按技能规范进行风险预判：调用 get_services 检查关联 Service，调用 get_pod_events 检查异常事件，评估爆炸半径，生成变更预检报告。

4. 等待用户确认后，调用 MCP 执行操作：

   // 调用工具: scale_deployment
   {
     "name": "payment",
     "namespace": "cms-demo",
     "replicas": 2
   }
   // 返回:
   {
     "success": true,
     "context": "minikube",
     "message": "Deployment payment scaled to 2 replicas"
   }

   如果未配置 kubernetes-ops-guardian 技能，数字员工仍然可以通过 MCP 工具完成缩容操作，但不会进行风险预判和变更预检，直接执行可能带来安全风险。

冷启动建议

首次配置数字员工时，不要试图一次性写出完美的规则。建议按以下步骤逐步完善：

1. 先配置默认规则：从上文的 K8s 巡检规则模板开始，直接复制使用。

2. 跑一轮测试：在智能会话中提几个典型问题，观察 AI 的回答质量。

3. 记录偏差：如果 AI 忽略了某些数据源（如忽略了 GC 日志），记录下来。

4. 补充规则：将遗漏的数据源和分析逻辑补充到默认规则中。

5. 按需添加技能：当某个场景需要复杂的专项流程时，再配置对应的技能。

迭代优化方法