夜莺 v9 AI：给每个 SRE 配一个 7x24 在线的资深副驾驶

做过 on-call 的人都熟悉这几个瞬间：

• 半夜被一条告警吵醒，盯着手机想"这到底是真的挂了，还是又误报了"，爬起来开电脑、翻指标、看邻居机器，二十分钟过去，结论是"虚惊一场"。
• 新接了一个业务，要给上百台机器配一套监控，PromQL、阈值、持续时间、通知规则一项项点，一两个小时就没了。
• 新人来值班，团队的排障套路全在几个老员工脑子里，文档写了也没人看，真出事还是得喊人。

这些事的共同点是：它们都依赖经验，而经验偏偏是团队里最稀缺、最难复制、最容易随人走的东西。

夜莺 v9 想解决的，正是这件事。它没有把 AI 做成一个孤立的"问答机器人"，而是把它做成了一个懂你这套系统的资深 SRE 副驾驶——它认识系统里所有的告警规则、机器和历史数据，了解你的数据源、常用指标和通知模板，还能复用团队沉淀下来的排障方法论。7x24 在线，随叫随到。

下面我们就从五个最真实的场景，看看这个副驾驶到底能干什么。

一、On-call 告警真假判定：20 分钟 → 2 分钟

收到告警，第一反应永远是"这是真的吗"。

在夜莺 v9 里，你不用再爬起来翻一圈。直接在通知卡片或事件详情页打开 Copilot，问一句 “这条告警是真的吗”，AI 会替你把一个老 SRE 该看的证据全看一遍：

• 心跳层 —— Redis 心跳时间、延迟了多少秒；
• 指标层 —— CPU、内存、网络的趋势数据；
• 邻居层 —— 同业务组里其他机器是什么状态；
• 屏蔽层 —— 现在是不是在维护窗口里。

然后给你一个有依据的结论，而不是一句空泛的"可能有问题"。原来要二十分钟的判断，现在两分钟就能出结果。

二、告警事件分析：看懂这条告警到底在说什么

确认是真告警之后，下一个问题是"它具体在说什么、该怎么看"。

在事件详情页直接问 AI，它会帮你把这条告警事件的来龙去脉讲清楚：解析告警规则的定义（PromQL、阈值、持续时间到底卡的是哪一条）、拉出涉及指标的历史趋势、看看同时段还有没有相关告警一起冒出来、对照主机的 CPU / IO / 网络数据。

最后给你的不是一堆原始数据，而是一段读得懂的事件解读 + 一条证据链 + 下一步该看哪里的建议。新人碰到一条陌生告警不再发懵，老手也省去了反复翻规则、翻指标的功夫。

三、新业务监控体系搭建：一句话 → 一条规则

搭监控这件事，繁琐但不难，最适合交给 AI。

你只需要用大白话描述需求，比如：

给所有生产环境（label env=prod）的主机加一条 CPU 使用率 > 90% 的二级告警。

AI 会自动完成：选定业务组和标签筛选条件 → 生成对应的 PromQL → 配好阈值、时间窗、告警级别 → 关联通知规则 → 直接把规则创建出来。

原来要一两个小时一项项点的活，现在十五分钟就能搞定。

四、日常零碎运维：把 30 分钟的小事压成 3 分钟

运维日常里有大量"不难但烦"的小任务，最消耗精力。这些 AI 都能接：

• 改通知模板 —— “给告警卡片加上业务组字段”；
• 临时屏蔽 —— “屏蔽 host=web01 的所有告警 2 小时”，一句话生成屏蔽规则；
• 接入新通知平台 —— 给出完整的 Webhook 配置，连签名、headers 这些坑都帮你避开；
• 排查发送失败 —— 解释错误码，给一份排查 checklist；
• 查事件、查资源 —— “最近 1 小时的一级告警有哪些”。

每一项原来要 3 到 30 分钟，现在基本三分钟以内就能搞定。

五、写自己的 Skill：把团队的打法装进 AI

这是夜莺 v9 AI 里我个人最看重的一块。

团队最值钱的资产，是资深 SRE 脑子里的排障方法论。但这些经验过去只能靠口口相传、靠拉人、靠新人慢慢踩坑攒出来。夜莺 v9 引入了 Skill 的概念来解决它：

资深 SRE 用 Markdown 把自己的排障套路写成一个 Skill，上传到夜莺。当 AI 遇到匹配的场景时，会自动加载这个 Skill，按既定方法论一步步引导新人。

也就是说，新人遇到问题问 AI，得到的不是泛泛的 GPT 式回答，而是你们团队自己的那套打法。新人从入职到能独立值班，周期能从 2-4 周缩短到 1-2 周。

