做过 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 | 干什么 |
|---|---|---|
| 部署接入 | categraf-deploy-guide |
直接给出 categraf 二进制 / Docker / Windows / K8s 的安装与上报配置 |
| 创建配置（自然语言转配置） | n9e-create-alert-rule |
支持 Prometheus、Loki、ES、ClickHouse、MySQL、PG 等十余种数据源建告警规则 |
n9e-create-alert-mute |
"屏蔽 host=web01 2 小时"式的屏蔽规则 | |
n9e-create-alert-subscribe |
按条件筛选并转发告警事件 | |
n9e-create-notify-rule |
级别 / 时段 / 通道 / 接收人都明确时的线性建规则 | |
n9e-create-dashboard |
给标题、类型、PromQL，生成完整仪表盘配置 | |
n9e-modify-task-tpl |
生成 / 修改自愈脚本（磁盘清理、重启服务、reload nginx 等） | |
| 通知 Copilot（三层分工） | n9e-notify-channel-copilot |
钉钉 / 飞书 / 企微 / 邮件 / 短信 / Webhook 的接入配置与发送排障 |
n9e-generate-message-template |
用 Go template 生成各平台专版的消息模板 | |
n9e-notify-rule-copilot |
复杂的分级路由："P1 工作时间钉钉+电话，非工作时间仅电话" | |
| 查询（只看数据不改配置） | n9e-query-alert-events |
查活跃 / 历史告警、看详情、做统计 |
n9e-query-datasource |
查询十余种数据源 | |
promql-generator |
自然语言 → PromQL | |
sql-generator |
自然语言 → SQL（MySQL / Doris / ClickHouse / PG） | |
| 排障诊断（从现象查问题） | ops-troubleshooting |
最宽口径的综合排查入口，多步骤定位问题 |
n9e-alert-rule-troubleshoot |
"为什么该报的告警没报出来" | |
n9e-host-health-diagnose |
主机失联综合判断：是真宕机、agent 假死、网络抖动还是在维护 | |
n9e-host-onboard-diagnose |
新装 categraf 接入不进来的诊断 | |
n9e-recommend-self-heal |
告警半自愈推荐 |
这些内置 Skill 的作者显示为 system，开箱即用、不可在 Web 端改动------但它们只是起点。
重头戏：写出贴合你自己场景的 Skill
内置的 19 个 Skill 解决的是"人人都会遇到"的通用动作。而一个团队真正的硬核经验，往往藏在那些只有你们才有的场景里：
- 自研中间件出问题该看哪几个指标、按什么顺序排查；
- 大促期间的巡检套路和扩容判断标准；
- "MySQL 主从延迟"告警在你们这套架构下的标准处理流程；
- 某次历史故障踩过的坑、事后定下来的应对预案。
这些东西没有任何通用大模型能凭空知道，却恰恰是最该沉淀下来的。在夜莺 v9 里，把它变成一个 AI 会用的 Skill，只要三步：
- 用 Markdown 写 ------ 像写一篇排障 wiki 一样，讲清楚"什么场景、按什么步骤、看什么数据、调用哪个工具"；
- 写好触发描述 ------ AI 靠"用户提问 + Skill 描述"来匹配，关键词写清楚，命中时就自动加载；
- 上传，立即生效 ------ 之后任何人在这个场景问 AI，拿到的都是你们团队自己的打法，而不是泛泛而谈的通用回答。
而且这套机制对用户足够友好：
- 你写的优先：和内置 Skill 同名时以你的为准，想改默认行为随时能覆盖；
- 兼容 Anthropic Agent Skills 规范：支持导入导出，团队之间、社区之间可以直接共享 Skill；
- 越用越厚：每复盘一次故障、每总结一套新套路，就多沉淀一个 Skill ------ 团队经验从"人走茶凉"变成"留在系统里持续复利"。
一句话：内置能力决定了夜莺的下限，而你能写出多少贴合自己场景的 Skill，决定了它的上限。
处处可达：AI 嵌在你已经在用的地方
夜莺 v9 没有把 AI 关进一个单独的对话框，而是把它嵌到了你日常操作的每一个入口：
| 入口 | 能力 |
|---|---|
| 右上角 Nightingale AI 图标 | 全站对话，自动识别场景 |
| 告警事件详情页 | 触发原因、误报判定 |
| 通知模板编辑器 | 「AI 生成」按钮，自然语言写模板 |
| PromQL 输入框 | AI 生成查询语句 |
| SQL / 日志查询框 | AI 生成 SQL / LogQL / ES DSL |
安全边界：能放心交给它的前提
AI 能干这么多事，前提是它守规矩。夜莺 v9 给 AI 立了几条边界，前三条是写进架构、绕不过去的硬约束：
- 不自主执行 ------ AI 工具箱里根本没有"执行命令"的工具，它只能产出带执行标记的推荐，真正执行得人在前端点确认、再走原有 ibex 链路，架构上它自己跑不了脚本。
- 不越权读取 ------ AI 每次调工具都带着当前登录用户的身份，复用夜莺现成的 RBAC 和业务组隔离，没权限的操作直接被拒，非管理员也只能看到自己业务组的数据。
- 数据不离域 ------ 没有任何中央或第三方中转服务，大模型地址和密钥都是你自己填的，请求由你部署的夜莺直连你配置的 LLM。
另外两条，靠的是内置 Skill 里写死的行为准则加"人工确认"兜底：
- 不乱给危险命令 ------ 内置 Skill 带着一份危险命令黑名单（
rm -rf /、mkfs、shutdown等）要求 AI 拒绝生成，kill -9、systemctl restart这类则要求先加护栏再给。 - 有风险的建议会说清风险 ------ 这类推荐输出结构固定，结尾必须留一段「误报风险」讲清它可能判断错的情况，遇到 critical 或涉及 root、核心库还会强制降级、提示人工二次确认。
模型自己选：从公网 API 到完全离线
数据隐私是很多企业用 AI 的最大顾虑。夜莺 v9 在这点上把选择权完全交给你------底层用哪个大模型，由你决定：
| 方式 | 数据流向 | 适合谁 |
|---|---|---|
| OpenAI 公网 API | 走公网 | 标准选项，开箱即用 |
| 阿里通义 / 火山豆包 | 云内传输 | 云厂商用户 |
| 公司内部 LLM 网关 | 企业内网 | 数据隐私要求高 |
| 本地 Ollama / vLLM | 完全离线 | 最强隐私保护 |
三步就能上手
- 接模型（5 分钟） ------ 进「AI 配置 → LLM 管理」，填 API URL、API Key、模型名，点「测试连接」验证，设为默认。
- 试场景（15 分钟） ------ 在前面说的五个场景里逐一触发 AI，看看哪些最适合你的团队。
- 写第一个 Skill（10 分钟） ------ 把团队最高频的那个 SOP 数字化成 Skill，让新人立刻受益。
写在最后
监控行业聊 AIOps 已经聊了很多年，但不少产品的 AI 还停留在"做几张异常检测的图"。夜莺 v9 想往前走一步：它不替你值班，而是把过去只能靠老员工口口相传的那些经验，沉淀成一个随手能问、人人可用的副驾驶。
夜莺 v9 已经发布 beta 版本，AI 能力默认内置。详细配置见官方文档：
欢迎下载试用，把你团队的那套打法，也写进夜莺里。