<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>告警處置手冊 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E5%91%8A%E8%AD%A6%E8%99%95%E7%BD%AE%E6%89%8B%E5%86%8A/</link><description>Recent content in 告警處置手冊 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 23 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E5%91%8A%E8%AD%A6%E8%99%95%E7%BD%AE%E6%89%8B%E5%86%8A/index.xml" rel="self" type="application/rss+xml"/><item><title>Alert Runbook</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/alert-runbook/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/alert-runbook/</guid><description>&lt;p>Alert runbook 的核心概念是「每個需要人處理的 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/alert/" data-link-title="Alert" data-link-desc="說明 alert 如何把需要處理的服務症狀轉成可行動通知">alert&lt;/a> 都要附上下一步」。Alert 通知異常，runbook 則說明如何判斷影響、查哪些 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/dashboard/" data-link-title="Dashboard" data-link-desc="說明 dashboard 如何把關鍵訊號組成可判讀的服務狀態畫面">dashboard&lt;/a>、執行哪些修復、何時升級。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Alert runbook 是可觀測性與操作流程的交界。告警搭配 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook&lt;/a> 後，事故處理可以從個人經驗轉成團隊流程。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要 alert runbook 的訊號是 on-call 收到告警後仍要臨場猜原因。&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/consumer-lag/" data-link-title="Consumer Lag" data-link-desc="說明 consumer lag 如何反映訊息堆積、處理能力與容量風險">Consumer lag&lt;/a> 告警應連到 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/queue-depth/" data-link-title="Queue Depth" data-link-desc="說明 queue 中等待處理的訊息數如何反映 backlog 與容量壓力">queue depth&lt;/a>、error rate、下游 latency、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/dead-letter-queue/" data-link-title="Dead-Letter Queue" data-link-desc="說明 dead-letter queue 如何隔離多次處理失敗的訊息">dead-letter queue&lt;/a> 數量與擴容或暫停流程。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Runbook 要包含影響判斷、查詢連結、原因分類、立即緩解、回復驗證與升級路徑。每次事故後應更新 runbook，讓下一次處理更可重現。&lt;/p></description><content:encoded><![CDATA[<p>Alert runbook 的核心概念是「每個需要人處理的 <a href="/blog/backend/knowledge-cards/alert/" data-link-title="Alert" data-link-desc="說明 alert 如何把需要處理的服務症狀轉成可行動通知">alert</a> 都要附上下一步」。Alert 通知異常，runbook 則說明如何判斷影響、查哪些 <a href="/blog/backend/knowledge-cards/dashboard/" data-link-title="Dashboard" data-link-desc="說明 dashboard 如何把關鍵訊號組成可判讀的服務狀態畫面">dashboard</a>、執行哪些修復、何時升級。</p>
<h2 id="概念位置">概念位置</h2>
<p>Alert runbook 是可觀測性與操作流程的交界。告警搭配 <a href="/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a> 後，事故處理可以從個人經驗轉成團隊流程。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要 alert runbook 的訊號是 on-call 收到告警後仍要臨場猜原因。<a href="/blog/backend/knowledge-cards/consumer-lag/" data-link-title="Consumer Lag" data-link-desc="說明 consumer lag 如何反映訊息堆積、處理能力與容量風險">Consumer lag</a> 告警應連到 <a href="/blog/backend/knowledge-cards/queue-depth/" data-link-title="Queue Depth" data-link-desc="說明 queue 中等待處理的訊息數如何反映 backlog 與容量壓力">queue depth</a>、error rate、下游 latency、<a href="/blog/backend/knowledge-cards/dead-letter-queue/" data-link-title="Dead-Letter Queue" data-link-desc="說明 dead-letter queue 如何隔離多次處理失敗的訊息">dead-letter queue</a> 數量與擴容或暫停流程。</p>
<h2 id="設計責任">設計責任</h2>
<p>Runbook 要包含影響判斷、查詢連結、原因分類、立即緩解、回復驗證與升級路徑。每次事故後應更新 runbook，讓下一次處理更可重現。</p>
]]></content:encoded></item></channel></rss>