- 快猫星云Flashcat

夜鶯 v9 給維運團隊請了一位「不下班、不離職、記得每條規則」的資深 SRE 副駕駛。本文從 6 個真實維運場景出發：On-call 判真假、故障定位、新業務上線、日常維運、新人培訓、告警自癒，講清楚夜鶯 AI 能在你的工作流哪一步介入、解決哪類問題。

一句話理解夜鶯 AI

夜鶯 v9 給你團隊請了一位 7x24 在線的資深 SRE 副駕駛。

他不下班、不離職、記得你這套夜鶯裡每一條告警規則、每一台機器、每一份歷史告警；他知道公司用什麼資料來源、哪些指標常用、通知範本怎麼拼；最重要的是——他能把你團隊裡那位最資深 SRE 的經驗和方法論學進去，下一次新人接手時，按「老司機」的思路引導他幹活。

這位副駕駛會在下面 6 個最常見的維運場景裡出現。

場景一：On-call 半夜被叫醒，第一時間判真假

你今天的處理方式

凌晨 3 點，一條「server-01 失聯」告警炸了手機。打開夜鶯一看：

target_up == 0，心跳顯示 2 分鐘沒上來；
但 ping server-01 又能通；
agent 卡死？網路抖動？還是真宕？

抓 SSH、看程序、看 dmesg、看交換機日誌……折騰 20 分鐘才敢下結論。如果直接打電話喊維運去機房，事後發現是誤報，那是更尷尬。

用夜鶯 AI 的樣子

在通知卡片或告警事件詳情頁裡直接打開 Copilot，問一句：

「這條告警是真的嗎？要不要立刻處置？」

夜鶯 AI 同時拉四層證據給你結論：

心跳層——Redis 裡上一次 BeatTime、lag_seconds、最後一次上報的 CPU/記憶體值；
指標層——最近 10 分鐘 cpu_usage_active / mem_available_percent / system_load1 / 網路位元組數的最後值與視窗內的趨勢；
鄰居層——同業務組裡其它機器現在是不是也異常（個體故障 vs 叢集故障 vs 網路分區）；
遮蔽層——這台機器現在是不是正好在維護視窗裡。

輸出一個明確結論：「真宕機 / agent 假死 / 網路抖動 / 維護中」，附關鍵證據 + 建議動作 + 可能站不住腳的反例（避免誤報）。

節省什麼

半夜誤打車去機房的機率 → 大幅下降；
單次失聯判斷從 20 分鐘 → 30 秒；
新人值班也能下出資深 SRE 水準的判斷。

「agent 失聯 ≠ 主機宕機」——這是社群裡被反覆證明的高頻誤報根源。AI 把多層證據綜合起來判斷，正是為了把這個誤報率打下來。

場景二：故障定位，從一團亂麻裡找根因

你今天的處理方式

業務報障：「訂單介面慢了」。你打開夜鶯：

看哪幾條告警在響；
切到儀表板看 P99 趨勢；
翻資料庫慢查詢日誌；
切回告警看是不是有相關基礎設施告警；
找歷史上類似時間點……

經驗豐富的同學 15 分鐘出結論，新接手的同學可能 1 小時定不到位。

用夜鶯 AI 的樣子

「剛才訂單業務報障，幫我看看是不是這條 MySQL 主從延遲告警導致的」

AI 自動跑一遍資深 SRE 的標準動作：

跑 PromQL 拉延遲告警涉及的指標歷史趨勢；
讀這條告警規則的定義（PromQL、閾值、持續時間）；
查同業務組在同一時間視窗有沒有其它告警一起響（資料來源端、網路端、應用端）；
查這台主機最近的 CPU / IO / 網路指標有沒有異常；
給出「時間線 + 關鍵證據 + 大機率原因 + 緩解建議」。

節省什麼