更省心的是，夜莺 v9 二进制里内置了 19 个开箱即用的 Skill，覆盖一线 SRE 日常 90% 的动作，不写一行也能直接用。它们分成五大类：

这些内置 Skill 的作者显示为 system，开箱即用、不可在 Web 端改动——但它们只是起点。

重头戏：写出贴合你自己场景的 Skill

内置的 19 个 Skill 解决的是"人人都会遇到"的通用动作。而一个团队真正的硬核经验，往往藏在那些只有你们才有的场景里：

• 自研中间件出问题该看哪几个指标、按什么顺序排查；
• 大促期间的巡检套路和扩容判断标准；
• “MySQL 主从延迟"告警在你们这套架构下的标准处理流程；
• 某次历史故障踩过的坑、事后定下来的应对预案。

这些东西没有任何通用大模型能凭空知道，却恰恰是最该沉淀下来的。在夜莺 v9 里，把它变成一个 AI 会用的 Skill，只要三步：

1. 用 Markdown 写 —— 像写一篇排障 wiki 一样，讲清楚"什么场景、按什么步骤、看什么数据、调用哪个工具”；
2. 写好触发描述 —— AI 靠"用户提问 + Skill 描述"来匹配，关键词写清楚，命中时就自动加载；
3. 上传，立即生效 —— 之后任何人在这个场景问 AI，拿到的都是你们团队自己的打法，而不是泛泛而谈的通用回答。

而且这套机制对用户足够友好：

• 你写的优先：和内置 Skill 同名时以你的为准，想改默认行为随时能覆盖；
• 兼容 Anthropic Agent Skills 规范：支持导入导出，团队之间、社区之间可以直接共享 Skill；
• 越用越厚：每复盘一次故障、每总结一套新套路，就多沉淀一个 Skill —— 团队经验从"人走茶凉"变成"留在系统里持续复利”。

一句话：内置能力决定了夜莺的下限，而你能写出多少贴合自己场景的 Skill，决定了它的上限。

处处可达：AI 嵌在你已经在用的地方

夜莺 v9 没有把 AI 关进一个单独的对话框，而是把它嵌到了你日常操作的每一个入口：

安全边界：能放心交给它的前提

AI 能干这么多事，前提是它守规矩。夜莺 v9 给 AI 立了几条边界，前三条是写进架构、绕不过去的硬约束：

• 不自主执行 —— AI 工具箱里根本没有"执行命令"的工具，它只能产出带执行标记的推荐，真正执行得人在前端点确认、再走原有 ibex 链路，架构上它自己跑不了脚本。
• 不越权读取 —— AI 每次调工具都带着当前登录用户的身份，复用夜莺现成的 RBAC 和业务组隔离，没权限的操作直接被拒，非管理员也只能看到自己业务组的数据。
• 数据不离域 —— 没有任何中央或第三方中转服务，大模型地址和密钥都是你自己填的，请求由你部署的夜莺直连你配置的 LLM。

另外两条，靠的是内置 Skill 里写死的行为准则加"人工确认"兜底：

• 不乱给危险命令 —— 内置 Skill 带着一份危险命令黑名单（rm -rf /、mkfs、shutdown 等）要求 AI 拒绝生成，kill -9、systemctl restart 这类则要求先加护栏再给。
• 有风险的建议会说清风险 —— 这类推荐输出结构固定，结尾必须留一段「误报风险」讲清它可能判断错的情况，遇到 critical 或涉及 root、核心库还会强制降级、提示人工二次确认。

模型自己选：从公网 API 到完全离线

数据隐私是很多企业用 AI 的最大顾虑。夜莺 v9 在这点上把选择权完全交给你——底层用哪个大模型，由你决定：

三步就能上手

1. 接模型（5 分钟） —— 进「AI 配置 → LLM 管理」，填 API URL、API Key、模型名，点「测试连接」验证，设为默认。
2. 试场景（15 分钟） —— 在前面说的五个场景里逐一触发 AI，看看哪些最适合你的团队。
3. 写第一个 Skill（10 分钟） —— 把团队最高频的那个 SOP 数字化成 Skill，让新人立刻受益。

写在最后

监控行业聊 AIOps 已经聊了很多年，但不少产品的 AI 还停留在"做几张异常检测的图"。夜莺 v9 想往前走一步：它不替你值班，而是把过去只能靠老员工口口相传的那些经验，沉淀成一个随手能问、人人可用的副驾驶。

夜莺 v9 已经发布 beta 版本，AI 能力默认内置。详细配置见官方文档：

• 📖 AI 能力总览
• 🧩 19 个内置 Skill 一览

欢迎下载试用，把你团队的那套打法，也写进夜莺里。