我的知識庫

DevOps 設計 Pattern 高級詳解

閱讀時間約 14 分鐘

GitOps

  • What — 以 Git repo 作為基礎設施與應用部署的唯一真相來源（source of truth）；Kubernetes operator 持續比對 Git 宣告狀態與實際叢集狀態，發現 drift 就自動調和（reconcile）。
  • Why — 傳統 CI/CD 是 push-based（pipeline 直接 kubectl apply）——誰 apply 了什麼難以審計、手動 patch 造成環境 drift、rollback 依賴 pipeline 重跑。GitOps 讓所有變更通過 PR review，rollback 等於 git revert。
  • When — 適用：Kubernetes 為主的部署平台、有多個環境（dev/staging/prod）需要一致管理、團隊重視 auditability 和 change control。不適用：非 Kubernetes 環境（GitOps operator 幾乎都是 K8s-native）、小型單一環境（git 流程的 overhead 不值得）、頻繁且大量的 auto-scaling 場景（自動 scale 的 replica 數不應該寫死在 Git）。
  • Where — Kubernetes 叢集的 CD 層；IaC 的狀態管理層（Terraform Cloud 延伸）。
  • Who — Argo CD（CNCF 畢業專案，最廣泛採用的 GitOps operator）；Flux v2（CNCF 畢業，Weaveworks 出品，支援多租戶）；Terraform Cloud（IaC 的 GitOps 延伸）。
  • 實踐 — 分離 app repo 和 infra/config repo（避免 app commit 觸發不必要的 config repo 髒讀）；image tag 更新的自動化用 Flux Image Automation 或 Argo CD Image Updater；multi-cluster 管理用 Argo CD ApplicationSet；secrets 不應該放進 Git——用 Sealed Secrets 或 External Secrets Operator；GitOps 不等於 NoOps——叢集本身的 day-2 操作（node upgrade、cert rotation）仍需人工介入。

Blue-Green 部署

  • What — 同時維持兩個完全相同的生產環境（Blue 現行、Green 新版）；切換流量路由器指向 Green 完成部署；Blue 保留作為即時 rollback。
  • Why — 傳統 rolling update 在切換過程中同時跑新舊版本，對有 schema 或 API 不相容的變更很危險；Blue-Green 讓版本切換是原子性的（對 router 而言）。
  • When — 適用：資料庫 schema 相容的變更、stateless 服務（session 和 sticky connection 要特別處理）、需要即時 rollback 能力的關鍵服務。不適用：有狀態服務（DB、有 local state 的 service）的直接切換有風險；資源有限的環境（Blue-Green 需要雙倍資源）；schema migration 需要不相容 DDL 的情況（需先做 expand-contract migration）。
  • Where — 服務層的流量路由；load balancer / ingress controller 層的切換控制。
  • Who — Kubernetes Deployment（rollback 機制是 Blue-Green 的簡化版）；Argo Rollouts（原生 Blue-Green + Canary 分析）；Spinnaker（Netflix 出品，multi-cloud CD platform）；AWS CodeDeploy（托管式 Blue-Green）。
  • 實踐 — 切換前 warm up Green 環境（預熱快取、JVM JIT）；切換後不要立刻關 Blue——至少保留一個監控窗口（5–30 分鐘視業務而定）；session stickiness 問題：要麼 stateless token（JWT）要麼 distributed session（Redis）；DB schema migration 要用 expand-contract——先加 nullable 新欄、兩版本都寫、舊版下線後再刪舊欄。

Canary 部署與 Progressive Delivery

  • What — 把新版本路由給一小部分（1–5%）的真實流量；觀察 error rate / latency / 業務指標；逐步擴大比例或 rollback。
  • Why — Blue-Green 是全有或全無；Canary 讓真實用戶流量成為驗證手段，比 staging 更接近生產環境，同時把爆炸半徑控制在一小部分用戶。
  • When — 適用：重大功能變更（algorithm 替換、ML model 更新）、API 行為改變需要生產環境驗證、A/B testing（搭配指標分析）。不適用：需要所有用戶同時看到相同版本的場景（一致性要求高的功能）；後端 schema migration 的不相容部分（canary 期間新舊版本混跑，schema 必須相容）。
  • Where — 流量路由層（ingress / service mesh）；邊緣計算層（Cloudflare Workers）；feature flag 系統（以用戶屬性切分）。
  • Who — Argo Rollouts（analysis template 自動查 Prometheus 指標決定繼續或 rollback）；Flagger（FluxCD 生態，支援 Istio/Nginx/App Mesh）；LaunchDarkly（Feature Flag 驅動的 canary，以用戶屬性而非流量比例切分）；Cloudflare Workers（edge-level traffic split）。
  • 實踐 — 「分析」是 Canary 的核心——要事先定義 success criteria（error rate < 1%，p99 < 500ms），不是部署後主觀看圖；Argo Rollouts 的 AnalysisTemplate 可以自動查 Prometheus / Datadog / New Relic；Canary 期間 log 要有 version tag，否則 error 難以區分是新版還是舊版；最終一致性的服務（eventual consistent DB）在 canary 期間可能有新舊寫入混用問題，需要設計相容。

