<?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>Canary on Tarragon</title><link>https://tarrragon.github.io/blog/tags/canary/</link><description>Recent content in Canary on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Tue, 23 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/canary/index.xml" rel="self" type="application/rss+xml"/><item><title>Canary Release</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/canary-release/</link><pubDate>Tue, 23 Jun 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/canary-release/</guid><description>&lt;p>Canary release 的核心概念是「先把小比例流量導向新版本、觀察行為、再決定是否擴大」。它把版本切換從一次性決策變成連續多批決策，每批都有明確的觀察窗口與停損條件。可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rolling-update/" data-link-title="Rolling Update" data-link-desc="說明逐批替換服務版本的發版策略與風險控制">Rolling Update&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Canary release 位在 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rolling-update/" data-link-title="Rolling Update" data-link-desc="說明逐批替換服務版本的發版策略與風險控制">rolling update&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/release-gate/" data-link-title="Release Gate" data-link-desc="說明變更在正式釋出前如何通過或阻擋">release gate&lt;/a> 之間。Rolling update 是逐批替換實例的機制，canary 是在替換過程中加入「先驗證再擴批」的決策層。Release gate 是每批擴大前的放行條件。可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/canary-perf-check/" data-link-title="Canary Perf Check" data-link-desc="canary release 中針對 latency / throughput 而非 error rate 的退化檢查">Canary Perf Check&lt;/a>。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要 canary release 的訊號是「版本切換需要控制 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/blast-radius/" data-link-title="Blast Radius" data-link-desc="說明事故影響面如何估算與隔離">blast radius&lt;/a>」。判讀要維持 per-version 視角——只看整體平均值會掩蓋新版本的局部退化。常見 stop condition 包含 per-version error rate 偏離、p95/p99 latency 惡化、依賴 timeout 連續超門檻、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/draining/" data-link-title="Draining" data-link-desc="說明服務如何先停止接收新流量，再讓既有工作完成">draining&lt;/a> 未完成。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Canary release 要定義三件事：切換單位（比例 / 區域 / 租戶 / 路由規則）、每批觀察窗口與停損條件、回退路徑（舊版本是否仍能承接回退流量）。效能退化的檢查見 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/canary-perf-check/" data-link-title="Canary Perf Check" data-link-desc="canary release 中針對 latency / throughput 而非 error rate 的退化檢查">Canary Perf Check&lt;/a>。Canary 決策的 evidence 格式見 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/evidence-package/" data-link-title="Evidence Package" data-link-desc="說明觀測、驗證與事故流程如何把證據包成可交接、可回放的 artifact">Evidence Package&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>Canary release 的核心概念是「先把小比例流量導向新版本、觀察行為、再決定是否擴大」。它把版本切換從一次性決策變成連續多批決策，每批都有明確的觀察窗口與停損條件。可先對照 <a href="/blog/backend/knowledge-cards/rolling-update/" data-link-title="Rolling Update" data-link-desc="說明逐批替換服務版本的發版策略與風險控制">Rolling Update</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Canary release 位在 <a href="/blog/backend/knowledge-cards/rolling-update/" data-link-title="Rolling Update" data-link-desc="說明逐批替換服務版本的發版策略與風險控制">rolling update</a> 與 <a href="/blog/backend/knowledge-cards/release-gate/" data-link-title="Release Gate" data-link-desc="說明變更在正式釋出前如何通過或阻擋">release gate</a> 之間。Rolling update 是逐批替換實例的機制，canary 是在替換過程中加入「先驗證再擴批」的決策層。Release gate 是每批擴大前的放行條件。可先對照 <a href="/blog/backend/knowledge-cards/canary-perf-check/" data-link-title="Canary Perf Check" data-link-desc="canary release 中針對 latency / throughput 而非 error rate 的退化檢查">Canary Perf Check</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要 canary release 的訊號是「版本切換需要控制 <a href="/blog/backend/knowledge-cards/blast-radius/" data-link-title="Blast Radius" data-link-desc="說明事故影響面如何估算與隔離">blast radius</a>」。判讀要維持 per-version 視角——只看整體平均值會掩蓋新版本的局部退化。常見 stop condition 包含 per-version error rate 偏離、p95/p99 latency 惡化、依賴 timeout 連續超門檻、<a href="/blog/backend/knowledge-cards/draining/" data-link-title="Draining" data-link-desc="說明服務如何先停止接收新流量，再讓既有工作完成">draining</a> 未完成。</p>
<h2 id="設計責任">設計責任</h2>
<p>Canary release 要定義三件事：切換單位（比例 / 區域 / 租戶 / 路由規則）、每批觀察窗口與停損條件、回退路徑（舊版本是否仍能承接回退流量）。效能退化的檢查見 <a href="/blog/backend/knowledge-cards/canary-perf-check/" data-link-title="Canary Perf Check" data-link-desc="canary release 中針對 latency / throughput 而非 error rate 的退化檢查">Canary Perf Check</a>。Canary 決策的 evidence 格式見 <a href="/blog/backend/knowledge-cards/evidence-package/" data-link-title="Evidence Package" data-link-desc="說明觀測、驗證與事故流程如何把證據包成可交接、可回放的 artifact">Evidence Package</a>。</p>
]]></content:encoded></item></channel></rss>