MCP依赖图与熔断器管理器v1.0,注册MCP依赖关系并拓扑排序,管理熔断器状态机(closed/open/half_open)与Bulkhead隔离舱,自动失败计数与恢复探测。触发:依赖注册/熔断检查/状态查询/熔断重置/级联故障分析/部署后验证
Coding
auto-healing-manager
Try it五阶段故障自愈闭环管理器v1.0,检测→诊断→修复→验证→回归完整闭环,30天无人值守期间故障自愈率80%。触发:故障自愈/自动修复/自愈管理/auto-healing/fault-healing/混沌工程/故障预案
What it does
五阶段故障自愈闭环管理器v1.0,检测→诊断→修复→验证→回归完整闭环,30天无人值守期间故障自愈率80%。触发:故障自愈/自动修复/自愈管理/auto-healing/fault-healing/混沌工程/故障预案
The skill document
核心功能: 本技能提供器v1等能力。
五阶段故障自愈闭环管理 v1.0 (ARCH-8)
检测→诊断→修复→验证→回归完整闭环,30天无人值守期间故障自愈率从0%提升至80%。
使用场景
- Prometheus指标异常触发自愈(检测阶段已由外部完成) 2. 容器崩溃自动重启 3. 磁盘满自动清理 4. LLM Provider限流自动切换 5. Cookie过期自动刷新 6. Gateway无响应自动重启 7. 故障后业务回归验证 8. 自愈历史查询与成功率统计 9. 混沌工程故障注入测试 10. 30天无人值守期间故障自动处置
核心概念
五阶段闭环: 检测(阶段1,接收fault_event)→诊断(阶段2,根因分析)→修复(阶段3,执行预案)→验证(阶段4,健康检查)→回归(阶段5,业务验证)。任一阶段失败则停止后续阶段并记录,避免级联错误。
故障预案库: config/fault_playbook.yaml定义11个常见故障预案(PG连接池耗尽/Docker容器停止/Cookie过期/LLM 429/磁盘满/Gateway无响应/MCP超时/Redis失败/网络分区/CPU高/内存泄漏),每个预案包含检测条件/诊断规则/修复步骤/验证方法/回滚方案。
冷却机制: 同一fault_type在300秒内不重复触发(可通过force=true强制覆盖),防止修复风暴。
并发控制: 最大3个并发自愈(asyncio.Semaphore),防止资源争用。
PG持久化: auto_healing_events表(event_id/fault_type/diagnosis/repair_action/verification_result/created_at),ThreadedConnectionPool(minconn=1,maxconn=5),PG不可用时降级到文件持久化。
工作流
流程A: 触发完整五阶段自愈(推荐)
- 调用trigger_healing(fault_type, fault_context, force=false)
- 阶段1检测: 接收fault_event,创建event_id
- 阶段2诊断: 调用diagnose_fault逻辑,匹配预案库,输出根因候选与置信度
- 阶段3修复: 调用auto_repair逻辑,执行预案中的修复步骤(支持{placeholder}替换与重试)
- 阶段4验证: 调用health_checks(Docker/Gateway/磁盘),确认故障已消除
- 阶段5回归: 调用business_regression逻辑,验证EP-01~EP-05链路完整性
- 全部通过→status=completed;任一失败→status=failed并记录error
- 持久化到PG(auto_healing_events表)与文件(data/auto_healing/state.json)
流程B: 独立诊断(不修复)
- 调用diagnose_fault(fault_type, fault_context)
- 加载预案库,匹配fault_type
- 评估诊断规则,输出根因候选与置信度
- 不执行修复,仅返回诊断结果(用于人工确认)
流程C: 独立修复(干跑模式)
- 调用execute_repair(fault_type, fault_context, dry_run=true)
- 加载预案,替换{placeholder}变量
- dry_run=true仅打印命令不执行(用于预览修复动作)
- dry_run=false执行修复命令(带重试,单步最多2次)
流程D: 独立验证
- 调用verify_repair(fault_type, fault_context)
- 执行健康检查: Docker/Gateway/磁盘
- 至少2/3项通过则验证通过
流程E: 独立回归
- 调用run_regression(fault_type, fault_context, full=false)
- 验证EP-01~EP-05核心链路: PG/Docker/Gateway/磁盘可写/磁盘空间
- 核心检查全过则ep_chain_ok=true
流程F: 查询历史
- 调用get_healing_history(limit=50, fault_type="", status="")
- 返回历史自愈事件列表(按created_at降序)
- 可按fault_type与status过滤
异常处理
| 异常 | 错误码 | 处理 |
|---|---|---|
| fault_type为空 | INVALID_ARG | 返回错误,提示必填 |
| fault_context非合法JSON | INVALID_JSON | 返回错误,提示格式 |
| 冷却中 | COOLDOWN_ACTIVE | 返回剩余秒数,提示用force=true强制 |
| 预案未找到 | PLAYBOOK_NOT_FOUND | 返回可用fault_type列表 |
| 阶段2诊断失败 | STAGE2_FAILED | 记录并停止,不执行修复 |
| 阶段3修复失败 | STAGE3_FAILED | 记录并停止,不执行验证 |
| 阶段4验证失败 | STAGE4_FAILED | 记录并停止,不执行回归 |
| 阶段5回归失败 | STAGE5_FAILED | 记录,EP链路可能受影响 |
| PG不可用 | (降级) | 自动降级到文件持久化,不报错 |
| MCP不可用 | TRIGGER_ERROR | 返回异常信息,记录日志 |
输入格式
{
"action": "trigger|diagnose|repair|verify|regression|history|healthcheck",
"fault_type": "docker_container_stopped",
"fault_context": "{\"container_name\":\"redis\"}",
"force": false,
"dry_run": false,
"full": false,
"limit": 50,
"status": "completed"
}
字段说明:
action: 操作类型(trigger触发/diagnose诊断/repair修复/verify验证/regression回归/history历史/healthcheck健康检查)fault_type: 故障类型标识(除history/healthcheck外必填)fault_context: 故障上下文JSON字符串(用于{placeholder}替换)force: 是否强制触发忽略冷却(仅trigger)dry_run: 干跑模式(仅repair)full: 全量验证(仅regression)limit: 历史条数(仅history,默认50)status: 按状态过滤(仅history,如completed/failed)
输出格式
{
"success": true,
"data": {
"event_id": "a1b2c3d4-...",
"fault_type": "docker_container_stopped",
"stages": {
"stage1_detection": {"status": "detected", "passed": true},
"stage2_diagnosis": {"status": "diagnosed", "passed": true, "diagnosis": {...}},
"stage3_repair": {"status": "repaired", "passed": true, "repair": {...}},
"stage4_verification": {"status": "verified", "passed": true, "verification": {...}},
"stage5_regression": {"status": "regressed", "passed": true, "regression": {...}}
},
"status": "completed",
"ep_chain_ok": true
},
"error": null,
"code": null
}
字段说明:
event_id: 自愈事件唯一ID(UUID)stages: 五阶段执行结果(stage1~stage5)status: 事件最终状态(completed/failed)ep_chain_ok: EP-01~EP-05链路是否完整(阶段5结果)
示例
示例1: Docker容器停止自愈
- 调用trigger_healing(fault_type="docker_container_stopped", fault_context='{"container_name":"redis"}')
- 阶段2诊断: 匹配预案,根因候选=["容器崩溃","OOM被杀","手动停止"]
- 阶段3修复: 执行
docker start redis,等待healthy - 阶段4验证: Docker健康=true, Gateway=true, 磁盘=true → 通过
- 阶段5回归: PG/Docker/Gateway/磁盘全过 → ep_chain_ok=true
- 返回:
{success:true, data:{status:"completed", ep_chain_ok:true}}
示例2: 磁盘满自愈(冷却中)
- 300秒内再次调用trigger_healing(fault_type="disk_full")
- 返回:
{success:false, data:{cooldown_remaining_sec:180}, error:"冷却中", code:"COOLDOWN_ACTIVE"} - 需用force=true强制触发
示例3: 干跑模式预览修复
- 调用execute_repair(fault_type="llm_provider_429", dry_run=true)
- 返回:
{success:true, data:{steps_executed:2, steps_succeeded:2, details:[{action:"switch_provider", dry_run:true}]}} - 未实际执行命令,仅打印预览
示例4: 查询历史自愈事件
- 调用get_healing_history(limit=10, status="failed")
- 返回:
{success:true, data:{events:[...], count:3}} - 返回最近10条失败的 自愈事件
验证标准
| 验证项 | 标准 |
|---|---|
| 五阶段闭环 | trigger_healing单次调用完整执行5阶段 |
| 阶段失败停止 | 任一阶段失败不执行后续阶段 |
| 预案库覆盖 | ≥10个常见故障预案(当前11个) |
| 冷却机制 | 同fault_type 300秒内不重复触发 |
| 并发控制 | 最大3个并发自愈 |
| PG持久化 | auto_healing_events表,ThreadedConnectionPool(1,5) |
| 文件降级 | PG不可用时降级到data/auto_healing/state.json |
| EP链路回归 | 阶段5验证PG+Docker+Gateway+磁盘4项核心 |
| 变量替换 | {placeholder}替换为context值 |
| 修复重试 | 单步最多2次重试 |
| 历史查询 | 支持按fault_type与status过滤 |
| 健康检查 | 返回预案数/PG状态/自愈统计 |
变更历史
| 版本 | 日期 | 变更内容 |
|---|---|---|
| v1.0 | 2026-07-07 | ARCH-8初始版本:五阶段闭环+11预案+PG持久化 |
Related skills
账号切换管理(封号换号),包括设备调度、好友迁移、账号状态管理、换号前好友筛选与通知。触发:封号检测/换号请求/风险预警
Cookie统一管理器,合并保活+紧急修复+健康检查三合一。功能:1.定时HTTP保活所有平台Cookie(闲鱼/抖音/快手/小红书/B站等13平台) 2.健康度评分0-100+健康度<60触发保活+3次连续失败写tenant_notification 3.4端Cookie同步检查与自动修复(fishclaw JSON/.env/global_config.yml/auto-reply API) 4.批量失效(≥2个)启动降级运营模式+备用Cookie自动切换+扫码恢复 5.多租户Cookie恢复SOP(备份恢复→备用切换→紧急告警三级降级)。触发:Cookie保活/Cookie检查/定时保活/Cookie过期告警/Cookie同步/Cookie批量失效/Cookie降级/cookie-keepalive-cycle/cookie-refresh/多租户Cookie恢复
工作流检查点管理器v1.0(ARCH-5),PG为唯一权威源,SQLite为本地可丢失缓存,支持崩溃后从PG重建。8工具:save_checkpoint保存检查点到PG+异步缓存SQLite/get_checkpoint从PG权威源读取/list_checkpoints列出工作流检查点/cache_to_sqlite显式缓存/get_cached_state快速读取(缓存未命中回退PG并回填)/rebuild_sqlite_cache从PG重建SQLite/verify_checkpoint_integrity一致性验证/healthcheck。触发:检查点保存/崩溃恢复/缓存重建/一致性验证/工作流状态持久化
能力退化预警与自愈:监测技能生态运行时健康,扫描各技能 learned_patterns.json,检测成功率 滑落(跌破阈值)与陈旧停滞(长期无操作),输出告警 + 推荐自愈动作(重注入 learner / 标 repair 缺口 / 重跑回归)。让元进化引擎在"能力悄悄变弱前"主动干预——一线大模型完全 不具备的元治理能力,是"超越之后能否稳定存续"的关键保障。
Huawei Cloud CCE auto-remediation runner skill that converts remediation intent into preview-first, confirm-required, post-verify execution plans. Use this s...