四個判斷維度

使用者數

自架方案的成本和使用者數幾乎無關（JSONL + grep 處理 1 個和 100 個使用者的成本差異很小）。商業方案按事件量或使用者數計費，使用者數增長直接推高費用。

經驗估算：使用者數在百人以下時，自架的總成本（開發 + 維護 + 硬體）通常低於商業方案的年費（以典型商業方案年費 $300-$600 和自架的開發維護時間估算）。使用者數在千人以上時，自架需要投入的基礎設施維護（高可用、擴容、備份）成本上升，商業方案的規模經濟開始有優勢。具體的交叉點取決於選用的 vendor 定價（Sentry Developer plan 免費額度 5000 events/月、PostHog 免費到 1M events/月）和自架的維護時間成本。

兩者之間是灰色地帶 — 取決於功能需求和團隊能力。

網路範圍

使用者和 collector 是否在同一個網路內。

同一網路（自用工具、內部工具）：自架方案直接 HTTP POST 到本機或內網 endpoint，不需要 DNS、TLS 憑證、CDN。成本極低。

外部網路（公開 app、SaaS）：自架方案需要處理公網暴露、DDoS 防護、TLS 憑證管理、高可用（多區域部署）。商業方案把這些基礎設施問題內化了。

功能需求

自架方案的功能上限是開發者願意投入的工程量。grep + jq 能做基礎查詢和 funnel 分析（模組八 自架 funnel）。Dashboard、告警、session replay、A/B test 分群每個功能都是數週到數月的開發量。

商業方案的功能開箱即用。如果需求包含 session replay、A/B test dashboard、自動 issue 分群，商業方案的功能完成度遠高於自架。

合規要求

資料必須存放在特定地區（GDPR data residency）或不能離開公司網路（金融、醫療）。

自架：資料完全在自己的基礎設施上，資料位置由自己控制。適合最嚴格的合規要求。

商業方案：資料存放在 vendor 的基礎設施上。部分 vendor 提供 data residency 選項（Sentry 的 EU hosting、Datadog 的 EU region），但仍然是第三方持有資料。

決策表

四個維度中三個以上指向同一方向 → 選那個方向。兩兩對半 → 從自架開始（成本低、可逆），需求增長後再評估切換。

決策表指向商業方案後，Sentry 深入和 Firebase 套件分別展開兩個主流方案的架構和能力邊界。決策表指向自架時，模組四 Collector 設計提供從 HTTP endpoint 到 rule engine 的完整實作藍圖。Server-side 的可觀測性（OTLP、Prometheus、Grafana）見 Backend 模組四 可觀測性。

中間路線

上表是「完全自架 vs 專業監控 SaaS」的兩端。中間還有兩條路徑 — 用 BaaS（Supabase + Vercel）搭出託管版 collector，或用 PaaS（Railway / Fly.io）跑自架 collector 原始碼但不管 server。APP 上線初期用免費方案零成本起步、保留自訂 schema 彈性是常見的起步策略。完整的四條路徑比較、架構差異、免費方案限額和遷移路線見部署光譜。

自架 vs 商業的判斷決策表用四個維度（使用者數 / 網路範圍 / 功能需求 / 合規）做二元分流。本章把光譜展開成四條路徑，讓中間的 BaaS 和 PaaS 選項浮現。Backend 選型模組已建立了完整的交付形態光譜（交付形態選型）和逐能力判斷外包深度的框架（能力級買 vs 建）。本章把那個框架特化到監控場景。

四條路徑

路徑 A 和 D 分別是光譜的兩端 — Sentry 深入、Firebase 套件和模組四 Collector 設計已完整討論。以下展開路徑 B 和 C。

路徑 B：BaaS + Serverless

APP 上線初期用 Supabase + Vercel（或 Cloudflare Workers）搭監控後端：serverless function 接收 SDK 送來的事件、驗證 schema 後寫入 Supabase 的 PostgreSQL。整條鏈路在免費方案額度內可以零成本運作。

架構差異

Serverless function 沒有常駐 process。模組四假設的 Go single binary 架構 — channel 背壓、single-writer goroutine pattern、in-memory buffer — 在 serverless 環境都不適用。每個 HTTP request 是獨立的 function invocation，沒有跨 request 的記憶體狀態。

