<?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>Status Page on Tarragon</title><link>https://tarrragon.github.io/blog/tags/status-page/</link><description>Recent content in Status Page on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Sat, 02 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/status-page/index.xml" rel="self" type="application/rss+xml"/><item><title>Status Page</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/status-page/</link><pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/status-page/</guid><description>&lt;p>Status page 的核心概念是「把事故影響、處理節奏與回復進度公開成單一對外契約」。它和 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel&lt;/a> 與 &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>Status page 位在 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/stakeholder-mapping/" data-link-title="Stakeholder Mapping" data-link-desc="說明事故期間如何把通報對象分層與對應 owner">stakeholder mapping&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> 之間。它把內部節奏轉成客戶可讀的更新，並把 ETA、影響範圍與下一次更新時間固定下來。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要 status page 的訊號是事故已經影響外部使用者，但內部的戰情室節奏還不能直接交給客戶。常見例子包括區域性 outage、身份平台失效、外部供應商中斷與多租戶服務退化。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Status page 要定義更新頻率、發佈責任、嚴重度標示、影響範圍與下一次更新承諾。它是外部信任的最小承諾面，用公關模板的心態維護會失去可信度。&lt;/p></description><content:encoded><![CDATA[<p>Status page 的核心概念是「把事故影響、處理節奏與回復進度公開成單一對外契約」。它和 <a href="/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel</a> 與 <a href="/blog/backend/knowledge-cards/incident-severity/" data-link-title="Incident Severity" data-link-desc="說明事故分級如何把產品影響轉成對應處置節奏">incident severity</a> 一起決定外部看到的真實版本。</p>
<h2 id="概念位置">概念位置</h2>
<p>Status page 位在 <a href="/blog/backend/knowledge-cards/incident-communication-channel/" data-link-title="Incident Communication Channel" data-link-desc="說明事故期間內外部溝通要使用哪些固定通道與節奏">incident communication channel</a>、<a href="/blog/backend/knowledge-cards/stakeholder-mapping/" data-link-title="Stakeholder Mapping" data-link-desc="說明事故期間如何把通報對象分層與對應 owner">stakeholder mapping</a> 與 <a href="/blog/backend/knowledge-cards/post-incident-review/" data-link-title="Post-Incident Review" data-link-desc="說明事故後如何完成復盤、學習與改進閉環">post-incident-review</a> 之間。它把內部節奏轉成客戶可讀的更新，並把 ETA、影響範圍與下一次更新時間固定下來。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要 status page 的訊號是事故已經影響外部使用者，但內部的戰情室節奏還不能直接交給客戶。常見例子包括區域性 outage、身份平台失效、外部供應商中斷與多租戶服務退化。</p>
<h2 id="設計責任">設計責任</h2>
<p>Status page 要定義更新頻率、發佈責任、嚴重度標示、影響範圍與下一次更新承諾。它是外部信任的最小承諾面，用公關模板的心態維護會失去可信度。</p>
]]></content:encoded></item></channel></rss>