<?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>Incident Severity on Tarragon</title><link>https://tarrragon.github.io/blog/tags/incident-severity/</link><description>Recent content in Incident Severity 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/incident-severity/index.xml" rel="self" type="application/rss+xml"/><item><title>Incident Severity</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/incident-severity/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/incident-severity/</guid><description>&lt;p>Incident severity 的核心概念是「用一致標準把事故影響分級」。分級描述的是產品影響範圍、持續時間、資料風險與回復緊急程度，技術細節放在其他層處理。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/alert/" data-link-title="Alert" data-link-desc="說明 alert 如何把需要處理的服務症狀轉成可行動通知">Alert&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Incident severity 連接 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/alert/" data-link-title="Alert" data-link-desc="說明 alert 如何把需要處理的服務症狀轉成可行動通知">alert&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/escalation-policy/" data-link-title="Escalation Policy" data-link-desc="說明事故升級鏈與值班轉接規則">escalation policy&lt;/a>。同一類技術錯誤在不同業務場景可能有不同等級，因此分級要以產品後果為主。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要分級模型的訊號是事件發生後團隊對嚴重度判斷不一致。付款成功率下降與單一內部報表延遲都可能由 timeout 引起，但前者需要立即啟動高優先級處置，後者通常走一般排程修復。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>分級要定義等級條件、升級門檻、負責角色、通訊頻率與回顧要求。等級規則應定期和事故紀錄對照，避免長期失真。&lt;/p></description><content:encoded><![CDATA[<p>Incident severity 的核心概念是「用一致標準把事故影響分級」。分級描述的是產品影響範圍、持續時間、資料風險與回復緊急程度，技術細節放在其他層處理。 可先對照 <a href="/blog/backend/knowledge-cards/alert/" data-link-title="Alert" data-link-desc="說明 alert 如何把需要處理的服務症狀轉成可行動通知">Alert</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Incident severity 連接 <a href="/blog/backend/knowledge-cards/alert/" data-link-title="Alert" data-link-desc="說明 alert 如何把需要處理的服務症狀轉成可行動通知">alert</a>、<a href="/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a> 與 <a href="/blog/backend/knowledge-cards/escalation-policy/" data-link-title="Escalation Policy" data-link-desc="說明事故升級鏈與值班轉接規則">escalation policy</a>。同一類技術錯誤在不同業務場景可能有不同等級，因此分級要以產品後果為主。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要分級模型的訊號是事件發生後團隊對嚴重度判斷不一致。付款成功率下降與單一內部報表延遲都可能由 timeout 引起，但前者需要立即啟動高優先級處置，後者通常走一般排程修復。</p>
<h2 id="設計責任">設計責任</h2>
<p>分級要定義等級條件、升級門檻、負責角色、通訊頻率與回顧要求。等級規則應定期和事故紀錄對照，避免長期失真。</p>
]]></content:encoded></item></channel></rss>