Service Mesh 與 Sidecar Pattern

  • What — 在每個 pod 旁注入一個 proxy sidecar（如 Envoy）；服務間的所有網路流量都流經 sidecar；mTLS、retry、circuit breaking、tracing、rate limiting 在 proxy 層處理，應用程式碼無感。
  • Why — 微服務架構的 cross-cutting concerns（可觀測性、安全性、彈性）若在每個服務各自實作，等於 N 倍的重複工作且語言異質；Sidecar 讓這些能力下沉到基礎設施層。
  • When — 適用：多語言微服務架構（N 個語言各自實作 mTLS 太痛）、需要 zero-trust 網路（每個 service 驗證對方身份）、細粒度流量管控（A/B、Canary by service）。不適用：小型服務（2–3 個服務）——mesh 的運維複雜度不值得；批次計算（非 HTTP/gRPC 的網路通訊，mesh 支援有限）；latency 極度敏感的場景（sidecar hop 增加 1–3ms）。
  • Where — Kubernetes pod 層（sidecar container injection）；網路 dataplane（Envoy proxy）；control plane（Istio istiod / Linkerd control plane）。
  • Who — Istio（最功能完整，也最複雜）；Linkerd（輕量，Rust-based proxy，CNCF 畢業）；Envoy Proxy（最底層，Istio 和其他 mesh 的 dataplane）；Cilium（eBPF-based，不需要 sidecar，效能更好）。
  • 實踐 — Istio 的學習曲線極陡——CRD 複雜度相當高，強烈建議從 Linkerd 入門再評估是否需要 Istio；eBPF-based mesh（Cilium）的 sidecarless 方案是 2024 年後的新趨勢，避免了 sidecar 的 resource overhead；mTLS 憑證管理要自動輪換（cert-manager）；service mesh 的 observability 資料（trace、metric）要接 Prometheus + Jaeger/Zipkin。

Immutable Infrastructure

  • What — 基礎設施資源（VM、container image）一旦建立就不修改；需要變更則建立新的 image、部署新資源、淘汰舊資源。
  • Why — 傳統「設定管理（configuration management）」（Ansible/Chef/Puppet 直接修改運行中的伺服器）會讓伺服器狀態隨時間漂移（configuration drift）——兩台「相同」的伺服器可能因為不同的 patch 順序有微妙差異，導致難以重現的 bug。
  • When — 適用：雲端環境（資源可快速銷毀重建）、Kubernetes 容器化部署（image-based by nature）、需要完全可重現環境的場景。不適用：有大量有狀態資料的伺服器（直接 immutable 有資料遷移問題）；變更頻繁但資源重建速度慢的場景（image build pipeline 的速度是瓶頸）。
  • Where — 基礎設施層（VM image build）；容器層（Docker image）；作業系統層（NixOS）。
  • Who — HashiCorp Packer（多平台 VM image builder）；Docker（container image 天生 immutable）；NixOS / Nix（把 immutable infrastructure 推到作業系統層級，可重現的環境宣告）；Bottlerocket（AWS 出品，專為容器設計的 immutable Linux 發行版）。
  • 實踐 — image 的版本管理要嚴格（semantic versioning 或 git SHA tag，禁止 latest）；base image 的安全更新要自動化（dependabot / renovatebot 掃描）；Nix 的學習曲線高但帶來最強的可重現性保證（同樣的 nix expression 在任何機器產生 bit-for-bit 相同的環境）；有狀態資料（DB volume）要與 immutable compute 分離，不要混在一起。