一次綜合排障從 30 分鐘 → 1 分鐘拿到證據鏈（最終還是你做決定，但證據已經擺好）；
跨資料來源 / 跨規則的查詢不用再手動來回切；
新人也能拿到資深 SRE 視角的證據組合。

AI 的故障定位不替你下結論，而是把證據鏈整理好擺給你看。最後那一下「是不是這個原因、要不要採取這個動作」，還是人來判斷。

場景三：新業務上線，5 分鐘搭起監控體系

你今天的處理方式

訂單服務要上線生產。SRE 標準動作：

建 4 條告警規則（CPU、記憶體、磁碟、請求成功率）；
配通知規則（白天發釘釘、夜裡加電話）；
建一個監控儀表板；
配幾個遮蔽規則給變更視窗用；
加自癒指令稿（磁碟滿清理）。

人工填表，1-2 小時。如果遇到 PromQL 閾值反覆調，可能半天。

用夜鶯 AI 的樣子

打開 Nightingale AI，用大白話一句話提需求：

「給所有生產環境（label env=prod）的主機加一條 CPU 使用率 > 90% 持續 5 分鐘的二級告警，工作時間發釘釘，非工作時間打電話」

AI 做：

自動選業務組（如果你在某業務組頁面打開，直接用目前）；
自動找 cpu_usage_active 指標 + env=prod 標籤篩選；
拼出 PromQL；
配閾值 90、持續時間 5m、級別 P2；
選好對應的通知規則；
直接幫你建立這條告警規則。

類似一句話能搞定的還有：儀表板、遮蔽規則、訂閱規則、通知規則、通知範本、自癒指令稿。

節省什麼

上線監控設定從 1-2 小時 → 5 分鐘；
PromQL 寫不出來不再阻塞——AI 知道你庫裡有哪些指標，自動選；
新人也能上手做監控設定。

場景四：日常維運，把零碎活兒變成對話

你今天的處理方式

維運一天會被無數零碎請求打斷：

「釘釘告警範本幫我加上主機名稱」——查欄位表 + 調樣式，10 分鐘；
「把 web01 這台機器的告警遮蔽 2 小時」——點 7 步表單，3 分鐘；
「怎麼接入 Slack 通知」——翻文件、試錯，半小時；
「為啥釘釘告警發不出去報 9499 錯」——抓包、查文件，1 小時。

用夜鶯 AI 的樣子

你想做的事	你說什麼	AI 做什麼
改通知範本	「釘釘範本加上主機名稱、觸發值，按級別分顏色」	用 Go template 語法直出可貼上片段，自動處理告警/恢復兩種事件分支
加臨時遮蔽	「遮蔽 host=web01 的所有告警 2 小時」	解析標籤 + 時間視窗 + 業務組，直接建立遮蔽規則
接入新通知平台	「怎麼接入 Slack」	給完整的 Webhook URL + 請求體 + Headers + 欄位級踩坑預警
排查發送失敗	「釘釘發不出去報 9499」	解釋錯誤碼 + 5 層 checklist（URL/簽名/Headers/網路/限頻）+ curl 驗證命令
查告警事件	「最近 1 小時有哪些一級告警」	拉介面 → Markdown 表格彙總
查資源列表	「我有哪些業務組」 / 「查看告警規則列表」	直接給列表

節省什麼

這類小動作每天 5-10 個，單個從 3-30 分鐘 → 30 秒；
不再需要隨時拉資深同學回答「這個怎麼配」。

場景五：新人接手，三天能獨立 On-call

你今天的處理方式

資深 SRE 離職 / 新人加入，痛苦的事情來了：

團隊 SOP 寫在 Confluence / 飛書文件裡，沒人維護、新人看不懂哪條還有效；
資深同學的「經驗」——比如「看到 MySQL 主從延遲告警先看 pt-heartbeat、再看複製執行緒、最後才看 binlog 大小」——只在他腦子裡；
新人值班遇到陌生場景，要麼打電話叫人，要麼硬扛，故障 MTTR 上升。

用夜鶯 AI 的樣子