背壓機制需要重新設計：Go collector 用 channel 容量做背壓（channel 滿回 429），serverless 版改用 DB-level 的 rate limit（PostgreSQL 的 advisory lock 或外部 rate limiter 如 Upstash Redis）或 platform-level 的 quota（Vercel 的 concurrency limit）。SDK 端的 429 處理邏輯不需要改 — 不管背壓訊號來自 channel 還是 DB quota，SDK 都是收到 429 後降採樣。

Downsample 和 purge 在 Go collector 是 background goroutine 定期執行。Serverless 沒有 background job — 需要外部 cron trigger（Vercel Cron / Supabase pg_cron / GitHub Actions scheduled workflow）。

免費方案限額

以下為 2026-06 查詢的各平台免費方案限額。平台定價會變動，決策前以官方定價頁為準。

Audit date: 2026-06。平台免費方案限額可能調整，決策前以官方定價頁為準。

適合情境

路徑 B 適合以下組合：APP 上線初期（使用者數 < 100）、團隊熟悉前端和 SQL 但不想管 server、想保留自訂 schema 和查詢彈性（商業 SaaS 的 schema 是 vendor 定義的）、零成本起步但未來可能遷到自架。

撞牆訊號

以下訊號出現時，代表路徑 B 的天花板已到、該評估遷到路徑 C 或 D：

連線數瓶頸：Supabase Free 的 PostgreSQL 約 20 個 concurrent connection。Serverless function 每次 invocation 開新連線，高併發時可能耗盡連線池。Supabase 內建 PgBouncer 做 connection pooling 可緩解，但免費方案的 pooler 有自己的連線上限。

Cold start 延遲：Vercel serverless function 的 cold start 約 200ms、Supabase Edge Function 約 100ms。對監控 ingestion（不是使用者面向 API）通常可接受，但如果 SDK 的 flush timeout 設得很短（< 1s），cold start 可能造成偶發超時。

Background job 限制：Downsample 和 purge 需要外部 cron。Vercel Hobby 支援最多 2 個 cron job、每個最頻繁每天觸發 1 次 — 如果需要每小時 downsample，要用 Supabase pg_cron（Free 方案支援）或外部 scheduler。

免費額度耗盡：Supabase 的 500K Edge Function invocations/月 ≈ 每天 16K requests。如果每個 request 攢批 100 筆事件，可處理每天 160 萬筆事件。超過後進入按量付費。Vercel Hobby 無明確 invocation 上限、瓶頸在 bandwidth（100GB/月）和 execution duration。

合規限制：Supabase Free 的 PostgreSQL 部署在特定 region。有 GDPR data residency 需求的 app（歐盟使用者的資料必須留在 EU）需確認 vendor 的 region 支援 — 免費方案的 region 選擇可能有限。

路徑 C：PaaS

PaaS 跑的是和完全自架相同的 Go collector 原始碼，差異只在部署方式。git push 觸發自動 build 和 deploy，平台管 server provisioning、TLS 憑證、process supervision。Collector 的 channel 背壓、single-writer pattern、SQLite storage 全部適用 — 和本機開發環境的行為一致。

Railway 和 Fly.io 都支援 persistent volume — Railway Hobby 含 1GB、Fly.io Free 含 1GB（限單 region）。SQLite 的 WAL 檔案需要持久化，persistent volume 是必要條件。Render 的免費方案沒有 persistent disk — SQLite 在每次 deploy 後重置，不適合需要保留歷史事件的場景。PaaS 平台以 container 形式運行 collector，SQLite 在 container 中的 I/O 和持久化考量見 Container 部署設計。

路徑 C 適合：想用自架 collector 但不想管 server / TLS / systemd 的團隊。程式碼完全相同，遷到自架（路徑 D）的成本接近零 — 把 binary 複製到 VPS、設定 systemd service 就完成。

路徑 C 的天花板在平台定價 — Railway Hobby 有 $5/月的資源上限、Fly.io Free 有 3 個 shared VM。流量成長到免費額度不夠時，PaaS 的按量付費和 VPS 月租費的交叉點是遷到自架的判讀訊號。

路徑間的遷移

遷移成本取決於起點和終點之間有多少層需要重寫。

路徑 B → C 或 B → D 的遷移代價主要在 collector 邏輯的重寫 — serverless function 的 request-level 處理和 Go binary 的 channel-based pipeline 是不同的架構，不能直接搬。資料層的遷移代價較低 — Supabase 的 PostgreSQL 資料可以用 pg_dump 匯出、匯入自管 PostgreSQL。

交付形態遷出的通用框架（資產線盤點、並行期設計、回切窗口）見 託管形態遷出。

外包深度對照

