rohitsalesforce132/crisis-command-center
GitHub: rohitsalesforce132/crisis-command-center
一个终端一体化危机指挥中心,通过整合监控、上下文与 AI 决策支持,解决多工具切换导致的响应断层问题。
Stars: 0 | Forks: 0
# 危机指挥中心
**一个实时事件响应仪表板,将监控、上下文和决策支持整合在一个地方。**
## 问题
你在值班。警报触发了。你有 5 分钟时间,否则会升级。
你今天要做的事:
- 打开 Grafana 查看指标
- 打开 kubectl 终端查看集群状态
- 在 Slack 中搜索“之前发生过吗?”
- 翻遍 Confluence 找运行手册
- 查看 PagerDuty 确认谁在响应
- 惊慌失措
**5 个工具。5 个标签页。零连贯性。**
## 解决方案
**危机指挥中心(Crisis Command Center)** — 一个展示以下内容的单一仪表板:
1. **当前事件面板** — 现在正在发生什么故障
2. **相似事件** — 3 个最相关的过去事件(带决策轨迹)
3. **一键操作** — kubectl、日志、运行手册、Slack 线程
4. **上下文图集成** — 先例决策、已知模式
5. **内置终端** — 无需离开仪表板即可使用 kubectl、az、jq
6. **AI 助手** — 已加载完整上下文图 + 事件历史
## 仪表板布局
```
┌─────────────────────────────────────────────────────────────────────┐
│ CRISIS COMMAND CENTER │
│ ┌──────────────────────┬──────────────────────────────────────┐ │
│ │ Current Incident │ Similar Incidents │ │
│ │ ────────────────── │ ─────────────────────────────────── │ │
│ │ Alert: Node NotReady│ 1. INC-001 (92% match) │ │
│ │ Cluster: prod-cluster│ • Disk pressure → cleanup ✅ │ │
│ │ Nodes: 3/8 down │ • DEC-001: Skip runtime restart │ │
│ │ Duration: 2 min │ 2. INC-004 (76% match) │ │
│ │ │ • Runtime restart → 45 min ❌ │ │
│ │ [View Live Metrics] │ 3. INC-006 (68% match) │ │
│ │ [View kubectl] │ • Partial cleanup → 18 min │ │
│ └──────────────────────┴──────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ DECISION SUPPORT │ │
│ │ ─────────────────────────────────────────────────────────── │ │
│ │ 💡 Suggestion: Skip container runtime restart │ │
│ │ Precedent: DEC-001 (INC-001) — saved 33 minutes │ │
│ │ Risk: LOW — 3 successful precedents, 0 failures │ │
│ │ │ │
│ │ 📋 Runbook: node-notready.md (step 2) ⚠️ CONFLICT │ │
│ │ Runbook says: "Restart container runtime" │ │
│ │ Context graph says: "Do NOT restart on disk pressure" │ │
│ │ │ │
│ │ [View Decision Trace] [View Incident Replay] [Chat AI] │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ TERMINAL (kubectl) │ │
│ │ ─────────────────────────────────────────────────────────── │ │
│ │ $ kubectl get nodes │ │
│ │ NAME STATUS ROLES AGE VERSION │ │
│ │ node-worker-03 NotReady worker 90d v1.28.0 │ │
│ │ node-worker-05 NotReady worker 90d v1.28.0 │ │
│ │ node-worker-06 NotReady worker 90d v1.28.0 │ │
│ │ │ │
│ │ [crictl rmi --prune] [journalctl --vacuum-time=2d] │ │
│ └───────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
```
## 工作原理
### 1. 事件检测
- 接入 Azure Monitor 告警(Webhook)
- 或从 Slack/PagerDuty 手动输入
### 2. 上下文检索
- 查询事件回放引擎,查找相似事件(语义搜索)
- 拉取决策轨迹、时间线、AI 回放
- 按相关性排序(告警类型、集群、时间、症状)
### 3. 决策支持
- 将当前状态与上下文图进行比对
- 标记运行手册与历史决策之间的冲突
- 提供带置信度分数的操作建议
### 4. 一键操作
- 预构建的 kubectl 命令(常见模式)
- 日志查询(tail、grep、过滤)
- 运行手册快捷方式
- Slack 线程链接
### 5. AI 助手
- 已加载完整事件历史
- 可回答:“上次发生了什么?”
- 可模拟:“如果重启运行时会发生什么?”
- 可解释:“为什么这是个坏主意?”
## 技术栈
**零依赖,纯 Markdown + bash:**
```
crisis-command-center/
├── README.md
├── dashboard.md # Terminal-based dashboard (fzf, tput)
├── scripts/
│ ├── incident-detect.sh # Parse alerts, create incident file
│ ├── similar-incidents.sh # Search replay engine for matches
│ ├── decision-support.sh # Query context graph
│ ├── launch-dashboard.sh # Start the dashboard
│ └── ai-query.sh # Query AI assistant
├── incidents/
│ └── active/ # Current incidents (Markdown + metadata)
├── templates/
│ └── incident-template.md
└── config/
├── clusters.yaml # Cluster configs
└── integrations.yaml # Azure Monitor, Slack, PagerDuty
```
**可选:** 如果需要基于浏览器的界面(React/Next.js)
## 关键特性
### 实时事件检测
- Azure Monitor 告警的 Webhook 接收器
- 自动创建带元数据的事件文件
- 触发相似事件搜索
### 语义相似度搜索
- 通过以下条件搜索事件回放引擎:
- 告警类型(Node NotReady、Pod CrashLoopBackOff 等)
- 集群名称
- 时间窗口
- 错误消息
- 返回带匹配分数的排序列表
### 决策支持引擎
- 查询上下文图获取先例
- 标记运行手册与历史决策之间的冲突
- 提供带风险分数的操作建议
### 内置终端
- 集成 kubectl、az、jq
- 预构建常见模式的命令
- 一键执行
### AI 助手
- 已加载事件回放引擎 + 上下文图
- 可模拟决策
- 可解释推理过程
## 使用流程
### 步骤 1:告警触发
```
[Webhook] → incident-detect.sh
→ Creates: incidents/active/INC-001-20260412-1423.md
→ Triggers: similar-incidents.sh
```
### 步骤 2:仪表板启动
```
./scripts/launch-dashboard.sh INC-001
```
展示:
- 当前事件详情
- 前 3 个相似事件
- 决策支持建议
- 待执行的命令
### 步骤 3:值班工程师响应
- 看到:“跳过运行时重启”(先例 DEC-001)
- 点击:[crictl rmi --prune]
- 节点在 12 分钟内恢复
### 步骤 4:事件后处理
- 仪表板自动生成事件回放
- 记录决策轨迹
- 更新上下文图
## 价值主张
| 指标 | 之前 | 之后 |
|------|------|------|
| 首次响应时间 | 5-10 分钟 | 30-60 秒 |
| 打开的工具数 | 5+ 个标签页 | 1 个仪表板 |
| 基于先例的决策 | 罕见 | 每次都有 |
| 平均 MTTR | 35 分钟 | 15 分钟 |
**危机指挥中心通过减少上下文切换并确保每个决策都基于先例,将 MTTR 降低了 50%。**
## 路线图
**第一阶段(MVP):**
- 基于终端的仪表板
- 来自 Azure Monitor 的事件检测
- 基于 grep 的相似事件搜索
- 基于 grep 的决策支持
- 内置终端
**第二阶段:**
- 语义相似度搜索(向量嵌入)
- 上下文图集成(完整 API)
- AI 助手集成
- Web 界面
**第三阶段:**
- 多集群支持
- Slack/PagerDuty 集成
- 自动化事件回放生成
- 模式检测(跨事件分析)
## 为何重要
**对于 Manav:**
- 他在值班 — 他会立即使用这个工具
- 他了解 Azure 和 k8s — 这是他的领域
- 他见过这种痛苦 — 上下文切换浪费时间
**对于 SRE 团队:**
- 降低 MTTR
- 降低值班压力
- 捕获并复用部落知识
- 使 AI 辅助事件响应成为现实
**对于生态系统:**
- 完善事件响应栈:
- 上下文图 SRE(存储决策)
- 事件回放引擎(回放事件)
- 危机指挥中心(实时响应)
## 下一步
1. **构建基于终端的仪表板**(fzf + bash)
2. **实现事件检测**(Azure Monitor Webhook)
3. **构建相似事件搜索**(基于 grep,后续升级到向量)
4. **与上下文图 SRE 集成**
5. **与事件回放引擎集成**
6. **使用真实事件进行测试**
## 灵感来源
- **Datadog 事件管理**(闭源,昂贵)
- **PagerDuty 事件响应**(专注于告警,而非上下文)
- **FireHydrant**(企业级,复杂)
**危机指挥中心:** 开源、简单、构建在我们已有的栈之上(上下文图 + 事件回放引擎)。
标签:AI助手, API集成, Confluence, Grafana, kubectl, PagerDuty, SaaS, Slack, SRE, 一键操作, 上下文关联, 仪表盘, 偏差过滤, 决策支持, 单点登录, 可观测性, 告警管理, 多工具整合, 应急指挥, 应用安全, 快速排查, 情境图谱, 日志查询, 站点可靠性工程, 终端集成, 运维平台, 运行手册, 防御加固