<?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>Rollback Rehearsal on Tarragon</title><link>https://tarrragon.github.io/blog/tags/rollback-rehearsal/</link><description>Recent content in Rollback Rehearsal on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 24 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/rollback-rehearsal/index.xml" rel="self" type="application/rss+xml"/><item><title>Rollback Rehearsal</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/rollback-rehearsal/</link><pubDate>Fri, 24 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/rollback-rehearsal/</guid><description>&lt;p>Rollback Rehearsal 的核心概念是「在低風險環境實際走一次回滾流程，確認步驟、權限與耗時都符合預期」。 可先對照 &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;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Rollback Rehearsal 位在 release gate、rollback strategy、migration 與 disaster recovery 之間。它是把回滾步驟實際走過一次的演練，文件審查無法替代實機驗證。 可先對照 &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;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要 rollback rehearsal 的訊號是：&lt;/p>
&lt;ul>
&lt;li>變更失敗時回復速度會直接影響使用者影響&lt;/li>
&lt;li>團隊不確定回滾步驟是否真的可執行&lt;/li>
&lt;li>高風險 migration 或 release 會同時影響資料與流量&lt;/li>
&lt;li>權限、腳本、順序或相容性可能成為回復瓶頸&lt;/li>
&lt;/ul>
&lt;h2 id="接近真實網路服務的例子">接近真實網路服務的例子&lt;/h2>
&lt;p>資料表結構變更前先在接近正式環境演練 rollback，可以確認舊欄位是否還能恢復、資料補回是否可逆、以及切回舊版本後是否還能接流量。服務替換前做 rollback rehearsal，也能驗證 DNS、load balancer 與設定切換的回復時間。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Rollback Rehearsal 要定義環境、資料範圍、演練步驟、驗證項目與紀錄方式。演練的重點是找出「看似可回滾、實際回不去」的缺口。&lt;/p></description><content:encoded><![CDATA[<p>Rollback Rehearsal 的核心概念是「在低風險環境實際走一次回滾流程，確認步驟、權限與耗時都符合預期」。 可先對照 <a href="/blog/backend/knowledge-cards/rollback-strategy/" data-link-title="Rollback Strategy" data-link-desc="說明事故期間如何判斷回滾、回切與暫停變更">Rollback Strategy</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Rollback Rehearsal 位在 release gate、rollback strategy、migration 與 disaster recovery 之間。它是把回滾步驟實際走過一次的演練，文件審查無法替代實機驗證。 可先對照 <a href="/blog/backend/knowledge-cards/rollback-strategy/" data-link-title="Rollback Strategy" data-link-desc="說明事故期間如何判斷回滾、回切與暫停變更">Rollback Strategy</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要 rollback rehearsal 的訊號是：</p>
<ul>
<li>變更失敗時回復速度會直接影響使用者影響</li>
<li>團隊不確定回滾步驟是否真的可執行</li>
<li>高風險 migration 或 release 會同時影響資料與流量</li>
<li>權限、腳本、順序或相容性可能成為回復瓶頸</li>
</ul>
<h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2>
<p>資料表結構變更前先在接近正式環境演練 rollback，可以確認舊欄位是否還能恢復、資料補回是否可逆、以及切回舊版本後是否還能接流量。服務替換前做 rollback rehearsal，也能驗證 DNS、load balancer 與設定切換的回復時間。</p>
<h2 id="設計責任">設計責任</h2>
<p>Rollback Rehearsal 要定義環境、資料範圍、演練步驟、驗證項目與紀錄方式。演練的重點是找出「看似可回滾、實際回不去」的缺口。</p>
]]></content:encoded></item></channel></rss>