用 外包深度 的三層框架（managed 基礎設施 / feature SaaS / BaaS bundle）看四條路徑：

路徑 B 在外包深度上介於 managed 基礎設施和 BaaS bundle 之間 — DB 和 runtime 交給平台，但 collector 邏輯和 schema 仍由開發者控制。這和 BaaS 的「前端 SDK 直連平台資料庫」模式不同 — 監控場景的路徑 B 仍然有一個自己寫的中間層（serverless function），只是這個中間層跑在平台上而非自己的 server。

選擇建議

APP 上線初期選 B 或 A 取決於自訂需求 — 需要自訂 schema 和查詢邏輯（例如自定義 error fingerprint、行為事件命名規範）選 B，只需要開箱即用的 error tracking 或行為分析選 A。B 保留遷到自架的彈性（資料在自己的 PostgreSQL），A 的功能完成度更高（dashboard、告警、session replay 開箱即用）。

下一步路由

• 自架 vs 商業的詳細決策 → 自架 vs 商業的判斷決策表
• 自架 collector 的完整設計 → 模組四 Collector 設計
• Backend 交付形態光譜 → 交付形態選型
• 能力級買 vs 建判斷 → 能力級買 vs 建
• 外包深度概念 → 外包深度
• BaaS 概念 → BaaS
• 遷出劇本 → 託管形態遷出
• Vendor lock-in 概念 → Vendor Lock-In

自架 log endpoint 的適用場景

自架 log endpoint 適合的前提是：client 和 server 在同一個網路內（同機、同 LAN、同 VPN/tailnet），log 的唯一消費者是開發者本人。

app_tunnel 就是這個場景。Server（ttyd）和 client（Flutter app）在同一台機器或同一個 Tailscale tailnet 內。開發者同時是使用者和維運者。Log 的消費方式是 grep — 不需要 dashboard、不需要告警、不需要多人共享。

在這個場景下，自架 log endpoint 的成本遠低於商業方案。一個 Go 程式開 HTTP endpoint 接收 JSON log 寫入檔案，20 行程式碼就能完成。Client 端的 AppLogger 在 debug mode 同時寫 console 和 POST 到 endpoint。Debug 時用 grep + jq 查詢，不需要額外工具。

1Client (Flutter) → HTTP POST /log → Go receiver → JSON file → grep/jq

這個方案沒有外部依賴、沒有帳號管理、沒有費用、沒有資料隱私顧慮（log 不離開本機網路）。

商業方案的適用場景

商業方案（Sentry、Crashlytics、Datadog）適合的前提是：使用者分佈在外部網路，log 的消費者包含非開發者（維運、客服、產品），且需要告警和趨勢分析。

商業方案提供的能力包括：跨網路收集（SDK 自動處理網路不穩定和批次傳輸）、多人查看 dashboard、告警規則設定、crash 報告自動分群、用戶 session 重播。這些能力在自用工具場景下不需要，在商業產品場景下是基礎需求。

商業方案的成本包括：SDK 整合和設定、帳號和權限管理、月費（依事件量計費）、資料隱私合規（log 傳到第三方伺服器）。

判斷流程

使用者在哪裡

使用者和 server 在同一個網路內（自用工具、內部工具、開發期測試）→ 自架 log endpoint 是成本最低的選擇。

使用者在外部網路（上架 app store、SaaS 產品、B2B 部署）→ 商業方案的跨網路收集能力是必要的，自架需要處理的 edge case（離線緩衝、重試、批次傳輸）太多。

Log 消費者是誰

只有開發者自己 → grep/jq 足夠，不需要 dashboard。

包含非技術人員（客服、產品經理）→ 需要視覺化 dashboard 和搜尋介面，商業方案的 UI 是這個需求的標準答案。

是否需要告警

開發者自己用、即時看 log → 不需要告警。

有維運值班、需要被動發現問題 → 需要告警規則，商業方案內建。

混合方案

開發期用自架 log endpoint（零成本、即時可用），production 切換到商業方案 — 這個策略可行的前提是 log 層的 API 設計足夠抽象。

AppLogger 提供統一的 log 介面（log(level, name, data)），底層實作在 debug mode 寫 console + POST 到本機 endpoint，在 release mode 寫 console + 呼叫 Sentry/Crashlytics SDK。切換只改 AppLogger 的底層實作，不改呼叫端。

這個抽象的投資在自用工具階段就值得做 — 即使目前不需要商業方案，統一的 log 介面也讓 log 點的管理更一致。

下一步路由

