MichaelNg2A/Hermes

Hermes 是对 AI 辅助的站点可靠性工程（SRE）、DevOps 和平台工程的开放式探索。 Hermes 的设计初衷并非取代工程师，而是通过证据、运维知识和引导式调查，同时保留人类的专业判断，帮助他们更快地了解生产事件。 # Hermes **Hermes 是一款 AI 辅助的态势感知引擎，专为站点可靠性工程（SRE）、DevOps 和平台工程设计。** Hermes 是一个开源探索项目，旨在研究 AI 如何通过证据、上下文、运维知识和引导式调查，帮助工程师更快地理解生产事件。 Hermes 并非旨在取代值班工程师。 Hermes 的初衷是帮助工程师更快地获得准确的态势感知，做出更明智的决策，并在整个事件响应过程中保留人类的专业判断。 ## 为什么开发 Hermes 当生产环境告警触发时，首要挑战通常不是修复问题。 首要挑战是理解现状。 值班工程师可能需要回答以下问题： - 最近发生了什么变更？ - 涉及哪些 service、namespace、node、deployment 或 dependency？ - runbook 中是怎么说的？ - 是否有相关的告警？ - metrics、logs、traces 和 Kubernetes Events 提供了什么线索？ - 以前发生过这种情况吗？ - 谁是受影响系统的负责人？ - 有哪些证据支持每种可能的解释？ - 在尝试修复之前应该验证什么？ Hermes 的存在是为了缩短**从告警触发**到**工程师获得态势感知**之间的时间。 ## 核心理念 Hermes 的构建基于知识、判断和执行之间的刻意分离。 Hermes 可以收集证据、关联上下文、检索运维知识，并生成假设。 人类始终对决策权、验证过程以及生产环境决策负责。 Hermes 受以下几项原则指导： - 先有证据，后有结论。 - 先有假设，后有建议。 - 先有调查，后有修复。 - 先有人工判断，后有具体执行。 - 先利用运维记忆，避免重复劳动。 - 先有学习认知，再谈盲目自动化。 ## Hermes 是什么 Hermes 旨在成为一个 AI 辅助的运维助手，能够帮助工程师完成： - 告警上下文收集 - 事件分类 - 证据关联 - Runbook 解读 - 引导式调查 - 组织知识检索 - 人工验证 - 事后复盘学习 ## Hermes 不是什么 Hermes **不是**： - 自主修复系统 - 值班工程师的替代品 - 通用聊天机器人 - 可观测性平台的替代品 - Runbook 的替代品 - 生产环境决策权威 Hermes 绝不应鼓励“勾选式审批”或对 AI 建议的盲目信任。 相反，Hermes 的存在是为了提供更充分的证据，从而让人类做出更明智的决策。 ## 初始 MVP 初始实现刻意聚焦于对 Hermes 推理引擎最小但实用的演示。 0.1 版本接受： - Kubernetes 告警 payload - 公开的 kube-prometheus runbook - 告警 metadata Hermes 会生成： - 事件摘要 - 支撑性证据 - 排序后的假设 - 建议的调查步骤 - 用于收集额外证据的命令 - 未知事项与前提假设 - 人工审批边界 - 来源参考 此 MVP 在不需要接入实时基础设施的情况下，展示了核心的推理引擎。 ## 长期愿景 Hermes 刻意采用渐进式的方式进行开发。 长期愿景远超出于初始实现，但项目将首先集中于验证核心态势感知引擎，随后再扩展至更多功能。 ## 设计目标 Hermes 应当帮助工程师回答： 其目标并非让 AI 听起来充满自信。 其目标是让人类的专业判断更加明智。 ## 项目状态 Hermes 目前处于早期探索阶段。 首次实现侧重于静态告警输入和公开的 Kubernetes runbook，随后才会向更丰富的运维知识和更广泛的事件理解方向扩展。 随着项目的成熟，将逐步引入更多功能，同时始终秉持项目的核心理念：

标签：API集成, SRE, 事故响应, 人工智能, 偏差过滤, 可观测性, 告警运营, 子域名突变, 用户模式Hook绕过, 自定义请求头, 运维, 逆向工具