Lerwee Alert To Fault Handling

核心用法

alert-to-fault-handling 是一款面向运维场景的智能告警处理工作流技能。其核心机制是监听对话中的告警上下文（eventid、IP、告警名称），通过群组识别与关键词匹配，自动推荐对应的故障处理脚本，引导用户一键执行。

工作流程遵循：告警检测 → 群组/分类匹配 → 脚本推荐 → 用户确认 → 执行脚本 → 结果反馈的闭环。用户可通过回复「执行」「确认」等指令触发预置脚本（如 nginx 重启、磁盘清理），也可手动指定 script_id 执行特定脚本。

显著优点

1. 上下文感知自动化：无需手动查询，自动从告警消息中提取 IP、eventid 等关键信息，减少信息录入错误
2. 精准匹配机制：支持多级匹配（群组 → 分类 → 关键词），确保推荐脚本的针对性
3. 完整的审计链路：所有执行记录到 .execution_log.json，包含时间戳、执行人、状态、输出详情，满足合规要求
4. 灵活的扩展性：通过修改 .scripts_map.json 即可添加新脚本类型，无需改动核心逻辑
5. 可选的告警闭环：执行成功后支持自动关闭对应告警，减少人工干预

潜在缺点与局限性

1. 依赖预置配置：新告警类型需提前配置 scripts_map，无法自动适配未知告警
2. IP 获取存在单点依赖：若告警消息无 IP 且 objectid 查询失败，流程中断
3. 缺乏权限细粒度控制：配置文件中未体现执行权限分级（如生产环境需审批）
4. 回滚能力有限：仅支持查询历史结果，无自动回滚机制
5. 多主机并发场景未明确：示例均为单 IP 执行，批量主机处理逻辑未详述

适合人群

• 运维工程师/SRE：需要快速响应常规告警（nginx、磁盘、数据库等）
• 值班人员：通过飞书群接收告警，希望一键处理减少登录跳板机操作
• 中小规模技术团队：告警类型相对标准化，有精力维护 scripts_map 配置

常规风险

| 风险类型 | 说明 | 缓解措施 |

|---------|------|---------|

| 误执行风险 | 关键词匹配错误导致执行错误脚本 | 强制用户二次确认，白名单机制 |

| 生产事故 | 重启类脚本在高峰期执行导致服务中断 | 建议配置执行时间窗口（未实现） |

| 日志篡改 | 本地 json 日志文件可被手动修改 | 建议接入中心化日志系统 |

| API 泄露 | `lerwee-api.sh` 脚本可能包含敏感凭证 | 需确保脚本权限与密钥管理 |

安全等级评估

• 用户确认机制：强 ✅ 必须回复明确指令方可执行
• 输入校验：中等 ⚠️ IP 依赖外部查询，存在失败场景
• 权限隔离：弱 ❌ 未体现用户角色与脚本权限的映射
• 审计完整性：强 ✅ 执行链路全记录

综合评估：适合标准化告警场景，生产环境建议补充执行时间窗口、权限分级、中心化日志等增强措施。

核心用法

alert-to-fault-handling 是一款面向 DevOps 和运维团队的智能告警自动处理工作流技能。其核心机制是通过监听对话中的告警上下文（eventid、IP、告警名称），自动识别飞书群组与监控分类的匹配关系，基于关键词匹配推荐预置的故障处理脚本，最终经用户一键确认后执行修复操作。

使用流程高度自动化：当对话中出现告警信息时，系统首先提取告警对象的关键标识，随后在 .scripts_map.json 配置文件中检索匹配的脚本（如 nginx 重启、磁盘清理等），并向用户推送包含脚本说明、适用场景的执行建议卡片。用户回复「执行」或「确认」后，skill 调用 fault-handling 组件在目标主机上执行脚本，全程记录到 .execution_log.json 审计日志，并可选择自动关闭已修复的告警。

显著优点

1. 极致响应速度：从告警检测到脚本执行完成，整个流程可在秒级完成，显著缩短故障恢复时间（MTTR）。

2. 零代码运维：通过 JSON 配置即可扩展新脚本类型，无需修改核心代码，降低运维自动化门槛。

3. 多重安全屏障：内置用户确认机制（禁止自动执行）、白名单脚本管控、完整审计日志，符合企业合规要求。

4. 智能上下文感知：自动解析告警消息中的 IP、eventid、objectid 等多源信息，无需手动输入目标主机。

5. 生态无缝集成：深度集成飞书群组工作流，与 Zabbix/Lerwee 监控体系打通，形成告警-处理-反馈闭环。

潜在缺点与局限性

1. 外部依赖耦合：核心功能依赖 fault-handling 和 lerwee-api 两个外部 skill，任一组件故障将导致服务中断。

2. subprocess 执行风险：虽参数受控，但 Python subprocess 调用外部命令的架构本身存在潜在攻击面。

3. 配置驱动局限：复杂故障场景难以用简单关键词匹配覆盖，需人工介入判断的边界案例较多。

4. 网络隔离环境受限：依赖外部 API 查询主机详情，在无外网或 API 不可达环境下面临功能降级。

适合的目标群体

• 企业 SRE/DevOps 团队：需要标准化故障处理流程、降低人工操作失误的中大型运维组织
• 云原生架构运维者：管理大量 Nginx、MySQL、中间件实例的 Kubernetes/云服务器环境
• 7×24 值班团队：追求告警响应自动化、减少夜间人工醒来的 on-call 工程师
• 金融/政务合规场景：需要完整操作审计日志、双人确认机制的高安全要求行业

使用风险

1. 依赖可用性风险：fault-handling 或 lerwee-api 升级变更可能导致接口不兼容，建议锁定版本并监控依赖健康状态。

2. 配置漂移风险：.scripts_map.json 手动编辑易引入语法错误或逻辑漏洞，建议配置变更走 GitOps 流程并添加 schema 校验。

3. 权限扩散风险：执行脚本通常需要目标主机的高权限账户（如 root），需确保 credential 托管系统的安全性。

4. 日志泄露风险：.execution_log.json 包含 IP、用户标识等操作痕迹，多租户环境需严格文件权限控制（建议 600）。

5. 误操作放大风险：批量主机执行场景下，脚本错误可能导致大规模服务中断，建议生产环境先在灰度环境验证脚本。