ops-fires

OPS ► 故障

运行时上下文

执行前，加载可用上下文：

1. 守护进程健康状况：读取 ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/daemon-health.json

   • 检查 infra-monitor 服务状态——如果未运行，预先收集的基础设施数据可能已过时
   • 如果 action_needed 不为 null → 立即将其作为潜在故障告知

2. 密钥：查询 ECS/CloudWatch 需要 AWS 凭据。

   密钥解析

   • 首先：检查 $AWS_ACCESS_KEY_ID / $AWS_PROFILE 环境变量
   • 然后：doppler secrets get AWS_ACCESS_KEY_ID --plain（如果偏好设置中已配置 doppler）
   • 然后：使用偏好设置中的 password_manager_config.query_cmd
   • Sentry 令牌：$SENTRY_AUTH_TOKEN → Doppler SENTRY_AUTH_TOKEN → 保管库

3. 偏好设置：读取 ${CLAUDE_PLUGIN_DATA_DIR}/preferences.json 中的 secrets_manager 配置，以确定要查询哪个保管库。

CLI/API 参考

aws CLI

命令	用法	输出
aws ecs list-services --cluster <name> --query 'serviceArns'	ECS 服务	ARN 列表
aws ecs describe-services --cluster <name> --services <arn> --query 'services[0].{status:status,running:runningCount,desired:desiredCount}'	服务健康状况	JSON
aws logs tail /ecs/<service> --since 1h --format short	ECS 日志	日志行（与 Monitor 配合使用可实时查看）

gh CLI（GitHub）

命令	用法	输出
gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt	最近的 CI 运行	JSON 数组
gh run view <id> --repo <repo> --log-failed	失败的 CI 日志	日志输出

sentry-cli / Sentry API

命令	用法	输出
sentry-cli issues list --project <slug> --status unresolved	未解决的问题	问题列表
curl -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" "https://sentry.io/api/0/projects/<org>/<proj>/issues/?query=is:unresolved"	MCP 不可用时的 API 备用方案	JSON 数组

---

Agent Teams 支持

如果设置了 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1，在同时调度多个修复 Agent 时使用 Agent Teams。这样可以：

• 让修复 Agent 共享发现（例如，API Agent 发现根本原因是数据库 → 基础设施 Agent 转而修复数据库）
• 你可以确定优先级：“先处理 CRITICAL ECS 问题，再处理 CI 故障”
• 实时进度：Agent 找到根本原因后会汇报，你可以按最佳顺序合并修复

团队设置（仅在启用该标志时，于调度阶段执行）：

TeamCreate("fire-fixers")
Agent(team_name="fire-fixers", name="fix-[service]", ...)

如果未设置该标志，请使用标准并行子 Agent。

预先收集的基础设施数据

${CLAUDE_PLUGIN_ROOT}/bin/ops-infra 2>/dev/null || echo '{"clusters":[],"error":"infra check failed"}'

CI 故障（过去 24 小时）

${CLAUDE_PLUGIN_ROOT}/bin/ops-ci 2>/dev/null || echo '[]'

外部项目健康状况

${CLAUDE_PLUGIN_ROOT}/bin/ops-external 2>/dev/null || echo '[]'

你的任务

分析预先收集的数据，包括外部项目。然后并行执行以下检查：

1. ECS 健康状况——解析基础设施数据，查找不健康的服务、已停止的任务和失败的部署。
2. Sentry——如果已连接 Sentry MCP，查询最近尚未解决的错误。否则注明该服务不可用。
3. CI——解析 CI 数据，查找失败的流水线以及损坏的 main/dev 分支。
4. GitHub Actions——gh run list --limit 20 --json status,conclusion,name,headBranch,createdAt 2>/dev/null
5. 外部项目——解析 ops-external 数据。将 auth_expired 标记为 HIGH（需要轮换凭据），将 unreachable/degraded 标记为 MEDIUM，将 not_configured 标记为 LOW。

按严重性对每个问题分类：

严重性	判断标准
CRITICAL	服务宕机、数据库无法访问、身份验证失效
HIGH	错误率升高、部署卡住、CI 主分支损坏
MEDIUM	非关键服务降级、测试不稳定
LOW	警告级别、无需紧急处理

---

输出格式

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► FIRES DASHBOARD — [timestamp]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CRITICAL
[service] — [issue] — [since]

HIGH
[service] — [issue] — [since]

MEDIUM
[service] — [issue] — [since]

ECS HEALTH
[cluster] [service] [desired/running] [status]

CI STATUS
[repo] [branch] [workflow] [status] [last run]

SENTRY (top errors, 24h)
[error] [count] [first seen] [project]

EXTERNAL PROJECTS
[alias] [source] [status] [details — e.g. auth_expired, unreachable]

──────────────────────────────────────────────────────

使用批量 AskUserQuestion 调用（每次最多 4 个选项）。只显示相关操作（例如：未发现问题时，跳过调度选项）：

AskUserQuestion 调用 1：

  [Dispatch fix agent for [top critical issue]]
  [Dispatch fix agent for [second issue]]
  [View logs for [service]]
  [More...]

AskUserQuestion 调用 2（仅在选择“More...”时）：

  [Open Sentry dashboard]
  [Open GitHub Actions]
  [All clear — nothing to do]

如果没有触发项：显示“ALL SYSTEMS OPERATIONAL”以及上次检查时间戳。

---

调度修复 Agent

用户选择修复问题时，先使用 AskUserQuestion 确认范围，再进行调度：

Dispatch fix agent for: [issue title]
  Severity: [CRITICAL/HIGH/MEDIUM]
  Repo: [repo]
  Error: [brief description]
  
  The agent will:
  - Investigate root cause in [repo]
  - Create feature branch with fix
  - Open PR for review

  [Dispatch agent]  [Show me the logs first]  [Skip — I'll fix manually]

确认后，启动一个 Agent，并提供：

• 错误详情和日志
• 访问相关代码仓库的权限
• 创建功能分支、修复问题并发起 PR 的指示
• 完成或受阻时反馈

基础设施问题使用 agents/infra-monitor.md Agent 定义。

如果 $ARGUMENTS 包含项目别名，则仅筛选该项目的服务。

---

原生工具用法

Monitor — 实时服务健康状况

调查触发项时，使用 Monitor 流式传输 ECS 任务日志或 GitHub Actions 运行记录：

Monitor(command: "aws logs tail /ecs/<service> --follow --since 5m")

Tasks — 事件跟踪

为每个活动触发项使用 TaskCreate 创建任务。调查、修复或升级触发项时，使用 TaskUpdate 更新任务。

WebFetch — 状态页面

诊断触发项时，使用 WebFetch 检查 AWS 状态页面（https://health.aws.amazon.com/health/status）、Vercel 状态页面或第三方 API 状态页面。

WebSearch — 已知故障模式

使用 WebSearch 查找错误模式是否与已知的 AWS／基础设施问题相符（例如，“ECS task stopped CannotPullContainerError” → 已知的 ECR 限流问题）。