對於許多開發者來說，處理權限控制（Authorization 通常會從簡單的 if-else 判斷開始。但當公司規模擴大、權限情境變得複雜時，這種做法會演變成難以維護的技術債。HubSpot 最近分享了他們如何將 Just-In-Time Access（JITA，即時存取權限）系統從傳統的條件邏輯重構為規則引擎架構，這對於需要處理複雜權限審核的工程團隊具有很高的參考價值。
什麼是 JITA 權限管理
在安全性要求較高的環境中，工程師不應該永久擁有生產環境的高權限，因為這會增加安全風險。JITA 是一種權限管理模式，要求使用者在需要操作時才申請臨時權限，審核通過後授予短時間的存取權能，到期後自動回收。HubSpot 的系統每天需處理約 5,500 次請求，服務對象約一萬名員工。
傳統條件邏輯的痛點
在舊系統中，HubSpot 使用的是嵌入在程式碼中的條件邏輯（Conditional Logic）。隨著業務需求增加，判斷權限的 if-else 巢狀結構變得極其複雜。這導致了兩個核心問題：第一是缺乏可解釋性，當一個請求被拒絕時，工程師很難快速找出究竟是哪一條規則導致的；第二是效能黑洞，無法精確得知是哪個判斷環節導致了請求延遲。
規則引擎與 DAG 架構的引入
為了解決上述問題，HubSpot 引入了規則引擎（Rule Engine）架構。他們將權限判斷邏輯從主程式中抽離，轉化為獨立的規則集。這些規則透過有向無環圖（Directed Acyclic Graph, DAG）來組織。
所謂的 DAG 是一種圖形結構，確保規則的執行順序有明確的方向且不會陷入無限循環。透過 DAG，系統可以定義規則之間的依賴關係，甚至讓不相干的規則並行執行，大幅提升處理效率。
上下文對象與數據解耦
為了避免每個規則都重複去資料庫查詢使用者資訊，HubSpot 設計了一個共同的上下文對象（Common Context Object）。系統在執行規則前，會先統一收集使用者屬性、團隊資訊與請求細節，將其封裝在一個對象中傳遞給各個規則。這種做法將數據獲取與邏輯判定解耦，確保所有規則在同一套一致的數據基礎上做決定。
提升權限決策的可觀測性
這次重構的核心目標不是功能增加，而是可觀測性（Observability）。在新的架構下，每一條規則的執行結果不再僅僅是一個布林值（True/False），而是一個結構化的輸出，包含執行結果、耗時以及相關元數據（Metadata）。
這意味著當權限審核發生時，管理員可以清楚地看到：規則 A 判定通過（耗時 10ms），規則 B 判定失敗（耗時 200ms）。這樣不僅能快速定位權限被拒的原因，還能精確找出導致系統緩慢的性能瓶頸。
容錯處理與遷移策略
在分散式的權限檢查中，如果某個依賴的服務暫時不可用，不應該導致整個權限系統崩潰。HubSpot 採用了隔離執行機制，若單一規則執行出錯，系統會記錄該錯誤但允許其他規則繼續運行，確保系統的可用性。
在切換新舊系統時，他們採取了並行運行（Parallel Running）的策略。新舊系統同時接收請求並比對結果，直到確認新系統的判定邏輯與舊系統完全一致且更穩定後，才正式將流量切換至新架構。
業界類似方案的比較
雖然 HubSpot 的實現方式偏向應用特定的工作流，但業界也有其他成熟的權限管理方案。例如 Open Policy Agent (OPA) 提倡策略即代碼（Policy-as-Code），將權限邏輯完全分離到獨立的引擎中；而 Google Cloud 的 Privileged Access Manager 或 Microsoft Entra PIM 則更側重於雲端基礎設施的特權角色激活與審計追蹤。
總結
HubSpot 的這次重構給工程師的啟示是：當邏輯複雜度達到臨界點時，將條件判斷轉化為可配置、可觀測的規則引擎，能將權限管理從單純的 程式碼執行 提升到 可治理的系統 階段。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。