• 三層 log 的詳細設計 → 三層 log 設計
• 在功能規格中定義 log 點 → 功能規格中的 log 點定義方法
• Log 收集後的 schema 設計 → monitoring 模組二 Log Schema

服務定位

Keycloak 是 自管控制面 的 human identity 與 federation engine、不是 cloud resource permission engine。跟 Okta / Auth0 的本質差異在於信任邊界落點：SaaS IdP 把 signing key、tenant 隔離、support workflow 都託管出去、客戶承擔「供應商出事我也跟著被打」的風險；Keycloak 把整條控制面收回自家機房或自家 VPC、客戶承擔「signing key 過期 / DB 崩 / Java app CVE 沒跟上」的運維風險。

跟 cloud-native SSO（AWS IAM Identity Center）相比、Keycloak 的核心優勢是 不綁雲廠 + 可深度客製 authentication flow + 資料不出境。適合垂直：金融、政府、醫療某些不接受 SaaS IdP 的場景；以及預算敏感、員工數中等、SRE 量能足以接 24/7 on-call 的組織。

本章目標

讀完本頁、讀者能判斷：

1. Keycloak 該承擔哪一段 identity 控制（SSO / MFA / federation / brokering）、哪一段該交給雲端 IAM 或下游應用
2. 自管 IdP 的最低運維基線（HA、DB DR、cert / signing key rotation、CVE cadence、SIEM 接點）
3. Realm / Client / User Federation / Identity Broker / Authentication Flow / SPI 各自的決策時機與陷阱
4. 何時用 Keycloak、何時改走 SaaS（Okta / Auth0）或其他 OSS（Authentik / Zitadel）

最短判讀路徑

判斷 Keycloak 部署是否健康、最少看 SaaS IdP 的四件事加上自管特有的四個維度：

• 誰能做什麼：master realm admin 的人數、是否走 access request workflow、admin console 是否限 IP / device trust、是否強制 phishing-resistant 認證
• 憑證在哪裡：client secret 是否走 secret management、realm signing key 的 rotation 排程、admin token 的 TTL
• 入口如何暴露：哪些 realm 對外、reverse proxy / Ingress 是否做 rate limit、admin console（/auth/admin）是否限內網或 zero trust
• 證據是否可回查：Event Listener SPI 是否接 SIEM、admin event 跟 login event 是否分流、保留期是否符合稽核
• DB 健康：PostgreSQL / MySQL 是否跨 AZ、是否有 PITR、是否做過 restore 演練（不是只有備份成功訊息）
• Cert lifecycle：TLS cert 與 realm signing key 各自的 rotation 排程、是否走 Website Certificate Lifecycle 自動化
• HA topology：Keycloak cluster 是否多節點、Infinispan cache 是否跨 AZ、單節點重啟是否會踢掉所有 session
• Upgrade cadence：Keycloak 每年 major release、CVE patch 是否能在 SLA 內上、是否有 staging 跑 DB migration

八個維度任一缺失、都是自管 IdP 常見事故的入口。

日常操作與決策形狀

Realm 設計：Realm 是 Keycloak 的隔離邊界、每個 realm 有獨立的 user store、client、role、signing key。multi-tenancy 走 realm 是正確選擇、但 master realm 能管所有 realm、master realm 的 admin compromise = 全公司 IdP compromise。把 master realm 鎖在內網、operational realm 才對外、是基本姿勢。

Client 註冊與 secret：每個應用是一個 client、confidential client 有 secret、public client（SPA / mobile）走 PKCE 不存 secret。client secret 不存 source code、走 secret management 注入。client 數量爆炸時要設 naming convention 跟 ownership 標記、不然 stale client 會堆積。

User Federation：把既有 LDAP / Active Directory 接進 Keycloak、user 還是住在原 directory、Keycloak 做 protocol 翻譯（LDAP → OIDC / SAML）。這是 Keycloak 強項之一 — 不需要 user migration、漸進接入。陷阱是 LDAP 連線健康 = IdP 健康、LDAP 慢 = 全公司 login 慢。

Identity Brokering：把外部 IdP（Google、Microsoft、其他 SAML / OIDC provider）federate 進來、Keycloak 當中介。B2B 合作常見模式 — partner 用自己的 IdP、不在我的 user store 開帳號。決策點是 trust mapping：外部 claim 怎麼對應到內部 role、外部 IdP 的 MFA 狀態怎麼信任。

