Flashduty Incident Management

FlashDuty 事件管理

本技能管理事件的生命周期。简单操作直接执行；复杂查询委托给 Sub-Agent。

前置条件

• FlashDuty API 授权：用户已配置 FlashDuty MCP 工具，API 连接可用
• 频道访问权限：用户有权访问目标协作空间（Channel）
• 数据保留期限：查询受 FlashDuty 数据保留策略限制

内部逻辑模式

本技能采用 Pipeline 模式：通过决策树判断操作类型，简单操作直接执行，复杂查询委托给 Sub-Agent。

SRE 集成

本技能遵循 SRE 最佳实践：

事件严重级别与 SLO 影响

创建或更新事件时，考虑 SLO 影响：

• Critical (严重): 可能违反 SLO，需要立即响应
• Warning (警告): 如果不处理可能会降低 SLO
• Info (信息): 监控但通常不影响 SLO

事后工作流程

解决事件后：

用户: "事件已解决，生成事后分析"
→ 步骤 1: 直接解决事件
→ 步骤 2: 委托给 sre-practices 技能
   启动: postmortem-generator
→ 步骤 3: 安排行动项

错误预算影响

关闭带有根因的事件时：

• 如果影响 SLO，则跟踪到错误预算
• 使用 error-budget-tracker 进行多事件分析

直接操作（无需 Sub-Agent）

这些简单操作立即执行：

Sub-Agent 委托

flashduty-incident-analyzer

用于: 复杂事件查询、过滤、搜索

何时委托:

• 用户要求 "find incidents" 但没有具体 ID
• 需要复杂过滤（多个条件）
• 需要聚合或分组结果

参数:

{
  "filters": { "severity": "...", "progress": "...", "title": "..." },
  "time_range": "7d",
  "group_by": "severity" | "channel" | "labels.xxx",
  "brief": true
}

注意：优先使用 time_range（如 '7d'、'24h'、'last_week'）而非手动计算 start_time/end_time。使用 brief: true 减少数据量。

决策树

用户请求：
├─ 直接操作 (ack/resolve/snooze/comment/update/assign) + 提供 ID
│  └─ 直接使用 MCP 工具执行
│
├─ 创建事件
│  └─ 收集必需字段 → 直接创建
│
├─ 更新事件字段（标题/描述/严重级别/影响/根因/解决方案）
│  └─ 直接使用 update_incident 执行
│
├─ 分配/指派事件
│  └─ 直接使用 assign_incident（type: "assign" + person_ids 或 type: "escalateRule" + escalate_rule_id）
│
├─ 查询/搜索/列出事件
│  └─ 委托给 flashduty-incident-analyzer
│
└─ 混合 (例如 "ack all critical incidents")
   └─ 步骤 1: 委托 analyzer 查找匹配项
   └─ 步骤 2: 与用户确认
   └─ 步骤 3: 直接执行 ack

不适用场景：批量创建 200+ 事件（应使用批处理 API）、纯统计分析（使用 incident-analytics）。

工作流模式

模式 1: 直接操作

用户: "确认事件 FD123456"
→ 直接调用 mcp__flashduty__ack_incidents
→ 确认完成

模式 2: 先查询后操作

用户: "确认今天所有 triggered 状态的事件"
→ 步骤 1: 启动 analyzer 查找匹配事件
     filters: { progress: "Triggered" }, time_range: "24h"
→ 步骤 2: 向用户展示列表，确认
→ 步骤 3: 使用列表调用 ack_incidents

模式 3: 创建事件

用户: "为数据库故障创建一个严重级别的事件"
→ 收集必需信息（标题、严重级别、描述）
→ 直接调用 create_incident
→ 返回事件 ID

模式 4: 复杂搜索

用户: "查找本周基础架构 channel 的所有 Critical 事件"
→ 启动 incident-analyzer
   filters: { severity: "Critical", channel_name: "基础架构" }
   time_range: "7d"
   brief: true
→ 展示结果

并行执行

批量操作

当用户提到多个不相关的事件时：

用户: "展示事件 A、B 和 C"
→ 并行：
  Agent 1: 获取事件 A 详情
  Agent 2: 获取事件 B 详情
  Agent 3: 获取事件 C 详情
→ 展示合并结果

多 Channel 查询

用户: "列出基础架构和数据库两个 channel 的 triggered 事件"
→ 并行：
  Agent 1: 查询基础架构 channel（brief: true）
  Agent 2: 查询数据库 channel（brief: true）
→ 合并并展示

响应模式

直接操作成功

[操作] 成功完成。
- 事件: [ID]
- 状态: [新状态]
- [附加详情]

批量操作成功

[操作] 已完成 [N] 个事件：
- [ID 1]: 成功
- [ID 2]: 成功
...

查询结果

找到 [N] 个匹配条件的事件：

| ID | 标题 | 严重级别 | 状态 | Channel |
|----|------|---------|------|---------|
|... |...  |...      |...   |...      |

[操作按钮或建议]

错误处理

• 缺少必需字段: 请用户提供
• 无效的事件 ID: 搜索类似事件
• 权限被拒绝: 告知用户并建议替代方案
• 结果集过大: 分页或建议过滤条件
• 时间范围超出保留期限: FlashDuty 有数据保留期限，只能查询最近 N 天的数据。遇到此错误时，自动缩短查询范围为最近可查询的时间段
• 时间顺序错误: 确保 start_time < end_time。使用 Unix 秒级时间戳

时间范围处理最佳实践

推荐使用 time_range 参数：

# 简单直观，无需计算时间戳
time_range: "24h"    # 最近 24 小时
time_range: "7d"     # 最近 7 天
time_range: "30d"    # 最近 30 天
time_range: "last_day"   # 昨天整天
time_range: "last_week"  # 上周整周

当需要精确时间范围时，使用 start_time+end_time：

如果查询失败（超出保留期限），逐步缩短时间范围：

• 尝试最近 7 天
• 如果失败，尝试最近 3 天
• 如果失败，尝试最近 1 天

Converted and distributed by TomeVault — claim your Tome and manage your conversions.