Case-First on Tarragonhttps://tarrragon.github.io/blog/tags/case-first/Recent content in Case-First on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Mon, 18 May 2026 00:00:00 +0000Vendor 深度技術文章方法論的演化紀錄：同 vendor 系列的開場輪替驗證https://tarrragon.github.io/blog/posts/vendor-%E6%B7%B1%E5%BA%A6%E6%8A%80%E8%A1%93%E6%96%87%E7%AB%A0%E6%96%B9%E6%B3%95%E8%AB%96%E7%9A%84%E6%BC%94%E5%8C%96%E7%B4%80%E9%8C%84%E5%90%8C-vendor-%E7%B3%BB%E5%88%97%E7%9A%84%E9%96%8B%E5%A0%B4%E8%BC%AA%E6%9B%BF%E9%A9%97%E8%AD%89/Mon, 18 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/posts/vendor-%E6%B7%B1%E5%BA%A6%E6%8A%80%E8%A1%93%E6%96%87%E7%AB%A0%E6%96%B9%E6%B3%95%E8%AB%96%E7%9A%84%E6%BC%94%E5%8C%96%E7%B4%80%E9%8C%84%E5%90%8C-vendor-%E7%B3%BB%E5%88%97%E7%9A%84%E9%96%8B%E5%A0%B4%E8%BC%AA%E6%9B%BF%E9%A9%97%E8%AD%89/<p>Vendor overview 寫完後、往下寫單一功能深度文章時，選題與結構需要不同的方法論。操作步驟維護在 <code>.claude/skills/vendor-deep-article/</code>，本文記錄這套方法論從兩輪 batch 中演化出來的過程，重點是 cadence collapse（批量寫作時開場句型同質化重複）怎麼被寫前的 variant 規劃（每篇預先指定不同開場 framing）解決。</p> <h2 id="背景">背景</h2> <p>本 blog 的 backend 教學模組已完成多個 vendor overview。overview 層飽和後、自然的下一步是 overview 頁尾「預計實作話題」backlog 的深度文章。</p> <p>寫了 deep article + migration playbook 後、確認 deep article 跟 overview 是不同產品、需要自己的方法論。差異見 <a href="https://tarrragon.github.io/blog/posts/migration-playbook-%E6%96%B9%E6%B3%95%E8%AB%96%E7%9A%84%E6%BC%94%E5%8C%96%E7%B4%80%E9%8C%84stage-0-variant-%E8%A6%8F%E5%8A%83%E6%8A%8A-collapse-%E7%8E%87%E5%BE%9E-60-%E9%99%8D%E5%88%B0-0/" data-link-title="Migration Playbook 方法論的演化紀錄：Stage 0 variant 規劃把 collapse 率從 60% 降到 0%" data-link-desc="跨 vendor migration playbook 需要獨立寫作方法論的依據，以及這套方法論從三輪 batch dogfood 中演化出來的驗證證據。">migration playbook 方法論演化紀錄</a>。</p> <h2 id="第一輪-batch5-篇跨-vendor5-種-entry-framing">第一輪 batch（5 篇）：跨 vendor、5 種 entry framing</h2> <table> <thead> <tr> <th>篇</th> <th>Variant</th> <th>章節 1 entry framing</th> <th>行數</th> </tr> </thead> <tbody> <tr> <td><a href="https://tarrragon.github.io/blog/backend/01-database/vendors/postgresql/pgbouncer-config/" data-link-title="PostgreSQL pgBouncer 配置 &#43; 連線池治理" data-link-desc="pgBouncer transaction pooling 配置、跟 application connection pool 的分層、production 故障演練（pool exhaustion / stale connection / DNS failover）跟容量規劃">pgBouncer 配置</a></td> <td>A 標準</td> <td>標準「問題情境」</td> <td>263</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/vendors/hashicorp-vault/dynamic-credential/" data-link-title="HashiCorp Vault Dynamic Credential：lease 治理跟 application 整合的實作層" data-link-desc="Vault database secrets engine 怎麼配、application 怎麼 renew lease、production 五大踩雷（lease 過期 race、DB max_connections 撞牆、Vault sealed、token expire、scope 過寬）、容量規劃跟 vault-agent injector 整合">Vault dynamic credential</a></td> <td>A 標準</td> <td>標準「問題情境」</td> <td>222</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/05-deployment-platform/vendors/kubernetes/graceful-shutdown/" data-link-title="Kubernetes Graceful Shutdown：termination 序列跟你以為的不一樣" data-link-desc="K8s pod termination 五步序列、preStop / SIGTERM / terminationGracePeriodSeconds 的真實時序、5 個 production 踩雷（500 期間 502、connection drain race、init container 重啟、StatefulSet 串行終止、Job 不 graceful）、跟 service mesh / readiness probe 整合">K8s graceful shutdown</a></td> <td>B 痛點</td> <td>痛點宣告「沒做對、每次 deploy 都吃 502」</td> <td>213</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/vendors/splunk/risk-based-alerting/" data-link-title="Splunk Risk-Based Alerting：從 alert per rule 到 score-aggregated notable" data-link-desc="Splunk Enterprise Security 的 RBA 方法論：risk score / modifier / notable 三層 model、ES 配置 step-by-step、tuning playbook（false positive / score inflation / threshold drift / decay）、capacity 成本、跟 SOAR &#43; case management 整合">Splunk RBA</a></td> <td>C 反向</td> <td>概念反向定義「alert fatigue 是 detection 天花板」</td> <td>193</td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/vendors/cloudflare-waf/page-shield-csp-sri/" data-link-title="Cloudflare Page Shield：用 CSP &#43; SRI &#43; script monitoring 防 client-side supply chain" data-link-desc="Page Shield 三層防禦（CSP / SRI / script monitoring）對應 Magecart / formjacking / skimmer / 第三方 SDK 注入的不同 attack pattern、Cloudflare dashboard &#43; API 配置、四個 production 踩雷（inline script 漏 / dynamic loader / CSP report 噪音 / SRI hash mismatch）、跟 dev workflow &#43; WAF 整合">Cloudflare Page Shield</a></td> <td>D 對照表</td> <td>對照表驅動「Attack pattern x Defense mechanism」</td> <td>214</td> </tr> </tbody> </table> <p>第一輪確認了結構 framework 成立、且章節名可隨主題調整。</p>Vendor overview 寫完後、往下寫單一功能深度文章時，選題與結構需要不同的方法論。操作步驟維護在 .claude/skills/vendor-deep-article/，本文記錄這套方法論從兩輪 batch 中演化出來的過程，重點是 cadence collapse（批量寫作時開場句型同質化重複）怎麼被寫前的 variant 規劃（每篇預先指定不同開場 framing）解決。