Authentication Flow：Keycloak 把 login / registration / reset password 做成可編輯的 flow DAG、可以插入自訂 step。這是 Keycloak 跟 SaaS IdP 最大差異點之一 — 想要 step-up MFA、device fingerprint、risk-based 判斷都可以自己接。雙面刃是 自訂 flow 容易留漏洞：跳過必要步驟、condition 寫錯讓 MFA 變可選、custom Authenticator SPI 沒處理 race condition。

Theme / 客製 UI：Keycloak 支援 theme override、可以改 login page HTML / CSS / JS。custom JS 在 login page = 自己注入 XSS 風險 — theme 寫進去之後就是 IdP 本體的攻擊面、不是普通網頁。CSP 跟 input sanitization 要當成 IdP 安全規範看待。

Event Listener / Audit：Keycloak 預設只把 event 寫進 DB、UI 上能查、但 不會自動推到外部 SIEM。生產環境必須接 Event Listener SPI（內建 jboss-logging、或自寫 Kafka / file listener）把 admin event 跟 login event 推進 SIEM。沒接的話 audit trail 只在 IdP 本機、IdP 出事就拿不到 evidence。

Exception / break-glass：master realm 留至少 2 個 break-glass admin、credential 離線存、走獨立 MFA（hardware key）。Keycloak cluster 整個失聯時、用 break-glass 直連 DB / 直連單一節點救回。

核心取捨表

選 Keycloak 的核心訴求：資料主權 + 預算控制 + 客製 flow 需求、且有 SRE 團隊能 24/7 on-call、能接受自管的運維重量。團隊小於 50 人沒 SRE 量能、應用主要在 SaaS（pre-built integration 用不上 Keycloak 強項）、需要快速接 7000+ SaaS app — 都該回頭看 Okta / Auth0。

進階主題

User Federation 跟 LDAP 整合：企業環境常見「Active Directory 是 user source of truth、Keycloak 做 protocol 層」。注意 LDAP 同步策略（read-only / writable / import）、LDAP 健康直接影響 IdP 可用性、LDAP timeout 要設嚴格避免 login 卡住整個 cluster。

Identity Brokering 跟外部 IdP：把 Google / Microsoft / 其他 SAML IdP federate 進來、外部 user 進來時 Keycloak 自動建 link。trust mapping 是關鍵 — 外部 IdP 宣稱「這個 user 已 MFA」、要不要信？外部 group claim 怎麼對應到內部 role？沒有預設答案、要用 authorization 邊界決定。

Fine-Grained Authorization（UMA / Authorization Services）：Keycloak 內建 policy engine、可以做 resource-level 授權（不只是 role-based）。適合需要中央化 policy decision 的場景、但會把應用的授權邏輯綁進 Keycloak、退場成本變高。多數場景應該把 authorization 留在應用內、Keycloak 只做 authentication + role token 發行。

Custom Authenticator SPI：用 Java 寫自訂 authenticator、插進 Authentication Flow。能做 step-up MFA、device posture、risk score 判斷。陷阱是 SPI 程式碼就是 IdP 本體的一部分、bug = IdP 漏洞、必須走完整 code review + 安全測試流程、不能當普通 feature 開發。

Realm signing key rotation：每個 realm 有自己的 RSA / EC signing key、用來簽 ID token / SAML assertion。rotation 必須跟下游 client 協調（key rollover 期間 client 要能接受新舊 key）、否則 rotation 當天全公司 login 失敗。分域分批是必做的、參考 Failure: Credential Rotation Without Scope。

排錯與失敗快速判讀

• DB 是 SPOF：Keycloak 所有 state 在 PostgreSQL / MySQL、DB 出事 = IdP 停 = 全公司 SSO 停。跨 AZ replication + PITR + 季度 restore 演練、不是 nice-to-have
• Cert / signing key 過期：自管 IdP 最常見事故、TLS cert 過期擋對外 endpoint、realm signing key 過期讓所有 token 變無效。走 Certificate Rotation 自動化、過期前 30 天 alert
• Cluster split-brain：Infinispan cache 跨節點同步、網路分區時 session 狀態不一致、user 看起來登入但下一個 request 又被踢出。HA topology 設計要考慮 cache mode（distributed vs replicated）、network 健康監控要 alert split-brain
• Major upgrade 卡 DB migration：每年 major release 帶 schema migration、staging 沒跑過就 production 升級 = 數小時 downtime。upgrade plan 包含 rollback DB snapshot + staging full rehearsal
• Custom theme / Authenticator 留漏洞：theme JS 引入 XSS、custom Authenticator 跳過 MFA、SPI 沒處理 race condition。把 IdP 客製當成 supply chain 看待、走 code review + 安全測試
• Event 沒進 SIEM：預設只在 Keycloak DB、IdP 出事就拿不到 evidence。Event Listener SPI 接 Kafka / file / SIEM、admin event 跟 login event 各自接 alert runbook
• Master realm admin 過多：日常工作不該用 master realm admin、應該在 operational realm 開有限權限 admin。master realm 是 single point of compromise

