<?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/%E4%BA%8B%E6%95%85%E5%BE%8C%E6%AA%A2%E8%A8%8E/</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/%E4%BA%8B%E6%95%85%E5%BE%8C%E6%AA%A2%E8%A8%8E/index.xml" rel="self" type="application/rss+xml"/><item><title>Post-Incident Review</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/post-incident-review/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/post-incident-review/</guid><description>&lt;p>Post-incident review 的核心概念是「事故後把事實、原因與改進行動整理成可驗證輸出」。它的目標是提升系統與流程，不是追究個人。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-timeline/" data-link-title="Incident Timeline" data-link-desc="說明事故時間線如何支援判斷、溝通與復盤">Incident Timeline&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>復盤連接 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-timeline/" data-link-title="Incident Timeline" data-link-desc="說明事故時間線如何支援判斷、溝通與復盤">incident timeline&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rca/" data-link-title="RCA" data-link-desc="說明根因分析如何區分觸發事件、系統弱點與防線缺口">rca&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;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要復盤流程的訊號是同類事故反覆發生。若每次都只做當下修補，沒有形成結構化改進，事故頻率通常不會下降。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>復盤要包含影響摘要、時間線、根因、有效措施、無效措施、行動項與驗證期限。行動項需要指定 owner 與完成標準，避免停在會議紀錄。&lt;/p></description><content:encoded><![CDATA[<p>Post-incident review 的核心概念是「事故後把事實、原因與改進行動整理成可驗證輸出」。它的目標是提升系統與流程，不是追究個人。 可先對照 <a href="/blog/backend/knowledge-cards/incident-timeline/" data-link-title="Incident Timeline" data-link-desc="說明事故時間線如何支援判斷、溝通與復盤">Incident Timeline</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>復盤連接 <a href="/blog/backend/knowledge-cards/incident-timeline/" data-link-title="Incident Timeline" data-link-desc="說明事故時間線如何支援判斷、溝通與復盤">incident timeline</a>、<a href="/blog/backend/knowledge-cards/rca/" data-link-title="RCA" data-link-desc="說明根因分析如何區分觸發事件、系統弱點與防線缺口">rca</a> 與 <a href="/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a> 更新。它也是可靠性改進與工程優先序調整的輸入來源。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要復盤流程的訊號是同類事故反覆發生。若每次都只做當下修補，沒有形成結構化改進，事故頻率通常不會下降。</p>
<h2 id="設計責任">設計責任</h2>
<p>復盤要包含影響摘要、時間線、根因、有效措施、無效措施、行動項與驗證期限。行動項需要指定 owner 與完成標準，避免停在會議紀錄。</p>
]]></content:encoded></item></channel></rss>