Austin5578/incident-response-bot

# incident-response-bot [](https://github.com/Austin5578/incident-response-bot/actions/workflows/test.yml) [](https://github.com/Austin5578/incident-response-bot/actions/workflows/build.yml) [](LICENSE) ## 这是什么 在经历第三次凌晨 3 点的呼叫后我构建了这个项目，当时我不得不：将警报复制到 Slack，手动查找相关的 Grafana 仪表盘，截取屏幕截图，打开 Jira，创建工单，粘贴话题链接。每次呼叫都要进行五分钟的繁琐操作，在系统“着火”时每次事件都要重复一遍。 当 PagerDuty webhook 到达时，这项服务会自动完成上述所有五项操作。 ## 流程 ``` sequenceDiagram participant PD as PagerDuty participant Bot as incident-response-bot participant Graf as Grafana participant Jira participant Slack PD->>Bot: webhook POST /pagerduty/incident Bot->>Bot: validate signature Bot->>Graf: fetch panel snapshot URL
(matched by service tag) Graf-->>Bot: rendered PNG + perma-link Bot->>Jira: create incident ticket
(severity, service, link) Jira-->>Bot: ticket key (e.g. OPS-1234) Bot->>Slack: post threaded message
(alert + graph + ticket + ack button) Slack-->>Bot: thread_ts (for follow-ups) Bot->>PD: ack webhook (200) ``` 值班工程师醒来时会看到一条已经包含以下内容的 Slack 消息： - 警报详情（严重程度、服务、触发原因） - 显示触发警报的指标的 Grafana 面板 - 一个预先填好、可供后续编辑的 Jira 工单 - 一个一键确认按钮，同时更新 PagerDuty 和 Jira 工单 ## 运行 ### 本地开发 ``` cp .env.example .env # 填写 Slack bot token、PagerDuty webhook secret、Grafana API key、Jira creds docker compose up # Bot 监听 http://localhost:8080 ``` ### 使用模拟 PagerDuty webhook 在本地测试 ``` ./scripts/send-fake-incident.sh # 向 http://localhost:8080/pagerduty/incident 发布示例 payload # 检查你的 Slack workspace 中的 #incidents ``` ### 生产环境 ``` docker build -t incident-response-bot:latest . # 推送到你的 registry，部署到 K8s / ECS / 其他任何地方 # 在 PagerDuty 中设置 webhook URL：https://your-bot.example.com/pagerduty/incident ``` ## 配置 所有配置均通过环境变量完成。完整列表请参见 `.env.example`。主要配置项： | 变量 | 说明 | |---|---| | `SLACK_BOT_TOKEN` | `xoxb-...` bot token，需要 `chat:write` + `chat:write.public` 权限 | | `SLACK_INCIDENT_CHANNEL` | 事件线程发送的目标 Channel ID（例如 `C01234`） | | `PAGERDUTY_WEBHOOK_SECRET` | 用于 HMAC 签名验证的共享密钥 | | `GRAFANA_BASE_URL` | 例如 `https://grafana.example.com` | | `GRAFANA_API_KEY` | 具有 `Viewer` 角色的 Service account token | | `JIRA_BASE_URL` | 例如 `https://your-org.atlassian.net` | | `JIRA_EMAIL` + `JIRA_API_TOKEN` | 认证信息 | | `JIRA_PROJECT_KEY` | 例如 `OPS` — 事件将记录在此项目中 | ## 接口 | 接口 | 认证 | 说明 | |---|---|---| | `POST /pagerduty/incident` | PagerDuty HMAC | 主 webhook — 驱动上述流程 | | `POST /slack/interaction` | Slack signed-secret | 处理确认按钮和下拉菜单操作 | | `GET /healthz` | 无 | 存活/就绪探针 | | `GET /metrics` | 无 | Prometheus 抓取 endpoint | ## 项目结构 ``` src/incident_bot/ ├── app.py # FastAPI app + routes ├── config.py # env var loading + validation ├── models.py # Pydantic models for PD/Slack/Jira payloads ├── handlers/ │ ├── pagerduty.py # parse + dispatch incoming webhooks │ └── grafana.py # match alert → dashboard panel └── integrations/ ├── slack.py # send threaded messages, handle interactions ├── jira.py # create + update tickets └── grafana.py # render panel snapshots via /render API ``` ## 为什么选择 FastAPI（而不是 Flask） 参见 [docs/ADR-001-fastapi-over-flask.md](docs/ADR-001-fastapi-over-flask.md)。简而言之：异步 I/O 在这里很重要，因为 bot 每个 webhook 会发出约 5 次出站 API 调用，而序列化也很重要，因为 PagerDuty 的 payload schema 嵌套很深。 ## 限制与诚实的注意事项 - **无 PagerDuty 重放保护。** HMAC 检查验证了真实性，但重放的 webhook 会重新触发流程。在生产环境中，应添加随机数或时间戳检查（大约 10 行代码，在 `handlers/pagerduty.py` 中）。 - **仅限单一 Slack workspace。** 多 workspace 需要重新设计身份验证层。 - **无事件时间线跟踪。** 该 bot 触发后即忘记；将后续的 webhook（升级、解决）与原始线程关联是 v2 版本的功能。 - **Grafana 面板匹配依赖标签。** 如果您的警报和仪表盘未使用 `service` 统一标记，bot 将回退到通用的“系统健康”面板。 ## 许可证 MIT — 参见 [LICENSE](LICENSE)。

标签：AV绕过, Docker, FastAPI, Grafana, IT运维, Jira, NIDS, PagerDuty, Python, SecOps, Slack机器人, Socks5代理, SRE, Webhook处理, 云安全架构, 偏差过滤, 告警管理, 告警聚合, 告警路由, 安全运营, 安全防御评估, 容器化, 应急响应平台, 扫描框架, 无后门, 服务集成, 监控集成, 站点可靠性工程, 网络信息收集, 自动化机器人, 自定义请求头, 请求拦截, 运维自动化, 逆向工具