何時改走其他服務

不在本頁內的主題

• Keycloak 完整 SAML / OIDC 規格細節、SPI Java API 文件
• Red Hat build of Keycloak 商業支援的差異與授權細節
• Keycloak Operator（Kubernetes deployment）的逐步部署教學
• LDAP / Active Directory 各種 schema 對應規格

案例回寫

Keycloak 沒有直接的廠商級公開事件（OSS 沒有 vendor incident 的對應形態）、自管 IdP 的失效模式以下分兩類整理：跨 vendor 共通的 同構失效 用既有 case 對照、自管 IdP 特有 的失效情境補敘事說明、避免案例表變成「同一個 frame 拼四個 case slug」。

對照引用（跨 vendor 同構失效）：

自管 IdP 特有的失效情境（沒有對應公開 vendor case、來自自管運維常見事故樣態）：

• Cert 過期讓全公司 SSO 卡死：Keycloak signing cert / TLS cert / 後端 DB cert 都自己管、任何一張過期 = login 全停。Okta / Auth0 客戶不會遇到這個失效面（vendor 自己 rotate）— 自管組織必須有 cert lifecycle monitoring（Prometheus exporter + alert）+ 季度 rotate rehearsal、不能等 Let’s Encrypt / 公司 PKI 發過期通知才動
• Major upgrade 卡 DB migration 變數小時 downtime：Keycloak 每年 major release 帶 schema migration、若 staging 沒 full rehearsal 就 production 升級、可能遇到 migration 比預期慢 5-10 倍、整個維護視窗炸掉。對照 Okta / Auth0：vendor 自己升、客戶感知是 minutes-level、不是 hours-level
• Realm scope 在小規模時用法跟大規模衝突：Contrast: Identity Governance by Scale 揭示不同規模治理模式差異 — 小團隊用單一 realm 順、團隊長大後該拆 realm 卻沒拆、最後 admin compromise blast radius 變整個組織。Keycloak 比 SaaS IdP 更容易踩到、因為 realm 拆分要自己決定時機、沒 vendor 推使用者升級 tier
• DB 是 SPOF、自管沒做好 = SSO 跟 DB 一起死：Keycloak 用 PostgreSQL / MySQL 存 user / session / signing key、DB 出事 = IdP 停。跨 AZ HA + 跨 region DR + 季度 failover 演練是硬性要求、不是 nice-to-have；SaaS IdP 客戶不會遇到這個層次的失效面

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Okta vendor、Auth0 vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM / Azure RBAC（Keycloak 之後的 cloud resource permission 層）
• 跨模組：8 事故處理 vendor 清單（自管 IdP 事件如何 routing 進 IR 流程）
• 官方：Keycloak Documentation

斷網環境裡這些服務全部要自建。每一個 SaaS 變成一個內部服務，infra 團隊承擔它的部署、設定、升級、備份、監控和使用者管理。這篇文章盤點完整的服務清單、推薦的自建工具、部署順序，以及容易被低估的維護成本。

服務清單與選型

「部署複雜度」指首次部署到可用狀態的工程量。「維護頻率」指部署完成後的持續性工作——安全更新、容量擴充、故障排查。

各服務的選型判斷

版本控制：GitLab CE 功能完整（含 CI/CD、container registry、package registry），但資源消耗大（建議 4 核 / 8GB 以上）。Gitea 輕量（512MB 記憶體可跑），適合小團隊或只需要 Git hosting 的情境。如果選 GitLab CE，版控 + CI/CD + registry 可以用同一個實例，減少部署數量。

CI/CD：如果已部署 GitLab CE，內建的 GitLab CI 是最低成本的選擇——Runner 裝在同一網段的機器上即可。Jenkins 的生態更大（plugin 多），但 plugin 的離線安裝和更新需要額外的搬運流程。

套件 registry：Nexus Repository 是斷網環境的首選，因為它用一個實例同時支援 apt / yum / npm / Maven / PyPI / Docker / Helm——維護一個服務取代六個獨立的離線 repo mirror。Artifactory 是商業替代品，功能相似但需要授權費。

