使用AI CLI对CCE工作负载进行故障诊断与恢复
应用场景
在CCE集群中，工作负载发布、扩缩容或配置变更后，可能出现Pod长时间未就绪、Deployment滚动升级卡住、容器频繁重启、镜像拉取失败、调度失败、服务端点异常等问题。传统排障通常需要运维人员在Deployment、ReplicaSet、Pod、Events、容器日志、探针配置和监控数据之间反复切换，定位链路长、人工判断成本高。
通过AI CLI结合云原生Skill能力，用户可以使用自然语言描述故障现象，由Agent自动完成上下文识别、证据采集、根因分析、恢复方案预览、用户确认、恢复执行和结果验证，帮助运维团队把工作负载故障处理沉淀为可重复的标准流程。
本实践面向CCE工作负载故障诊断与恢复的通用场景，不绑定固定命名空间、工作负载名称或单次测试环境。文中的 ai-diagnose-demo 仅表示演示命名空间，实际使用时请替换为您的目标集群和业务命名空间。
约束与限制
- AI CLI的诊断准确性依赖于集群访问权限、日志保留时间、事件完整性和可观测数据质量。
- 所有写操作必须遵循“预览 + 确认”模式，禁止在未确认的情况下执行回滚、重启、扩缩容或配置修改。
- 生产环境中，建议将诊断权限和恢复权限分离，并通过审计日志记录AICLI的所有操作。
- 回滚操作依赖于工作负载的历史Revision。如果历史版本已清理，需要采用重新发布或配置修复等方式恢复。
- 如果故障涉及数据库变更、数据格式变更、外部依赖或消息堆积，回滚前需要评估数据一致性和业务补偿方案。
- 对于多集群、多命名空间或多异常对象的场景，AI CLI应要求用户确认目标范围，避免跨业务的误操作。
- 禁止在提示词、诊断报告或恢复预览中输出AK/SK、Token、证书、真实项目ID等敏感信息。
- 建议先在演示或测试命名空间验证Skill流程，确保流程的正确性和安全性，再推广到生产集群。
前提条件
- 已创建CCE集群，目标工作负载已部署。
- 已安装或接入AI CLI，并完成相关Skill注册。
- AI CLI具备读取工作负载、Pod、Events、日志、版本历史和服务端点的权限。
- 如需执行恢复操作，AI CLI还需具备回滚、重启、扩缩容或修改工作负载配置的权限。
涉及的Skill
| Skill名称 | 功能描述 |
|---|---|
| huawei-cloud-cce-workload-failure-diagnoser | 采集工作负载、Pod、Events、日志和版本历史，输出诊断结论。 |
| huawei-cloud-cce-auto-remediation-runner | 生成恢复预览，并在用户确认后执行回滚、重启、扩缩容等动作。 |
操作流程
步骤一：启动AI CLI会话
根据企业实际接入方式启动AI CLI。若使用命令行方式，可进入交互会话：
aicli chat
如果AI CLI已接入运维平台、ChatOps工具或流水线，也可以直接在对应入口发起自然语言请求。
步骤二：使用自然语言描述故障
用户不需要手动拼接多条Kubernetes命令，只需描述目标集群、命名空间和故障现象。建议在输入中说明是否允许执行恢复操作，以及恢复前是否需要预览。例如，提示词如下。
请帮我诊断北京四cce-ai-ops-demo集群中ai-diagnose-demo命名空间的工作负载发布异常，现象是最近一次更新后Pod长时间未就绪。请先分析根因并给出恢复建议，恢复操作执行前请让我确认。
如果不确定异常对象，可以让AI CLI先扫描命名空间。
请先检查cce-ai-ops-demo集群中ai-diagnose-demo命名空间的异常工作负载，找出发布失败或Pod未就绪的对象，并输出诊断结论和恢复建议。
步骤三：确认诊断范围
AI CLI会根据用户输入识别区域、集群、命名空间、资源类型、故障时间窗口和故障现象。若命名空间中存在多个异常工作负载，AI CLI应先列出候选对象及异常摘要，让用户确认诊断范围。
建议确认以下信息。
| 信息 | 说明 |
|---|---|
| 目标集群 | 支持通过集群名称、集群ID或区域+集群名称识别。 |
| 命名空间 | 用于限定诊断范围，避免跨业务误操作。 |
| 工作负载类型 | 可诊断Deployment、StatefulSet、DaemonSet等常见工作负载。 |
| 故障现象 | 例如Pod未就绪、滚动升级卡住、容器重启、镜像拉取失败、调度失败。 |
| 恢复边界 | 是否允许执行回滚、重启、扩缩容或配置修改等动作。 |
步骤四：自动采集诊断证据
AI CLI调用工作负载故障诊断Skill后，应按照从控制面到数据面的顺序采集证据，避免只依赖单点日志或单条事件作出判断。
| 诊断维度 | 关键证据 | 诊断价值 |
|---|---|---|
| 工作负载状态 | 期望副本、就绪副本、可用副本、更新副本、状态条件 | 判断发布是否完成、可用性是否受影响。 |
| 版本关系 | Revision历史、ReplicaSet状态、新旧版本副本分布 | 判断是否存在健康历史版本，是否具备回滚条件。 |
| Pod生命周期 | Pending、Running、Ready、RestartCount、容器状态 | 判断故障发生在调度、启动、运行还是就绪阶段。 |
| Kubernetes事件 | FailedScheduling、FailedPull、Unhealthy、BackOff等事件 | 快速定位调度、镜像、探针、容器启动类问题。 |
| 容器日志 | 最近异常日志、启动日志、健康检查相关日志 | 识别应用内部错误、依赖异常或配置问题。 |
| 探针配置 | readinessProbe、livenessProbe、startupProbe配置和结果 | 判断健康检查路径、端口、协议和超时配置是否合理。 |
| 服务端点 | Service、EndpointSlice、Ingress或负载均衡后端 | 判断故障是否影响业务流量接入。 |
| 可观测数据 | 指标、告警、日志趋势 | 识别资源压力、异常流量、依赖抖动等外部因素。 |
步骤五：输出诊断结论和恢复建议
诊断完成后，AI CLI应输出结构化结论，帮助用户快速判断是否需要恢复操作。
建议输出以下内容。
| 输出项 | 内容 |
|---|---|
| 诊断结论 | 明确故障类型，例如探针失败、镜像拉取失败、容器启动失败、调度失败、资源不足或配置异常。 |
| 影响范围 | 说明受影响的命名空间、工作负载类型、不可用副本数量和业务访问影响。 |
| 关键证据 | 列出支撑结论的状态条件、事件、日志或指标，不输出敏感信息。 |
| 根因分析 | 说明故障发生在发布链路的哪个阶段，以及为什么会导致工作负载不可用。 |
| 恢复建议 | 给出一个或多个恢复选项，并说明适用场景、风险等级和预期效果。 |
| 是否需要确认 | 对回滚、重启、扩缩容、配置修改等变更动作标记为需要用户确认。 |
步骤六：预览恢复方案
如果用户希望AI CLI继续处理故障，AI CLI应调用自动恢复Skill生成恢复预览。预览阶段只展示计划，不改变集群状态。
常见恢复动作如下所示。
| 恢复动作 | 适用场景 | 风险控制 |
|---|---|---|
| 回滚到健康Revision | 新版本发布后不可用，旧版本仍可稳定承载业务。 | 校验历史版本、当前可用副本和回滚影响范围。 |
| 重启异常Pod | 单个Pod进入异常状态，工作负载模板本身未发现明显配置问题。 | 避免批量重启导致可用副本不足。 |
| 临时扩容 | 当前可用副本不足，业务需要先恢复容量。 | 评估资源配额、节点容量和HPA策略。 |
| 修正工作负载配置 | 探针、环境变量、镜像Tag、Secret或ConfigMap引用存在错误。 | 展示配置差异，确认变更窗口和回退方式。 |
| 暂停或恢复发布 | 滚动升级异常，需要阻止继续扩大影响或继续完成发布。 | 明确暂停/恢复后的发布状态和人工后续动作。 |
恢复预览建议包含以下信息：
- 将执行的动作和目标资源范围。
- 变更前后的关键配置或状态差异。
- 风险等级、业务影响和是否需要变更窗口。
- 验证方式和回退路径。
- 用户需要确认的具体语句。
步骤七：确认并执行恢复
用户确认恢复计划后，AI CLI才可以调用自动恢复Skill执行动作。建议用户使用明确表达，例如：
确认按预览方案执行恢复。
执行过程中，AI CLI应持续反馈变更状态。如果恢复动作失败，应停止后续变更，输出失败原因、已执行动作、当前集群状态和建议的人工处理方式。
步骤八：验证恢复结果
恢复完成后，AI CLI需要再次读取工作负载状态和相关证据，确认故障是否真正恢复。
建议验证以下内容。
| 验证项 | 期望结果 |
|---|---|
| 工作负载状态 | 期望副本、就绪副本、可用副本符合预期，发布状态稳定。 |
| Pod状态 | Pod处于Running且Ready，无持续重启、拉取失败或调度失败。 |
| 事件和日志 | 不再出现同类高频异常事件，容器日志无新的关键错误。 |
| 服务端点 | Service或EndpointSlice具备可用后端，业务流量可被正确转发。 |
| 业务探测 | 如已配置健康检查或外部探测，探测结果恢复正常。 |
| 告警状态 | 相关告警恢复或进入收敛状态，无新的高风险告警触发。 |
Skill执行流程
| 阶段 | 输入 | Skill动作 | 输出 |
|---|---|---|---|
| 目标识别 | 自然语言中的区域、集群、命名空间、故障现象 | 解析诊断范围，补全缺失信息，必要时请求用户确认 | 明确的诊断目标和边界 |
| 证据采集 | 目标工作负载和时间窗口 | 查询工作负载、Pod、Events、日志、版本历史和服务端点 | 多维度诊断证据 |
| 根因分析 | 诊断证据 | 识别故障阶段，排除不匹配原因，输出置信度 | 根因结论和关键证据 |
| 恢复规划 | 根因、影响范围、权限边界 | 生成回滚、重启、扩缩容或配置修复预览 | 恢复计划、风险等级、验证方式 |
| 用户确认 | 用户确认语句 | 检查确认内容是否匹配预览计划 | 可执行恢复任务 |
| 恢复执行 | 已确认的恢复任务 | 调用Kubernetes API或CCE相关接口执行变更 | 执行结果和中间状态 |
| 恢复验证 | 恢复后的工作负载状态 | 复查状态、事件、日志、端点和业务探测 | 最终结论和后续建议 |
预期结果
完成本实践后，用户可以通过AI CLI自然语言对话完成以下闭环：
- 识别目标CCE集群、命名空间和异常工作负载。
- 自动汇聚工作负载状态、Pod状态、版本历史、事件、日志、探针和服务端点等证据。
- 输出可解释的根因分析，而不是只给出单条命令结果。
- 对恢复动作进行预览，明确风险、影响范围和验证方式。
- 在用户确认后执行受控恢复动作。
- 自动验证恢复结果，并输出后续修复建议。
后续建议
为了提升CCE工作负载故障处理效率，建议结合本实践沉淀以下能力：