夜鶯 v9 提供一個叫 Skill 的機制，本質是「團隊 SOP 的數位化沉澱」：

資深 SRE 把自己的排障方法論用 Markdown 寫一份 Skill，描述清楚「什麼場景下、按什麼方法、輸出什麼」；
上傳到夜鶯；
AI 在遇到匹配場景時自動載入這份 Skill，按你寫的方法論回答。

舉一個真實的例子：

資深 DBA 把「MySQL 慢查詢排障四步法（看慢日誌 Top 10 → 看池子命中率 → 看鎖 → 才 EXPLAIN）」寫成一個 Skill 上傳。

新人值班時收到 MySQL 延遲告警，問 AI 「這條告警怎麼處理」，AI 不是泛泛回答「用 EXPLAIN 看看」，而是按 DBA 寫的四步法引導新人一步步走——先拉慢日誌、再看池子、再看鎖，最後才讓他 EXPLAIN。

夜鶯 v9 還內建了 19 個開箱即用的 Skill，覆蓋告警建立/排障、主機診斷、通知設定、PromQL/SQL 產生、半自癒推薦——裝好就能用。

詳見：

Skill 撰寫教學——端到端教你寫第一個團隊 Skill
內建 Skill 一覽——19 個內建 Skill 分別能做什麼

節省什麼

新人獨立 On-call 週期從 2-4 週 → 3-7 天；
資深 SRE 離職帶走的經驗，這次留下來了；
團隊 SOP 第一次有了「會被真的執行」的載體。

這一點是夜鶯 AI 給團隊帶來的最大價值——不是會寫 PromQL，而是讓經驗可沉澱、可複用、可傳承。

場景六：告警自癒，讓「機械告警」不再打擾人

你今天的處理方式

有些告警每週都來一次，處理動作是固定的：

「磁碟滿」——清理 /var/log 下 7 天以上的舊日誌；
「服務掛了」——重啟對應程序；
「Nginx 設定變更後沒生效」——nginx -s reload。

每次都做同樣的事，但又不敢全自動——萬一指令稿寫錯把生產搞掛，誰負責？

用夜鶯 AI 的樣子

夜鶯 v9 提供「半自癒」能力：AI 推薦 → 人確認 → 系統執行。

在告警事件詳情頁或通知卡片裡打開 Copilot，問一句：

「這條告警能自癒嗎？幫我處理一下」

AI 做：

拉目前事件 + 告警規則 + 近 30 天歷史三層證據；
在你已有的自癒指令稿庫裡搜尋匹配候選；
對每個候選做安全評估：
- 意圖匹配嗎？
- 業務組邊界對不對？
- 標籤夠指令稿用嗎？
- 有沒有觸發危險命令（rm -rf / 這類）？
- 目標主機現在線上嗎？
通過評估的候選——給你一個 「✅ 一鍵執行」按鈕，附指令稿預覽 + 風險提示 + 誤報風險。

最後那一下確認必須人來點。AI 永遠不自己跑命令。

如果你的自癒指令稿庫裡沒有匹配，AI 會切換到「自癒指令稿產生 Copilot」，幫你按需求草擬一份新指令稿（帶 stdin 解析、timeout 建議、危險命令護欄、風險與回滾說明），讓你審核入庫。

節省什麼

90% 的「機械告警」——AI 推薦 + 人點確認就閉環；
「怕指令稿寫錯搞掛生產」的顧慮——AI 在產生/推薦時自動過危險命令黑名單 + dry-run 建議；
資深 SRE 不用再被每週一次的磁碟滿告警打斷。

這些場景從哪裡觸發

入口非常簡單：

