<?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/%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/%E8%99%95%E7%BD%AE%E6%89%8B%E5%86%8A/index.xml" rel="self" type="application/rss+xml"/><item><title>Playbook</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/playbook/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/playbook/</guid><description>&lt;p>Playbook 的核心概念是「針對特定故障場景提供可直接執行的處置腳本」。它比通用 &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>Playbook 位在 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/incident-command-system/" data-link-title="Incident Command System" data-link-desc="說明事故期間的指揮角色、決策邊界與協作方式">incident command system&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rollback-strategy/" data-link-title="Rollback Strategy" data-link-desc="說明事故期間如何判斷回滾、回切與暫停變更">rollback-strategy&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> 之間。復盤後的改進常會沉澱成新的 playbook。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要 playbook 的訊號是某類事故反覆出現且處置步驟可預期。consumer lag 持續擴大、憑證即將過期、單區域流量異常等場景都適合建立專用 playbook。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Playbook 要定義觸發條件、必要查詢、操作步驟、停止條件與回復驗證。內容應保持短而可執行，並在每次演練或真實事故後更新。&lt;/p></description><content:encoded><![CDATA[<p>Playbook 的核心概念是「針對特定故障場景提供可直接執行的處置腳本」。它比通用 <a href="/blog/backend/knowledge-cards/runbook/" data-link-title="Runbook" data-link-desc="說明 runbook 如何把事故判斷與操作步驟標準化">runbook</a> 更聚焦，通常對應單一風險模式或單一系統路徑。</p>
<h2 id="概念位置">概念位置</h2>
<p>Playbook 位在 <a href="/blog/backend/knowledge-cards/incident-command-system/" data-link-title="Incident Command System" data-link-desc="說明事故期間的指揮角色、決策邊界與協作方式">incident command system</a>、<a href="/blog/backend/knowledge-cards/rollback-strategy/" data-link-title="Rollback Strategy" data-link-desc="說明事故期間如何判斷回滾、回切與暫停變更">rollback-strategy</a> 與 <a href="/blog/backend/knowledge-cards/post-incident-review/" data-link-title="Post-Incident Review" data-link-desc="說明事故後如何完成復盤、學習與改進閉環">post-incident-review</a> 之間。復盤後的改進常會沉澱成新的 playbook。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要 playbook 的訊號是某類事故反覆出現且處置步驟可預期。consumer lag 持續擴大、憑證即將過期、單區域流量異常等場景都適合建立專用 playbook。</p>
<h2 id="設計責任">設計責任</h2>
<p>Playbook 要定義觸發條件、必要查詢、操作步驟、停止條件與回復驗證。內容應保持短而可執行，並在每次演練或真實事故後更新。</p>
]]></content:encoded></item></channel></rss>