容器 registry：Harbor 提供映像掃描（整合 Trivy）、RBAC、複寫、稽核 log。如果只需要儲存和拉取映像、不需要掃描和稽核，Docker Registry（開源）足夠。

內部 CA：step-ca 支援 ACME 協定（跟 Let’s Encrypt 相同的自動簽發流程），內部服務可以用跟外部一樣的 certbot 工具自動續期。cfssl 是更輕量的選擇但沒有 ACME 支援、需要手動或腳本續期。

內部 DNS：CoreDNS 用設定檔驅動、輕量、適合 Kubernetes 環境。BIND 是傳統選擇、功能完整但設定複雜。多數斷網環境的 DNS 需求簡單（幾十筆 A record），CoreDNS 的 file plugin 足夠。

時間同步：chrony 是 NTP 的現代替代——啟動快、適應性強、低資源。內網裡指定一台機器當 NTP server（stratum 1 如果有 GPS 時鐘、stratum 2 如果手動校時），其他機器指向它。時間不同步會讓 log correlation 失效、TLS 憑證驗證失敗、Kerberos 認證拒絕。

監控：Prometheus（metric 收集）+ Grafana（視覺化）+ Loki（log 聚合）是最常見的 self-hosted 監控組合。三者都支援離線部署、不需要外部依賴。詳見斷網環境的監控與可觀測性。

機密管理：HashiCorp Vault 提供 secret 儲存、動態 secret 產生、PKI、加密即服務。部署和維護複雜度高——Vault 本身需要 unseal、HA 需要 Raft 或 Consul 後端、稽核 log 需要儲存規劃。如果機密數量少且變更不頻繁，加密的 ansible-vault 或 git-crypt 是輕量替代。

IaC state 後端：PostgreSQL 是 Terraform 支援的 state backend 之一（backend "pg"），斷網環境裡用既有的 PostgreSQL 實例存 state、用 PostgreSQL 的 advisory lock 防並行。比自建 S3 + DynamoDB 簡單得多。Consul 是另一個選擇（Terraform 原生支援），但引入 Consul 只為了存 state 的 ROI 通常不划算、除非環境裡已經有 Consul 跑 service discovery。

部署順序

服務之間有依賴關係，部署順序由依賴方向決定：

 1第一層（基礎設施服務）
 2  DNS → 所有服務都需要名稱解析
 3  NTP → 所有服務都需要時間同步
 4  CA  → 所有服務都需要 TLS 憑證
 5
 6第二層（開發平台服務）
 7  版本控制 → 程式碼要有地方存才能跑 CI
 8  套件 + 容器 registry → build 需要依賴
 9
10第三層（自動化服務）
11  CI/CD → 依賴版控 + registry
12  IaC state backend → Terraform 需要 state 存放處
13
14第四層（營運服務）
15  機密管理 → 其他服務的 secret 集中管理
16  監控 → 監控所有上述服務的健康

第一層的三個服務可以平行部署——它們彼此不依賴。第四層的監控放最後是因為它要監控的對象都還沒就位時、設定 target 沒有意義。

每一層部署完成後做一次整體驗證（所有服務能互相連通、TLS 正常、時間同步），再進下一層。

統一管理 vs 個別部署

GitLab CE 把版控、CI/CD、container registry、package registry 打包在一個實例裡。用 GitLab CE 取代四個獨立服務的優缺點：

小團隊（5-15 人）的斷網環境，GitLab CE 統一管理的 ROI 通常較高——維護一個服務比維護四個省力，故障半徑的風險靠備份和 HA（GitLab 支援 Geo replication）緩解。

大團隊或高安全環境，個別部署的隔離性較好——CI runner 跟版控分開、registry 跟 CI 分開，每個服務的存取控制和稽核獨立。

同樣的邏輯適用於 Nexus：它用一個實例服務 6 種格式的套件，比為每種格式各建一個離線 mirror 省力。

維護的隱藏成本

自建服務的維護成本容易被低估，因為部署完成時感覺「已經做完了」，但持續性維護才剛開始。每個自建服務需要：

10 個自建服務各自都有這六項維護需求。時程參考：每月的例行維護（安全更新 + 備份驗證 + 容量檢查）約需 2-3 天工程師時間。這筆時間是隱性的——不在任何 sprint 或 ticket 裡，但不做的後果是累積的。

管理層溝通時的關鍵數字：自建 10 個服務的維護成本約等於 0.3-0.5 個全職工程師。這筆人力投入是斷網環境的結構性成本，跟應用開發無關。