Feature Flags

  • What — 在應用程式碼中的 if/else 開關，由外部設定系統控制；讓功能的部署（code 合進 main）與發布（用戶看到功能）解耦。
  • Why — 長期 feature branch 是技術債和 merge 地獄的根源；Feature Flags 讓開發者直接在 main branch 開發、以 flag 隱藏未完成功能，實現真正的 trunk-based development；也讓 kill switch 和 A/B test 成為標準操作。
  • When — 適用：Trunk-based development、漸進式功能發布（Canary by user segment）、實驗性功能、緊急 kill switch。不適用：Flag 數量不加控制——flag debt 比 branch debt 更難清理（要有 flag lifecycle 管理）；核心業務邏輯的 if/else 不應該是 feature flag（邏輯應該明確，不應依賴運行期配置）。
  • Where — 應用程式碼層（SDK 注入）；前端（client-side flag，需考量 flicker）；CI/CD pipeline（deployment gate）。
  • Who — LaunchDarkly（商業產品，業界標準之一）；Unleash（OSS，可自托管）；Flagsmith（OSS + 商業，支援 remote config）；OpenFeature（CNCF 標準化的 feature flag SDK interface，避免 vendor lock-in）；GrowthBook（OSS，內建 A/B test 分析）。
  • 實踐 — Flag 要有 owner 和 expiry date（過期自動提醒刪除）；flag 評估邏輯要在用戶請求 context 裡（user ID、attributes）——太早評估（啟動時）失去動態控制的意義；client-side flag（前端）要考慮 flag 值的快取與 flicker（用戶看到功能瞬間消失）；OpenFeature SDK 讓你可以換 backend（從 Unleash 換 LaunchDarkly）而不改應用程式碼。

Observability Pattern（三支柱）

  • What — 可觀測性（Observability）由三個互補的遙測資料類型組成：Metrics（聚合時序指標）、Logs（離散事件記錄）、Traces（跨服務請求鏈路）；三者結合讓工程師能從外部行為推斷系統內部狀態，無需在生產環境直接 debug。
  • Why — 傳統監控（monitoring）是「已知的未知」——預定義哪些 metric 要告警；Observability 處理「未知的未知」——系統出現從未見過的失敗模式時，能從 traces 和 logs 推斷根因，不需要提前預測所有可能的失敗。
  • When — 適用：任何生產環境的後端服務——這是現代系統工程的基礎設施，不是可選項。不適用：「有了 observability 就不需要 staging 環境」這個誤解——observability 幫你理解生產問題，不能取代測試環境的驗證。
  • Where — 應用程式層（instrumentation SDK）；基礎設施層（node exporter、kube-state-metrics）；平台層（telemetry pipeline、storage backend）。
  • Who — OpenTelemetry（CNCF，統一的遙測資料收集標準，支援 metrics/logs/traces，廠商中立）；Prometheus（metrics 收集與告警的事實標準）；Jaeger（分散式 trace，CNCF 畢業）；Grafana（視覺化儀表板，可接所有 telemetry backend）；Grafana Loki（log 聚合，Prometheus-like 但給 logs）。
  • 實踐 — 從 OpenTelemetry SDK 開始——它是廠商中立的標準，讓你可以換 backend（Jaeger / Tempo / Honeycomb）而不改 instrumentation code；Trace 的 sampling 策略要仔細設計（全量 trace 成本高，但 tail-based sampling 才能抓到慢請求）；Metrics cardinality 爆炸是 Prometheus 最常見的生產問題——label 值不能是 user ID 這種高基數欄位；SLO（Service Level Objective）要建立在 metrics 之上，不是憑感覺寫 alert threshold；Logs 的結構化（JSON）比非結構化文字更容易查詢——Loki 的 LogQL 要對結構化 log 才好用。

與既有專欄的關係

Observability 的 instrumentation 是 AI Agentic SaaS 架構的重要一環，見 AI Agentic SaaS 工程實踐。

Feature Flags 的決策邏輯（何時用 flag vs 直接部署）與 spec-driven development 的功能閘門概念相關，見 Problem Framing + Spec-Driven Development。

待解問題 / 持續追蹤

  • eBPF-based service mesh（Cilium Mesh）vs sidecar mesh（Istio/Linkerd）的生產規模對比數據：性能差距有多大？CNCF Survey 2024 有初步數據但樣本有限。
  • GitOps 在非 Kubernetes 環境（VM-based、serverless-heavy）的最佳實踐尚不成熟——有什麼 pattern 正在出現？
  • Feature Flag 的 AI 輔助決策（自動根據 error rate 決定 rollout 進度）是否有 OSS 實作？GrowthBook 有部分 A/B 自動分析，但 flag lifecycle 管理的 AI 輔助尚未成熟。

更新紀錄

  • 2026-07-03 — 建立。涵蓋 GitOps、Blue-Green、Canary/Progressive Delivery、Service Mesh/Sidecar、Immutable Infrastructure、Feature Flags、Observability 三支柱七個 DevOps pattern。

反向連結