┌──────────────────────────────────────────────────────────────┐
│  右上角 [Nightingale AI] 圖示 —— 全站對話入口                  │
│      任何頁面打開，問任何場景的問題，AI 自動選場景             │
├──────────────────────────────────────────────────────────────┤
│  告警事件詳情頁 —— "能自癒嗎" / "為什麼觸發" / "是誤報嗎"      │
│  通知範本編輯器  —— 「AI 產生」按鈕，自然語言產生範本          │
│  PromQL 輸入框   —— 告警/儀表板裡的 PromQL 旁，AI 產生查詢     │
│  SQL / 日誌查詢  —— SQL / LogQL / ES DSL 輸入框旁，AI 產生查詢 │
│  自癒指令稿編輯器  —— 「AI 產生指令稿」按鈕，自然語言產生自癒指令稿   │
└──────────────────────────────────────────────────────────────┘

入口雖然多，設定只配一次：在 AI 設定 → LLM 管理 接入一個大模型，全平台 AI 都用同一套設定。

AI 不會做什麼——它的邊界

作為維運負責人，你最關心的可能不是「它能做多少」，而是「它會不會越界」。夜鶯 AI 在設計上守了這幾條底線：

邊界	說明
不自己跑命令	所有「執行」類動作——執行自癒指令稿、對生產環境做變更——最後一下確認必須人來點。AI 只推薦，不動手。
不越權讀資料	AI 跑在目前登入使用者的權限上下文裡。你這個帳號看不到的業務組、改不了的資源，AI 也存取不到。
不偷傳資料	夜鶯 server 不會把你的告警/指標/機器列表回傳到任何「夜鶯官方服務」，沒有所謂的中央 AI 服務。
不輸出危險命令	寫自癒指令稿時拒絕輸出 `rm -rf /` / `mkfs` / `shutdown` / `iptables -F` 等危險操作，會改寫成安全變體（dry-run / 限定範圍）。
不替你扛鍋	AI 給的根因分析、自癒推薦都附帶一段「誤報風險」說明——告訴你「這個結論可能在什麼情況下不準」。最後判斷和簽字是你的。

資料完全可控

很多維運 leader 看到「AI」第一反應是：「我的告警資料會不會被傳到 OpenAI？」

夜鶯 AI 在這點上的設計是：大模型在哪由你決定，夜鶯不綁定任何特定供應商。

部署方式	資料流向
接 OpenAI 公網 API	資料走公網 → OpenAI
接阿里通義 / 火山豆包	資料在阿里雲 / 火山雲內
接公司內部 LLM 閘道	資料不出公司
接本機 Ollama / vLLM 跑開源模型	資料完全不出域，完全離線

對資料出域有硬性要求？用 Ollama 跑 DeepSeek / Qwen / Llama 就行——一台 GPU 伺服器就能起，對一線 SRE 場景的效果完全夠用。

詳見 LLM 管理裡支援的提供商清單。

30 分鐘上手

接入 LLM（5 分鐘）——去 LLM 管理新建一條 LLM 設定：填 API URL / API Key / 模型名 → 點「測試連線」→ 看到「連線成功」再儲存 → 把它設為預設。
跑一遍 6 個場景（15 分鐘）——找最近一條告警，按上面 6 個場景每一個都用一次：
- 進事件詳情頁問「這條告警是真的嗎 / 能自癒嗎」；
- 全域對話框問「最近 1 小時有哪些一級告警」；
- 任意 PromQL 輸入框旁點 AI 按鈕，讓它幫你寫一條查詢；
- 通知範本編輯器點「AI 產生」試試效果；
- ……
感受一遍後，你會知道在你團隊裡哪幾個場景最適合先推廣。
寫第一個團隊 Skill（10 分鐘）——把團隊裡最高頻的一份「故障處理 SOP」寫成 Skill 上傳，讓團隊的新人也能受益。具體怎麼寫參考 Skill 撰寫教學。

關聯文件

LLM 管理——接入大模型的詳細操作
Skill 管理——什麼是 Skill，怎麼管理
Skill 撰寫教學——從零寫一個團隊 Skill
內建 Skill 一覽——19 個開箱即用 Skill 的能力清單
通知訊息範本 → AI 產生範本