跨分類引用

• → 斷網環境的通用原則：內容搬運、離線套件管理的共通模式
• → 斷網環境的 IaC：state backend（PostgreSQL）和 CI 的詳細設定
• → 斷網環境的容器與映像管理：Harbor 和映像搬運的詳細操作
• → 斷網環境的監控與可觀測性：Prometheus + Grafana + Loki 的部署
• → 模組二：身分與憑證地基：Vault 的身分管理與 infra IAM 的關係
• → 模組八：治理好習慣：自建服務的 secret 管理與成本歸因

定義 funnel 步驟

Funnel 分析的第一步是列出每一步和對應的事件名稱。以一個透過 WebSocket 連接遠端終端機的 app 連線流程為例：

SQLite 層：每步事件計數

SQLite backend 能做的 funnel 是「每步有多少事件觸發」— 單表 GROUP BY，不需要跨事件 JOIN。

1SELECT name, COUNT(*) as count
2FROM events
3WHERE name IN ('terminal.connect.start', 'auth.biometric.success',
4               'terminal.connect.done', 'terminal.input.submit')
5  AND ts >= datetime('now', '-7 days')
6GROUP BY name;

步驟 N 的轉換率 = 步驟 N 的事件數 / 步驟 N-1 的事件數。流失率 = 1 - 轉換率。

能做的

• 每步事件計數（單表 GROUP BY）
• 按 source.version 或 source.platform 分群（加 WHERE 條件）
• 按天/按週看趨勢（strftime 分桶 + GROUP BY）

做不到的

• Session 級轉換率：「同一個 session 完成步驟 1 到步驟 4 的比例」需要 JOIN 同 session 的多個事件、跨所有 session 聚合。SQLite 能做這個 JOIN，但在大量 session 時效能不足。
• 步驟間耗時：「使用者在步驟 1 和步驟 2 之間等了多久」需要 self-join on session_id + timestamp 差值計算。
• 漏斗順序驗證：確認使用者是按 1→2→3→4 順序完成、不是跳步。

PostgreSQL 層：Session 級 funnel

PostgreSQL backend 提供 window function 和高效 JOIN，能做完整的 session 級 funnel 分析。

 1WITH session_steps AS (
 2  SELECT session_id, name,
 3         ROW_NUMBER() OVER (PARTITION BY session_id ORDER BY ts) as step_order
 4  FROM events
 5  WHERE name IN ('terminal.connect.start', 'auth.biometric.success',
 6                 'terminal.connect.done', 'terminal.input.submit')
 7    AND ts >= NOW() - INTERVAL '7 days'
 8),
 9session_max_step AS (
10  SELECT session_id, MAX(step_order) as reached
11  FROM session_steps
12  GROUP BY session_id
13)
14SELECT reached, COUNT(*) as sessions
15FROM session_max_step
16GROUP BY reached
17ORDER BY reached;

新增能力

• Session 級轉換率：每個 session 到達了哪一步、在哪一步流失
• 步驟間耗時：LAG window function 計算相鄰步驟的 timestamp 差值
• 漏斗順序驗證：用 ROW_NUMBER + CASE 確認步驟順序
• Cohort 分群的 funnel：按使用者註冊日期 / 版本 / 平台分群看不同 cohort 的 funnel 差異

JSONL 匯出後的臨時分析

Collector 的 monitor export --format=jsonl 可以匯出事件為 JSONL 格式。匯出後用 grep + jq 做一次性的臨時分析：

1for step in terminal.connect.start auth.biometric.success terminal.connect.done terminal.input.submit; do
2  count=$(grep "\"name\":\"$step\"" exported-events.jsonl | wc -l)
3  echo "$step: $count"
4done

JSONL 臨時分析適合「快速看一眼大概數字」的場景。持續性的 funnel 監控應該用 SQLite 或 PostgreSQL 的 SQL 查詢，結果穩定且可重現。

自架 vs 商業方案

自用工具場景下，SQLite 層的每步事件計數通常足夠。商業產品需要 session 級分析時，PostgreSQL 層的 SQL 能力和商業方案的分析能力在功能上對等，差異在 UI 和設定便利性。

下一步路由

• Funnel 分析的完整方法論 → Funnel analysis
• 事件設計如何影響分析品質 → 行為事件設計
• 功能分層定義 → 功能分層與 Backend 選擇
• 去識別化是分析的入場條件 → 模組七 資安與隱私