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, 一键操作, 上下文关联, 仪表盘, 偏差过滤, 决策支持, 单点登录, 可观测性, 告警管理, 多工具整合, 应急指挥, 应用安全, 快速排查, 情境图谱, 日志查询, 站点可靠性工程, 终端集成, 运维平台, 运行手册, 防御加固