背景

本 blog 的 backend 教學模組已完成多個 vendor overview。overview 層飽和後、自然的下一步是 overview 頁尾「預計實作話題」backlog 的深度文章。

寫了 deep article + migration playbook 後、確認 deep article 跟 overview 是不同產品、需要自己的方法論。差異見 migration playbook 方法論演化紀錄。

第一輪 batch（5 篇）：跨 vendor、5 種 entry framing

篇 Variant 章節 1 entry framing 行數
pgBouncer 配置 A 標準 標準「問題情境」 263
Vault dynamic credential A 標準 標準「問題情境」 222
K8s graceful shutdown B 痛點 痛點宣告「沒做對、每次 deploy 都吃 502」 213
Splunk RBA C 反向 概念反向定義「alert fatigue 是 detection 天花板」 193
Cloudflare Page Shield D 對照表 對照表驅動「Attack pattern x Defense mechanism」 214

第一輪確認了結構 framework 成立、且章節名可隨主題調整。

6 段 framework 成立但章節名可變

6 段內容指引（問題情境 → 概念 → 配置 → 演練 → 容量 → 整合）在 5 篇都成立。但章節 1 的 framing 因主題本質不同自然分化 — 5 種 entry framing 都成立、章節 1 不必死守「問題情境」標題。

據此小修方法論：6 段 framework 是內容指引、不是章節標題模板。

Cadence collapse 0% — 主動 variant 有效

後 4 篇寫作前主動規劃 4 種 framing variant。跟 backend/07 的 51 vendor batch 對照：

維度 backend/07 51 vendor deep article 後 4 篇
Cadence「任一缺失」族重複 51/51 (100%) 0/4 (0%)
章節 1 entry framing 種類 1 種 4 種

Reviewer 單人足夠

deep article 焦點窄（單一 feature）、跨章 frame 重複風險低、case 引用密度低（1-2 個對照）。5 篇都採單一 reviewer 流程、未出現需要 multi-axis review 的盲點。

第二輪 batch（5 篇）：同 vendor sub-tool 系列、最高 collapse 風險

第二輪刻意選 cadence collapse 最高風險場景：5 篇 PostgreSQL sub-tool deep article、同 vendor / 同 article type / 同 audience / 同 6-section framework。

篇 Variant 章節 1 entry framing 行數
Patroni HA E lifecycle-driven 「Failover lifecycle 5 段不是一條曲線」 243
autovacuum tuning B pain-driven 「你的 autovacuum 永遠追不上 bloat — 為什麼」 202
declarative partitioning C concept-reversed 「Partition 不是『把大表切小』、是『讓 planner pruning + 縮小 maintenance scope』」 244
logical replication + Debezium D table-driven 「Replication slot x Failure x Recovery 對照」 227
PITR + WAL archiving A standard 6-section 「問題情境」 273

第二輪在最高風險場景（同 vendor sub-tool）仍維持 collapse 0%，且新增第五種 variant（lifecycle-driven）。

跨兩輪對照

維度 第一輪 N=4（跨 vendor） 第二輪 N=5（同 vendor sub-tool）
Variant 種類 4（A / B / C / D） 5（A / B / C / D / E）
Cadence collapse 0/4 (0%) 0/5 (0%)
章節 1 entry framing 種類 4 5
共同 context 6-section framework 6-section + 同 vendor + 同讀者

關鍵驗證：

  1. N=5 仍 0% collapse：5 種 variant 在最高風險場景（同 vendor sub-tool）仍完全錯開
  2. 5 variant 不耗盡：5 種變體（lifecycle / pain / reverse / table / standard）對應主題自然進入方式、不是強制配對
  3. cadence audit 最佳位置是進度 60-80%：進度 10-20% 只有 1 樣本訊號弱、60-80% 有 4 樣本對照訊號強

方法論演化小結

版本 修改 驅動來源
v0 直覺套 overview 11 章節 第一篇 deep article 不合用
v1 6 段結構 + 200-400 行 sweet spot 第一輪 5 篇 dogfood
v1.1 6 段是內容指引、不是章節標題模板 章節 1 framing 自然分化
v1.2 寫作時間預估 2-4hr → 1-2hr overview 已建立 context
v1.3 cadence audit 抽樣位置 10-20% → 60-80% 第二輪 N=5 驗證

相關連結

]]>