AI SRE

CFOperator：面向 homelab 基础设施的自托管 AI SRE 智能体

aachtenberg/cfoperator · AI-powered SRE agent for homelab infrastructure monitoring, OODA sweeps, RAG memory, and remediation workflows

CFOperator 是一个自托管 AI SRE 智能体，用于监控 homelab 基础设施并按 alert → triage → investigate → propose a fix → open a GitOps PR → verify after merge 的流程处理告警。它通过本地 LLM 对 Alertmanager 告警分级，使用工具循环查询 Prometheus、Loki、Kubernetes 和 Docker，并以 pgvector 知识库检索历史调查记录，最终生成针对 manifest 仓库的具体 diff 并开 PR，但不直接改动运行中的集群。它还每 30 分钟执行一次主动巡检，并可通过聊天、Slack 或 MCP 主机进行问答。

AI 改变了你应对事故的方式，但你的桌面演练还没跟上

Webflow 公司花了一年时间把 AI 用在事故响应的环节里，比如整理告警、调取处置手册、提出应对建议，甚至起草事后复盘。这样一来，AI 已经成了事故响应系统的一部分。但问题在于，传统的桌面演练只测试人，默认工具是固定的、不会出错的，所以没人演练过 AI 出错时该怎么办。作者建议在演练里加一层专门针对 AI 的故障注入，比如 AI 自信地给出错误结论、AI 系统本身不可用、有人绕过安全护栏、团队忘了手动操作的老办法，以及 AI 建议和人工决策之间的交接边界是否清楚。目前这些建议还只是实践者的经验分享，没有提到具体的产品或工具。

你的 AI 代理刚刚创建了资源，谁来负责？

这篇文章讲的是 AI 代理（就是自动帮你干活的程序）在云上创建资源后没人管的问题。环境里有 34 个资源，比如网络、数据库和负载均衡器，有些已经几周没流量了，但标签上的“负责人”写的是 deploy-agent，根本查不到真人。以前员工离职至少有交接记录和上级接手，代理干完活后上下文一关，留下的东西就没人认领了。解决办法是用查询找出哪些资源的“负责人”其实是服务账号而不是真人，再用一条审批策略拦住新部署——除非每个资源都填了真人的邮箱，否则不允许通过。这样运维和财务就不会被遗忘的资源持续烧钱。