<?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%81%A5%E5%BA%B7%E6%AA%A2%E6%9F%A5/</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>Fri, 24 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E5%81%A5%E5%BA%B7%E6%AA%A2%E6%9F%A5/index.xml" rel="self" type="application/rss+xml"/><item><title>Health Check</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/health-check/</link><pubDate>Fri, 24 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/health-check/</guid><description>&lt;p>Health Check 的核心概念是「讓平台用一個簡單回應判斷服務是否值得接流量或是否需要介入」。它是狀態判斷的入口語意，不等於 readiness、liveness 或 diagnostic endpoint 本身。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/histogram/" data-link-title="Histogram" data-link-desc="說明 histogram 如何用分桶統計延遲、大小與分布">Histogram&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Health Check 位在 load balancer、platform、diagnostic endpoint 與 application 之間。平台會依這個回應決定是否導流、是否重啟，或是否需要進一步檢查。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/histogram/" data-link-title="Histogram" data-link-desc="說明 histogram 如何用分桶統計延遲、大小與分布">Histogram&lt;/a>。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要 health check 的訊號是服務需要一個快速、低成本、可自動化的狀態回應，讓平台不用靠猜測判斷是否正常。&lt;/p>
&lt;h2 id="接近真實網路服務的例子">接近真實網路服務的例子&lt;/h2>
&lt;p>Load balancer 以 health check 判斷 instance 能否接新流量；運維工具以 health check 快速確認服務是否仍回應；Kubernetes 會把 health check 的責任拆到 readiness / liveness / startup probe。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>設計時要讓 health check 保持簡單、穩定、低成本，並且只反映它被設計要回答的問題。更細的流量條件交給 readiness，更細的存活條件交給 liveness，更完整的操作介面交給 diagnostic endpoint。&lt;/p></description><content:encoded><![CDATA[<p>Health Check 的核心概念是「讓平台用一個簡單回應判斷服務是否值得接流量或是否需要介入」。它是狀態判斷的入口語意，不等於 readiness、liveness 或 diagnostic endpoint 本身。 可先對照 <a href="/blog/backend/knowledge-cards/histogram/" data-link-title="Histogram" data-link-desc="說明 histogram 如何用分桶統計延遲、大小與分布">Histogram</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Health Check 位在 load balancer、platform、diagnostic endpoint 與 application 之間。平台會依這個回應決定是否導流、是否重啟，或是否需要進一步檢查。 可先對照 <a href="/blog/backend/knowledge-cards/histogram/" data-link-title="Histogram" data-link-desc="說明 histogram 如何用分桶統計延遲、大小與分布">Histogram</a>。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要 health check 的訊號是服務需要一個快速、低成本、可自動化的狀態回應，讓平台不用靠猜測判斷是否正常。</p>
<h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2>
<p>Load balancer 以 health check 判斷 instance 能否接新流量；運維工具以 health check 快速確認服務是否仍回應；Kubernetes 會把 health check 的責任拆到 readiness / liveness / startup probe。</p>
<h2 id="設計責任">設計責任</h2>
<p>設計時要讓 health check 保持簡單、穩定、低成本，並且只反映它被設計要回答的問題。更細的流量條件交給 readiness，更細的存活條件交給 liveness，更完整的操作介面交給 diagnostic endpoint。</p>
]]></content:encoded></item></channel></rss>