<?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%B9%B3%E5%9D%87%E4%BF%AE%E5%BE%A9%E6%99%82%E9%96%93/</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%B9%B3%E5%9D%87%E4%BF%AE%E5%BE%A9%E6%99%82%E9%96%93/index.xml" rel="self" type="application/rss+xml"/><item><title>MTTR</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/mttr/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/mttr/</guid><description>&lt;p>MTTR 的核心概念是「從事故開始到恢復的平均時間」。它幫助團隊追蹤處置效率趨勢，但不能單獨代表可靠性品質。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">Incident Severity&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>MTTR 連接 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">incident severity&lt;/a>、&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/post-incident-review/" data-link-title="Post-Incident Review" data-link-desc="說明事故後如何完成復盤、學習與改進閉環">post-incident-review&lt;/a>。不同等級事故應分開計算，避免指標失真。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要 MTTR 的訊號是團隊想驗證事故流程是否改進。若新增 runbook 與升級策略後 MTTR 持續下降，表示流程變更有實際效果。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>MTTR 指標要搭配樣本數、嚴重度分層與影響範圍一起解讀。它應導向流程改善與演練設計，而不是單純追求數字下降。&lt;/p></description><content:encoded><![CDATA[<p>MTTR 的核心概念是「從事故開始到恢復的平均時間」。它幫助團隊追蹤處置效率趨勢，但不能單獨代表可靠性品質。 可先對照 <a href="/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">Incident Severity</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>MTTR 連接 <a href="/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">incident severity</a>、<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/post-incident-review/" data-link-title="Post-Incident Review" data-link-desc="說明事故後如何完成復盤、學習與改進閉環">post-incident-review</a>。不同等級事故應分開計算，避免指標失真。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要 MTTR 的訊號是團隊想驗證事故流程是否改進。若新增 runbook 與升級策略後 MTTR 持續下降，表示流程變更有實際效果。</p>
<h2 id="設計責任">設計責任</h2>
<p>MTTR 指標要搭配樣本數、嚴重度分層與影響範圍一起解讀。它應導向流程改善與演練設計，而不是單純追求數字下降。</p>
]]></content:encoded></item></channel></rss>