結論先說：alert 寫對條件只是一半，另一半是通知真的送到對的人手上、runbook 撐得住現場、而且有人持續驗證「這條 alert 上一次真的有用嗎」。
上篇談了三件事：alert 該不該叫醒人，取決於使用者影響（症狀優先於原因）；Knight Capital、Fastly、AWS S3、Cloudflare 幾起事故分別示範了「訊號沒被設計成 alert」「找根因太慢」「動作沒驗證過」「授權與 kill switch 事先到位」這幾種斷裂與修法；以及怎麼把一條 alert 寫成有 owner、有第一步、有 runbook 的 contract，再落成 burn-rate PromQL rule。這篇接著談 rule fire 之後的事：怎麼 routing、runbook 怎麼寫才可執行、怎麼審查與測試，以及怎麼持續量化「這些 alert 到底有沒有用」。
Prometheus 判斷 alert 是否 firing。
Alertmanager 負責 grouping、routing、deduplication、silence 與 inhibition。
兩者的責任分清楚後，才不會把收件人邏輯塞進每一條 PromQL。
這是概念範本。
receiver 名稱、Slack integration 與 pager integration 都必須換成讀者自己的受管設定。
範例不含任何 webhook URL 或憑證。
route:
receiver: ai-platform-ticket
group_by:
- alertname
- service
- environment
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- matchers:
- severity="page"
- owner="ai-platform-oncall"
receiver: ai-platform-pager
group_wait: 10s
continue: false
- matchers:
- severity="ticket"
- owner="ai-platform"
receiver: ai-platform-ticket
continue: false
- matchers:
- severity="info"
receiver: ai-platform-observability
continue: false
group_by 的目的不是讓通知更短。
它是在同一波事故裡把同類訊號合成一個可處理的通知。
如果 group 得太細，三個 instance 的同一個事故會變成三個 page。
如果 group 得太粗，兩個不同使用者旅程的事故又可能被混成一張看不懂的訊息。
service 與 environment 通常是合理起點。
要不要再加 workflow_name，取決於它是否真的是獨立 owner、獨立 SLO 的旅程。
剛開始異常的幾十秒，常會有多條相同 incident 的 alert 一起抵達。
短暫 group_wait 讓 Alertmanager 有機會合併。
但它同時是偵測到通知之間的延遲。
對真正需要秒級回應的安全事件，路由會不同。
對一般 service SLO page，十到三十秒的 group_wait 是否合理，必須明寫在 alert policy 裡。
inhibition 不是拿來靜音壞消息。
它是表達「這個症狀已經有一個更適合處理的主要通知」。
以下例子在 /ask 的 fast burn 觸發時，抑制同一 service 與 environment 的 dependency ticket。
inhibit_rules:
- source_matchers:
- alertname="AskErrorBudgetFastBurn"
- severity="page"
target_matchers:
- alertname="AskProviderTimeoutContributing"
- severity="ticket"
equal:
- service
- environment
請注意 equal。
沒有它時，一個 production incident 可能把 staging 的資訊也壓掉。
而且 inhibition 不應把所有根因 evidence 消失。
它只該抑制通知。
dashboard、alert list 與 incident timeline 仍應讓 on-call 看得到 provider timeout 的訊號。
planned maintenance、已知測試或已受理的重複通知，可能需要 silence。
但每個 silence 至少要有：
scope: 哪些 label matcher
starts_at / ends_at: 明確起訖時間
owner: 誰建立
reason: 為何合理
ticket / change: 對應變更
review: 到期前誰確認是否需要延長
不要建立沒有期限的 silence。
它不是降低噪音，而是讓未來的事故沒有聲音。
也不要把 alert rule 調得更鬆來代替 maintenance silence。
前者改變了正常營運時的偵測能力。
後者只在明確範圍與時間內改變通知。
第五節提到 Cloudflare 事後承諾把規則部署改成分階段（staged rollout），這個原則其實也適用在 Alertmanager 的 routing 設定本身。routing tree 直接決定「誰會在半夜被叫醒」，一次改壞可能造成的後果，跟改壞一條 WAF 規則同一個等級——如果新 routing 不小心把 severity=page 的訊號導向一個沒有 24 小時值班的 receiver，或是 continue: false 寫錯位置導致某條規則永遠比對不到，後果是「本該響的 page 完全沒有響」，而這種失敗模式往往要等到下一次真正的事故才會被發現，那時候已經太遲。
實務上可以做的護欄包括：改動 routing 規則時，先在測試環境用第十三節的合成時間序列跑過一輪 notification drill，確認訊號真的送到預期的 receiver；重大 routing 變更（例如新增或修改 severity=page 的路徑）比照 production alert rule 一樣走 code review；也可以考慮讓 routing 變更本身觸發一則低優先度的通知，讓相關人員知道「今天有人動過分流邏輯」，而不是悄悄生效。
一則 page 不需要塞整段 PromQL。
它應該讓收件人快速完成三件事：確認影響、打開證據、找到第一步。
[page] /ask fast burn
service=policy-qa environment=production
impact=/ask 的 5m 與 1h error-budget burn 同時超過門檻
first step=開 service overview，確認 deploy annotation 與 bad outcome slice
runbook=https://…/ask-error-budget-fast-burn
dashboard=https://…/ask-overview
不要把 prompt、模型回應、使用者問題或 token 全塞進 pager。
這些資料可能敏感，也讓通知變得無法掃讀。
把安全的 link 或受權限保護的 trace search 留給後續鑽取。
runbook 的第一頁應該能讓當班的人在不熟悉服務的情況下開始。
它不需要包辦根因分析。
它要先避免錯誤的第一步。
第五節的 AWS S3 案例是這個問題最乾脆的示範：不是沒有復原程序，是那套程序隨系統規模成長，好幾年沒被完整跑過一次，第一次真正執行就是在生產事故現場，於是「重啟並驗證 metadata」這一步本身變成了拖住恢復時間的瓶頸。日常 runbook 常見的失敗模式與這個案例同一種病：dashboard 連結在重新設計時被移動、指令執行需要權限但 on-call 工程師沒有、故障排查步驟太模糊無法執行、步驟假設讀者知道隱含的 context（誰是 service owner、fallback 是否可用、何時該停止嘗試而升級）。第一次被 page 的新人，常常光靠 runbook 走不完整段診斷。改善的有效方法很直接：讓非作者的工程師按 runbook 走一遍 mock incident，記錄每個卡點，然後才修復——這比等真正事故發生時才發現 runbook 有洞，代價小得多。這說明再好的 alert 如果配不上能實際運作、且被驗證過的 runbook，也無法驅動真正的恢復。
AskErrorBudgetFastBurn runbook 範本讀者可以在自己的文件系統建立相同結構。
本文不會建立或驗證該檔案。
# AskErrorBudgetFastBurn
## 目的
處理 /ask 持續快速消耗 error budget 的症狀。
## 觸發條件
5m 與 1h error-budget burn 均高於已核准 fast-burn threshold。
## 影響確認
1. 開 Service Overview，確認 /ask completed requests 與 bad outcome ratio。
2. 切 production、/ask、受影響 workflow。
3. 記下 alert 開始時間、目前 deployment_id 與 workflow_version。
## 第一個安全動作
若 runbook 已明確授權，將流量切到已驗證的 degraded route。
若沒有已核准 route，先升級 incident，不要臨時開新 fallback。
## 排查順序
1. 確認近期 deploy、prompt、retrieval index、model-route change。
2. 看 dependency timeout 與 queue delay 是否同時上升。
3. 以 trace 抽樣確認 technical_failure、workflow_failure 或 rejected 的比例。
4. 依 evidence 選擇既定 rollback、degrade 或 provider escalation。
## 停止條件
bad outcome ratio 已回到目標範圍，且長 window 不再支持 fast burn。
## 不要做
- 不把每個 request 重送給 provider。
- 不為了降低失敗率停用 safety 或 validation。
- 不在沒有變更紀錄下修改 SLO 分母。
這個順序刻意把「使用者 impact」放在「哪個元件壞了」之前。
如果一開始就跑去看 GPU utilization，常會漏掉其實是 retriever index 剛發布、引用 validation 大量失敗。
「看 dashboard」不是步驟。
它缺少看哪一張、看到什麼算異常、之後做什麼。
把它改成下面這種形狀：
| 步驟 | 輸入 | 看到什麼 | 下一步 |
|---|---|---|---|
| 確認影響 | /ask overview |
bad outcome ratio 上升 | 建立 incident timeline |
| 切 outcome | outcome panel |
technical_failure 增加 |
看 dependency 與 deploy |
| 切延遲 | P95 breakdown | queue delay 上升 | 查 capacity / admission policy |
| 查變更 | annotation | 新 model route 同時開始 | 依 change policy rollback 評估 |
| 抽 trace | 同時窗抽樣 | parser failures 集中 | 走 workflow rollback |
runbook 的出口也很重要。
如果 evidence 顯示是 provider 區域性 outage，而 team 無法修復，出口可能是採用既定 fallback 與向 provider 升級。
如果 evidence 不足，出口可能是升級給 service owner，而不是讓 on-call 無限探索。
AI workflow 的變更不只有 container image。
prompt、retrieval corpus、tool policy、model version 都可能有不同的回退風險。
例如回退 retrieval index 也許會讓新政策文件暫時不可見。
回退 safety policy 更可能直接造成不可接受的風險。
runbook 應標記：
rollback candidate: prompt-version v12 -> v11
precondition: v11 可存取且已保留 evaluation evidence
authority: incident commander + workflow owner
expected effect: 降低 parser schema mismatch
known trade-off: 不含 v12 的新 citation formatting
這樣才叫做可行動。
「rollback to previous」只是在事故現場把決策責任丟回人身上——第五節的 Knight Capital 案例已經示範過這句話的代價：沒有預先定義的 kill switch、也沒有寫好「已知安全狀態是哪一版」，工程團隊只能臨場判斷，結果反而讓壞掉的邏輯跑到更多節點上。回滾不是天然安全的動作，沒先講清楚「回到哪個已驗證狀態」與「誰有權按下去」，回滾也可能變成放大問題的那一步。
同一節的 Cloudflare 案例則是反例：「全域終止 WAF」不是一句模糊的「rollback」，而是一個具名、事先演練過、且明確授權給 on-call 工程師可以直接執行的開關。把這個差異寫進自己的 runbook，具體做法是把每一個「緊急動作」都寫成像下面這樣，而不是一句籠統的「回滾」：
action name: disable-ask-feature-x（具名、可搜尋、可在 postmortem 中引用）
what it does: 停用 /ask 呼叫某個高風險 tool 的能力，其餘功能不受影響
authority: on-call 工程師可直接執行，無需額外核准
reversible: 是，重新啟用只需切回同一個 feature flag
known trade-off: 該 tool 對應的使用者需求暫時無法被滿足
last rehearsed: 2026-08-15（在 staging 環境模擬觸發並驗證切換）
last rehearsed 這一欄特別值得留意。一個動作如果從未被真的執行過，就算寫得再詳細，也只是「理論上安全」，跟 AWS S3 那個「好幾年沒被完整重啟過」的復原程序是同一種風險。具名、有明確授權、而且定期演練過的緊急動作，才配得上「已核准且可逆」這幾個字。
若你不知道某個 fallback 的品質、成本或資料邊界，就直接寫 UNKNOWN。
UNKNOWN: fallback model 在目前 golden dataset 的 task success 未重新評估。
Action: 僅在已核准的 availability degradation policy 下使用；事故後補回歸評估。
這比寫一句「切換備援模型」可靠得多。
它能阻止團隊把「有路可以切」誤解成「切過去一定一樣好」。
alert rule 會改變值班人的工作。
所以它應和 production code 一樣被 review。
不是因為 YAML 神祕。
而是它有真實的使用者與睡眠成本。
每次新增或修改 page rule，可以照這個順序審：
for、長短 window 與 low-traffic 行為。Prometheus 有 rule unit testing 的設定格式。
即使你現在還沒把它接進 CI，也值得先把期待行為寫成 test case。
下面是概念範例，名稱與時間序列需要依你自己的 metrics 調整。
rule_files:
- ask-alerts.yml
evaluation_interval: 30s
tests:
- interval: 30s
input_series:
- series: 'ai_requests_total{service="policy-qa",environment="production",route="/ask",workflow_name="policy_qa",outcome="success"}'
values: '0+100x240'
- series: 'ai_requests_total{service="policy-qa",environment="production",route="/ask",workflow_name="policy_qa",outcome="technical_failure"}'
values: '0+0x60 0+10x180'
alert_rule_test:
- eval_time: 2h
alertname: AskErrorBudgetFastBurn
exp_alerts:
- exp_labels:
severity: page
service: policy-qa
environment: production
這不是「貼上就必過」的測試檔。
counter 的輸入序列、rate() window、你的 SLO 和 alert for 都會影響預期時間。
它的價值在於迫使作者回答：
如果這些問題還沒答案，rule 還不應該接 pager。
第一種是正常流量。
它用來驗證 rule 不會平白 firing。
第二種是短暫尖峰。
它用來驗證 for 與多 window 沒有把一分鐘的波動誤認為 outage。
第三種是持續劣化。
它用來驗證 alert 真的會在你聲稱的反應時間內 firing。
如果服務有 fallback，還要加第四種：dependency error 上升，但 end-to-end success 維持。
這種情境的正確答案通常是：根因訊號可見，使用者症狀 page 不該響。
沒有成熟 test harness 時，不要因此跳過驗證。
找一位不參與寫 rule 的同事，給他一則 notification，請他只依 runbook 回答：
你認為哪個使用者旅程受影響？
第一個可以安全執行的動作是什麼？
哪張 dashboard 能否驗證動作有幫助？
什麼時候應該升級而不是繼續查？
如果回答只能是「我得問 rule 作者」，這條 alert 還沒有真正可操作。
rule 成立和通知抵達是兩件事。
一個完整的非 production drill 至少要觀察：
recording rule 是否產生預期 series
alert 是否經過 pending -> firing
Alertmanager 是否依 label route 到正確 receiver
同一 incident 的重複 alert 是否被正確 grouping
inhibition 是否只壓掉應壓的 cause notification
notification 是否有可點的 runbook 與 dashboard
resolved notification 是否能對應原始 incident
本文沒有建立 receiver、沒有發送 page，也沒有執行任何 drill。
讀者應在隔離環境或由組織核准的測試管道進行。
假設 policy Q&A service 在 10:02 開始劣化。
10:00 剛發布新的 retrieval index。
10:01 provider timeout 有輕微升高。
10:02 /ask 的 workflow_failure 開始增加。
10:05 5m error-budget burn 超過 threshold。
10:07 1h window 也符合條件，加上 for: 2m 後，AskErrorBudgetFastBurn 進入 firing。
這不是根因的證明。
它只告訴值班人員：使用者旅程已經有足夠持續的傷害。
on-call 開啟 Service Overview。
先看 /ask completed requests 是否正常。
若 completed requests 本身掉到接近零，要避免把分母太小造成的 ratio 當成完整故事。
再看 outcome slice。
此例顯示 workflow_failure 上升，而 technical_failure 沒有明顯改變。
這就比「provider timeout 有一點高」更接近使用者症狀。
記錄：
10:00 retrieval index change: handbook-2026-09-25
10:01 provider timeout slight increase
10:02 workflow_failure begins rising
10:07 fast-burn page fires
不要在這一步就宣告 index 是根因。
時間相鄰值得查。
它不等於因果。
從 trace 或 workflow dashboard 抽取同一時窗的失敗樣本。
如果大部分失敗集中在 citation validator，且 validator 讀到的 document identifier 是舊格式，這比 provider timeout 更有解釋力。
此時 evidence 可能指向 retrieval index 的 schema 相容性問題。
注意，完整 trace 可以包含敏感使用者內容。
runbook 應要求在受授權系統中查看，通知裡只保留安全的 trace link 或 filter。
如果 retrieval index 回退已被定義、權限也正確，incident commander 可以依流程回退到前一版。
如果沒有這種授權，就不應該由 on-call 在壓力下臨時執行資料回退。
可選的暫時動作也許是降低高風險 workflow 的流量，或改為明確回覆「目前無法確認來源」。
這會降低功能完整性。
卻可能比繼續提供錯誤引用更符合服務的安全與品質承諾。
動作完成後，先看 bad outcome ratio 是否下降。
再看 quality review queue 是否出現新的偏差。
最後確認長 window 是否逐步回到正常。
alert resolved 只表示它的 expression 不再成立。
不等於根因已永久消失，也不等於所有使用者已補救。
事故後應補：
這才讓 alert 隨著系統演進，而不是每次事故後只多一條規則。
alert 的品質也要有 SLI。
Etsy 的方法很直接：請真正收到通知的人分類。
你不需要照抄它的工具或表單。
先用一個小表格就能開始。
| 欄位 | 例子 | 為什麼需要 |
|---|---|---|
| alertname | AskErrorBudgetFastBurn |
找到要改善的 rule |
| fired_at | 2026-09-25T10:07:00Z | 對應事件時間線 |
| classification | actionable / non-actionable / duplicate / unknown | 不把所有未處理都叫 false positive |
| user_impact | yes / no / unknown | 回到 service outcome |
| action_taken | degraded route / rollback / none | 驗證能否行動 |
| first_action_minutes | 7 | 看 runbook 是否縮短時間 |
| resolution | resolved / escalated / follow-up | 保留結果 |
| notes | missing dashboard link | 產生具體改進 |
一則通知可能沒有立刻行動，但仍然有價值。
例如它讓團隊提前發現某個趨勢，並在工作時間開 ticket。
這比較適合的結論通常是「routing 太吵」或「severity 太高」。
false positive 則應保留給「rule 的主張本身不成立」。
分類越精準，改善也越不會只剩下把 threshold 往上調。
page volume
actionable ratio
median time to first useful action
duplicate notification ratio
page volume 低不一定好。
你可能只是把真正的事故靜音了。
actionable ratio 高也不必然代表健康。
如果所有 page 都是因為範圍太大才終於響，仍可能太慢。
把這些數字和 error-budget 事件、incident 數量一起看，才有脈絡。
每週：分類上一週通知，修正明顯重複 routing
每月：看每條 page rule 的 actionable evidence 與 owner
每季：重審 SLO、burn threshold、runbook 與 escalation authority
每次重大 incident 後：檢查 alert 是否早、是否準、是否有用
不是每週都要重寫所有規則。
但 alert 無人負責 review，最後一定會變成沒人敢動的遺產。
如果只有收到 page 的人填分類，分母就是「有回填的 page」，不是所有通知。
如果某個 team 在夜間沒回填，不能把缺值算成 actionable。
可以直接把 dashboard 標成：
Actionable ratio（以有分類的 page 為分母；目前回填覆蓋率 78%）
這種揭露看起來不華麗。
卻能避免每月報表把不完整資料講成服務 SLA。
這一節是讀者自行操作的路徑。
不需要先真的接 pager。
先在隔離或經核准的測試環境做 rule 與通知內容審查。
本文沒有新增 DIY 專案、安裝依賴、啟動 Prometheus、發送 page 或執行 rule test。
開始前，請先確認：
/ask 的 completed、good 與 bad outcome 如何定義。沒有這些條件時，可以先完成 contract 與桌上推演。
不要在不清楚通知接收者的情況下把 rule 載入 production。
建立一份表，先不要急著寫 YAML。
signal 1: /ask bad outcome ratio
candidate destination: page
why: 直接對應使用者任務是否完成
signal 2: LLM provider timeout ratio
candidate destination: ticket / diagnostic
why: 需和 end-to-end outcome 一起看
signal 3: sampled groundedness failure
candidate destination: review queue
why: 抽樣與 evaluator 誤判都需要人讀 context
預期觀測是：三個訊號不會因為都「看起來糟」就被塞進同一個 pager。
把第八節的欄位填進你自己的文件。
至少填：
alert name
user journey
SLI numerator / denominator
SLO and window
owner
first safe action
do-not-do list
dashboard link
runbook link
known limitations
預期觀測是：另一位工程師只讀這張 contract，就能說出為何它值得 page。
若不能，先修 contract，不要繼續寫 PromQL。
將第十節的範例改成你的 metric 名稱。
確認：
sum by 保留 service 與 environment
outcome=success 的語意符合 SLI
分母是 completed requests，不是 received requests 的混雜集合
zero traffic 的處理已被說明
版本、request_id、prompt 沒有進 label
預期觀測是：同一個 SLI 被 dashboard 和 alert 共用，而不是各自重算。
for選擇你的短 window、長 window 與持續時間。
每一個數值旁邊寫理由。
5m: 要及時看到快速惡化
1h: 要排除短暫尖峰
for 2m: 避免一個 evaluation cycle 就 firing
如果你無法說明為什麼是 2m 而不是 10m，先標為待驗證。
門檻不是靠「業界都這樣」就能成立。
把 pager 訊息限制在能做判斷的資訊。
使用者影響一句話
service / environment
第一個安全動作
runbook link
dashboard link
預期觀測是：通知本身沒有敏感 payload，也不需要捲動十頁才能找到第一步。
依第十一節建立概念 routing tree。
再以紙上或測試環境檢查：
AskErrorBudgetFastBurn -> pager
AskProviderTimeoutContributing -> ticket
AskErrorBudgetFastBurn firing 時 -> 同 service/environment 的 provider ticket 被抑制通知
staging 的 alert -> 不被 production source alert 抑制
預期觀測是：一個 incident 的 notification 數量下降，但證據訊號仍可在 dashboard 上看到。
不用先跑任何 command。
先在文件裡手算三種情境：
| 情境 | 5m 壞比例 | 1h 壞比例 | 預期 |
|---|---|---|---|
| 正常 | 0.1% | 0.1% | 不 pending |
| 30 秒尖峰 | 10% | 接近基線 | 不 firing |
| 持續故障 | 10% | 8% | 在 for 後 firing |
接著再加上 provider timeout 上升但 fallback 成功的情境。
預期是 dependency signal 可見，AskErrorBudgetFastBurn 不 firing。
把一則匿名化的 page notification 和 runbook 交給另一位工程師。
請他口頭走一遍前十分鐘。
記錄他卡住的地方。
常見卡點包括：
outcome label 的定義。這些卡點是 runbook 的待辦事項，不是讀者不夠熟悉的證明。
可以用這份清單交付 review：
[ ] page signal 對應使用者 SLI，而不是單一元件指標
[ ] 分子、分母、SLO、window 都被寫出
[ ] recording rule 的 labels 已被審查
[ ] page annotation 包含 impact、first action、runbook、dashboard
[ ] ticket 與 dashboard signal 沒有誤送 pager
[ ] inhibition 有 service 與 environment equality boundary
[ ] silence policy 有 owner、期限與變更關聯
[ ] 至少推演正常、尖峰、持續故障與 fallback 成功四種情境
[ ] 非作者可用 runbook 說出第一步與升級條件
[ ] 未驗證的閾值、fallback 或權限被如實標示 UNKNOWN
這份清單全部勾上，表示設計已可以進入受控測試。
它不表示 production rule 已驗證。
兩者必須分開說。
- alert: AIIsBad
expr: ai_requests_total{outcome!="success"} > 10
這條 rule 至少有三個問題。
counter 會累積，因此幾乎終究會大於十。
它沒有分母，十筆失敗在十筆流量與一百萬筆流量的意義完全不同。
它也沒有使用者影響與 owner。
修正不是把十改成一百。
修正是先回到 good / total 與 SLO。
provider 的失敗很值得量。
但若 fallback 已成功、使用者看到的結果正常，直接 page 可能只是叫人起床看一個已被服務處理掉的局部錯誤。
保留 dependency ratio。
再用 end-to-end SLI 決定 notification 強度。
值班者會看到很多 Grafana dashboard。
也許還有不同環境、不同 datasource、不同時間範圍。
runbook 至少要說：先開哪一張、帶什麼 filters、要確認哪一個 outcome slice。
silence 可以降低 planned maintenance 的噪音。
inhibition 可以降低同一事故的重複通知。
兩者都沒有讓服務變好。
如果 outage 正在發生，silence 不是緩解措施。
平均數會掩蓋少數使用者正在等待很久。
Day 16 已說過為何要看分位數。
在 alert 也一樣。
用端到端 P95 或已定義的 latency SLI，並保留 breakdown 做排查。
quality evaluator 有抽樣率、延遲與 false positive。
它的結果應先進 review、dataset 與 release decision。
只有當你能證明品質劣化正在系統性地傷害既定使用者 SLI，而且有可安全執行的行動時，才考慮升級。
owner=ai-platform-oncall 不等於他有權回退 prompt 或 index。
runbook 要把「誰可做」和「誰需核准」分開。
否則 alert 只是在事故現場暴露組織責任邊界。
YAML 經過 review、能被載入、測試有通過，仍不代表真正 receiver 能收到通知。
production routing、權限、值班表與 notification template 都是另一層驗證。
請在紀錄中分別標記：
static review: completed
rule test: completed / not run
notification drill: completed / not run
production enablement: completed / not enabled
誠實的狀態比一個模糊的「done」有用。
好的 alert 不是監控系統最先看到異常時發出的聲音。
它是使用者影響已經足以需要人接手，而且接手者已經有安全下一步時，才發出的聲音。
這也是為什麼同一份 telemetry 會同時進 dashboard、trace、ticket、review queue 與 pager。
資料沒有高低貴賤。
差別在於它現在需要什麼回應節奏。
Day 24 給了我們鑽取順序。
Day 25 把這個順序接成通知與行動。
Day 26 會再處理 AI 特有品質與安全訊號：它們何時應該是 alert，何時更適合 evaluation、人工審查或 release gate。
下一篇會接著處理「AI Alerting」。
這篇是 Learning SRE for the AI Era 系列的一部分。
Build → Trace → Break → Measure → Evaluate → Recover → Improve.
iThome鐵人賽
看影片追技術