Index 加了卻沒生效？資料庫在尖峰時刻無預警卡頓？

資料量成長後，單純的 SQL 優化已不足以應對複雜的效能瓶頸。理解 PostgreSQL 的 MVCC 機制、Index 結構（B-Tree, GIN, GiST）與底層資源分配，是確保系統在高併發環境下穩定運行的關鍵。

本活動將拆解 EXPLAIN ANALYZE 診斷邏輯，並透過 pg_stat_statements 與 pg_stat_activity 建立精準監控體系，幫助開發者定位慢查詢、排除資源競爭，實現系統性能的極致化！

活動資訊

日期：2026.6.10 (三) 11:00 – 12:00

形式：線上

活動亮點

 Index 調優實踐： 掌握複合索引與部分索引，避開 Index Bloat。
 執行計畫剖析： 透過診斷工具，精準定位 Seq Scan 與效能瓶頸。
 資源監控技巧： 活用 pg_stat 系統表，即時偵測併發衝突與 I/O 異常。

我們誠摯邀請您，一同深入學習 Postgresql 最新技術，掌握職場競爭力！

 活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！

若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

限時抽獎

於 2026/6/5 前到歐立威科技臉書指定貼文參加【開源隨堂考】，就有機會將 精美 EDB 周邊 帶回家！
*** 一人限抽一次 ***

這項更新不僅簡化了開發者在佈署 AI 應用時的身分對接流程，更讓企業能在確保資安合規的前提下，快速將 AI Agent 納入現有的自動化維運體系中。

為什麼 AI Agent 需要全新的授權模式？

傳統的 IAM 是為了「可預測」的使用者與工作流所設計。然而，AI Agent 具備自主性與非預定性的行為特性，這與過往的授權邏輯完全不同。

AI Agent 不只需要單純的存取控制，更需要一套能將身分、委任、即時策略評估與短效授權結合的全新模型。權限必須是暫時性的，且嚴格限制在特定請求的交易情境中，一旦任務結束便隨即失效。

圖 1：傳統 IAM 權限範圍過大且效期過長；若 AI Agent 缺乏明確身分，將導致資安風險。

企業在導入 AI Agent 時，急需針對自動化系統設計的身分識別與安全控管，重點包含：

• 設立行為護欄 (Guardrails)：針對行為預測性較低（對比人類或傳統非人身分）的 Agent 強化控管。
• 即時精細授權：支援在執行期間即時評估，並將權限嚴格限制在單一動作或工作流。
• 行為溯源與審核：完整記錄 Agent 代表使用者執行任務的歷程，確保審核合規。
• 跨環境標準化：在不同環境與工作流中，建立一致的 AI Agent 安全管理框架。

針對 AI Agent 的運作特性，Vault 推出專為 AI 工作流設計的新功能，包含 Agent 註冊表、精細化身分策略，以及單次請求授權 (Ephemeral Authorization)。這種機制僅在特定任務期間給予臨時權限，任務結束即失效，能有效降低資安風險。

目前已有部分客戶透過早期測試計畫進行評估，預計今年夏季將開放公開測試。

Agent 身分識別：Vault 註冊表中的新核心組件

透過 Agent 註冊表，開發者可將 AI Agent 的活動與人類或傳統非人身分 (NHI) 分開管理。這種專屬的監管機制在「委任流程」中至關重要，特別是當 Agent 取得使用者同意、以其名義 (On-behalf-of) 執行任務時。

Agent 註冊表能確保這些委任行為被明確追蹤，並以此建立一套專門針對 AI Agent 的註冊、授權、憑證管理與觀測化框架。

AI Agent 身分策略與權限規範

「最小權限原則」是企業的首要目標，對於 AI Agent 更是如此。Vault 透過豐富的原則（Policy）與執行期間（Runtime）控管，讓管理者能嚴格規範 Agent 的活動。

由於 AI Agent 的行為具有非預定性，Vault 採用預定性護欄 (Deterministic Guardrails) 與單次請求存取控制進行防護。

此外，當 Agent 以委任模式執行任務（即具備使用者的授權）並存取機密資訊時，Vault 會進行多維度的信任評估，確保操作安全性。

圖 2：授權行為取決於使用者、AI Agent 與權限上限的交集，並結合單次請求授權細節。

在此模型中，授權邏輯由三層策略的交集決定：使用者（Human Owner）策略、Agent 基礎存取策略，以及一組覆蓋式的權限上限策略 (Ceiling Policies)。

權限上限策略專用於委任流程，旨在建立絕對的爆炸半徑 (Blast Radius)。它定義了 Agent 在代理使用者時所能擁有的最高權限邊界，確保其權限不會超出預設範圍。如同文氏圖的邏輯，一項操作必須同時存在於這三層策略的交集內，才會獲得授權執行。

臨時授權：限制單次請求存取權限

策略交集定義了 Agent 的最大權限範圍。此外，Vault 支援單次請求授權，透過在授權 Token（基於 OAuth 2.0 RAR 規範）中嵌入交易情境，配合上限策略，嚴格控管每次請求核發的憑證權限，避免過度授權風險。

為執行臨時授權，授權伺服器會在 JWT Body 的 authorization_details 聲明中指定權限集。這將權限與 Token 生命週期（而非 Agent 身分）綁定，一旦 Token 過期，Agent 即失去操作權限。

相較於僅依賴實體策略，這種方式能提供更高安全性的資源控管。Vault 不再核發廣義的長期權限，而是針對特定請求或工作流進行即時評估。

以下範例展示如何透過 JWT 聲明，授權存取 Vault KV Mount 中名為 secrets 的特定機密：

"authorization_details": [
  {
    "action": "read",
    "path_constraint": "secrets/my-secret",
    "type": "vault:path_access"
  }
],

圖 3：Vault 採用臨時性的單次請求授權，依需求限制 AI Agent 的存取權限。

Vault 可直接評估授權 Token 內具備防篡改特性的「單次請求授權細節」。這代表權限範圍能被限制在單一請求或工作流中，而非開放所有可能的路徑。

由於此模型不再需要額外的 Token 交換流程，能有效降低維運複雜度，並簡化對 Agent 行為的追蹤。

總結

當 AI Agent 進入生產系統，靜態機密與廣義 API Token 已不足以支撐資安需求。企業需要的是針對自動化系統設計的運行時身分、受限委任與授權模型。

Vault 的 AI Agent 身分識別功能確保了每一項操作皆可溯源、可審核，並受即時政策規範。這讓 Vault 的角色從機密管理，延伸至自動化系統的運行時信任控管。

目前 AI Agent 原生支援已開放部分客戶進行早期測試，預計今年將進入公開測試階段，敬請關注後續版本更新。

本文翻譯自：Announcing native AI agent support in HashiCorp Vault

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

SSL 憑證有效期已正式縮短至 200 天，未來只會更短 —— 你的憑證管理流程準備好了嗎？

Google 等國際大廠推動 SSL 憑證有效期持續縮短，讓企業面臨「更頻繁、更高風險」的換證壓力。在雲端與微服務架構下，只要一張憑證漏換，就可能導致服務中斷、交易失敗，甚至造成品牌信任與營收損失。

本活動將聚焦分享，如何透過 IBM HashiCorp Vault 將憑證管理自動化，以「系統自動執行」取代高風險的人工操作，協助企業大幅降低維運負擔，穩定服務不中斷！

活動資訊

日期：2026.06.04 (四) 11:00 – 12:00

形式：線上

活動亮點

• 自動化續約： 從核發到續約全程自動化，徹底擺脫人工換證與疏漏風險
• 全局化控管： 集中管理所有憑證生命週期，消除維運盲點
• 零風險部署： 建立自動化閉環機制，確保憑證在期限內完成續約

 活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！

若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

參加好禮

活動報名通過，會後填寫問卷即可領取學習簡報！

The Elasticsearch Platform

Elastic 9.4 重點更新

Elastic 9.4 的更新展現了其作為 AI 「上下文（Context）與檢索層」的核心地位，主要包含：

Agent Builder 功能擴展

新增多種控制元件，優化 Agents 獲取並運用上下文的效率。新支援包含 Skills、Attachments、Connectors 與 Plugins ，讓 Agent 的行動更精準。

原生支援 Prometheus 與 PromQL

結合 Elasticsearch TSDB 效能優化（效能優於 Prometheus 2.6 倍）以及 ES|QL 時間序列功能正式上線 (GA)。Elastic 提供了一套能完全替代 Prometheus 與 Grafana 的整合方案，將日誌分析與指標（Metrics）整合在單一平台，加速故障排除。

Elastic Workflows 正式上線

Workflows 結合自動化腳本與 AI 代理推理能力。對於 Elastic Security 用戶，這意味著原生自動化能直接處理資料的分流、富化（Enrichment）、響應與案件管理，無需切換平台。

資安實體分析（Entity Analytics）進化

新增四項核心能力：精確分析實體識別、實體關聯、動態監控名單以及實體驅動偵測。讓分析師能獲得單一且權威的個人紀錄，整合風險等級與組織脈絡，同時提供 AI 代理更準確的背景資訊進行判斷。

底層架構與效能提升

• DiskBBQ 演算法： 優化向量索引與搜尋效能
• GPU 加速索引 (GA)： 由 NVIDIA cuVS 驅動，索引吞吐量最高提升 12 倍
• 無 Schema 查詢： ES|QL 現在可直接對未定義 Mapping 的欄位進行查詢、篩選與聚合
• 合規性提升： Elasticsearch 與 Kibana 全面符合 FIPS 140-3 標準

Elasticsearch 平臺

在最新版本中，Elasticsearch 平台在自動化編排、查詢語言、AI 原生體驗及企業合規四大維度均有顯著提升。

自動化與編排：

Elastic Workflows 已正式上線。Workflows 是連結 Elastic 與外部營運系統的自動化層。它能觸發外部系統動作、協調多步驟流程，並將「平台偵測」到「實際執行」的閉環自動化。

• 與 Agent Builder 協作： Agent Builder 定義代理程式的知識與推理邏輯，而 Workflows 則定義其執行動作，兩者互為補充。

ES|QL：強大的管道式查詢語言

ES|QL 持續進化，新增五項技術預覽（Technical Preview）功能，提升分析效率：

• 子查詢 ： 支援在單一語句中結合多個獨立管道，無需手動彙整多個查詢結果。
• 近似查詢 ： 在處理海量資料時，以極小精確度換取極速回應，並提供信心指標，讓分析師掌握結果的可信度。
• 邏輯檢視 ： 可定義複雜的查詢邏輯並命名，供儀表板、警示與即時查詢重複調用。
• JSON 欄位提取： 透過標準路徑法直接從 JSON 欄位或 _source 提取資料，無需重新索引 (Reindexing)。
• 存取所有攝取欄位： 即使攝取時漏掉 Mapping 的欄位現在也能直接查詢，確保資料完整覆蓋。

AI 原生 Kibana

Kibana 正轉向更智慧的作業空間：

• AI 儀表板生成： 分析師只需用自然語言描述需求，Kibana 即可透過對話方式逐步建置儀表板。
• 儀表板即程式碼 ： 平台團隊可透過 CI/CD 流程控管儀表板版本，取代脆弱的 saved-object 匯入匯出模式。

營運管理與合規化

針對管理員與合規團隊，多項 GA 功能上線：

• 查詢活動監控： 管理員可即時查看所有長時間執行的查詢來源，並一鍵取消。
• 搜尋分析日誌： 自動紀錄 DSL、ES|QL、EQL 與 SQL 的查詢延遲與內容，無需額外配置。
• 個人化連線授權： Kibana Connector 支援以個人身分驗證取代共用服務帳號，讓審核追蹤更精確。
• FIPS 140-3 合規： Elasticsearch 與 Kibana 全面支援此安全標準，提供平滑升級路徑，無需資料遷移。

Search & AI

Elastic 9.4 為建構 AI Agents 的開發者提供了生產環境所需的掌握度：包含更精準的代理行為控制、更深層的效能監測，以及更具成本效益的向量運算。

• Agent Builder 體驗優化 Elastic 9.4 升級了使用者介面，優化開發者配置 AI 助理的流程。

Agent Builder

在 Elastic 9.4 中，Agent Builder 透過一系列連動的新功能，大幅優化了代理程式（Agents）獲取、運用與處理上下文（Context）的能力，讓開發者能建構出更穩定、低成本且高效能的 AI 助理。

• Skills： 這是一套引導指令，專門教導 Agent 如何完成特定任務。Skills 僅在需要時才會載入，有效提升反應效率。
• Kibana 物件對話與即時預覽： 支援在對話介面中直接操作 Kibana 物件，例如：儀表板、Workflows 與 ES|QL 查詢。使用者可以透過對話直接建立、微調並分析資料。
• 語義元資料層（Semantic Metadata Layer）： 在 Elastic 及其連結的外部來源（如 Google Drive, SharePoint）之上，建立了一層語義探索骨幹。這讓 Agent 能更深入理解資料脈絡，進而優化推理結果。
• 上下文管理優化： 導入查詢結果卸載、壓縮與摘要技術。在長篇、多輪的對話情境下，能有效降低成本並提升回應速度。

向量資料庫（Vector DB）

Elasticsearch 9.4 針對向量索引與搜尋演算法進行了深度優化，確保在生產環境的 AI 應用中能達到速度與成本的最佳平衡。

• 作為 Elastic 最核心的向量搜尋演算法，DiskBBQ 在此版本中大幅提升了效能。針對帶有「嚴格篩選條件」的查詢，其延遲降低了至少 3 倍。此外，受益於原生代碼（Native Code）的廣泛應用，向量比較效能也顯著提升，進而加速了索引與搜尋過程。
• 靈活的量化（將向量量化為 2-bit、4-bit 或 7-bit。當單一位元量化不足以滿足精確度時，這些新選項能提供更好的召回率。
• GPU 加速向量索引正式上線 (GA)： 先前於 9.3 釋出的技術預覽功能現已正式發布。透過整合 NVIDIA cuVS（開源 GPU 向量搜尋與資料分群函式庫），地端 用戶可獲得高達 12 倍的索引吞吐量提升，以及 7 倍快的強制合併速度。

開發者引導助理

新推出的對話式助理能引導開發者從構思階段快速進入實作，目前已支援在 Cursor、Claude Code 以及 Kibana 中運行。

• 引導式實作： 助理會詢問開發目標、分析資料結構並推薦最佳實踐方案。
• 全流程自動化： 從欄位映射（Mapping）、資料索引到產生可運行的實作程式碼，助理會分步引導，並在過程中主動提示關鍵的 Elasticsearch 核心概念。
• 縮短開發週期： 對於初次建置搜尋應用或正在開發原型（Prototyping）的團隊，這項工具能將數小時的文檔閱讀時間縮短至數分鐘的引導式開發，大幅提升效率。

動態 LLM 連接器與推論管理

Elastic 9.4 強化了對大語言模型（LLM）的整合與集中化控管能力：

• 跨版本模型擴充： 現在無需等待 Stack 版本更新，即可透過連接器即時支援最新的 LLM 模型。
• 統一推論管理體驗： 在 Elastic 生態系中建立了一個單一且權威的管理介面。無論是推論端點（Inference Endpoints）、模型還是連接器，都能在同一個位置進行集中控管。
• 流程整合： 讓開發者在處理所有的 Search & AI 工作流時，能更流暢地調度資源，確保管理邏輯的一致性。

Elastic Observability

隨著微服務與 Kubernetes 規模化，指標資料（Metrics）已爆增至億級。現有工具如 Datadog 常因「自定義指標」導致費用激增，逼使團隊刪除高基數標籤來節省預算；而 Prometheus 與 Grafana 則面臨效能下降及日誌與指標分散的問題。

Elastic Observability 9.4 讓 Elasticsearch 成為處理指標的首選平台，效能比 Prometheus 快 30 倍，儲存效率高出 2.6 倍，成本卻不到 Datadog 的一半，且完全不設高基數限制。透過 Kibana 對 PromQL 的原生支援，團隊可無縫沿用既有儀表板。此外，新版針對 Kubernetes 導入了 AI 驅動的自動化調查，讓 SRE 在點開儀表板前就能鎖定根本原因。

透過 Elastic 9.4，將所有資料（甚至是指標資料！）整合至 Elastic 平台變得前所未有的簡單。

更進階的指標數據體驗

Elastic 9.4 的更新大幅提升了處理指標資料（Metrics）的能力。藉由更高效的儲存架構、正式支援的時間序列查詢語言，以及對 PromQL 的原生支援，SRE 團隊能在單一平台上直接整合日誌（Logs）、指標與追蹤（Traces），不需改動既有的工具鏈。

• TSDB 效能提升：Elasticsearch TSDB 現已支援正式生產環境。與 Prometheus 相比，儲存效率提升 2.6 倍，查詢速度快了 30 倍。這代表在相同的硬體預算下，能攝取更多資料、存放更久，且查詢反應更快。
• 原生支援 Prometheus 與 PromQL (技術預覽)：現在能直接將 Prometheus 資料導入 Elasticsearch，並在 Kibana 裡直接執行 PromQL。開發者可以沿用習慣的語法，同時搭配 ES|QL 進行跨維度的關聯分析。
• ES|QL 時間序列分析：正式支援大規模的時間序列運算，並內建 rate、changes、cumulative 等聚合函數。這讓監控、警示與報表工作流更加穩固，在處理日誌與指標時，不再需要中途切換工具或語法。

TSDB 效能的提升，為將日誌、指標與追蹤資料整合至單一平台提供了強而有力的實務理由。

Kubernetes 代理式觀測

Elastic Observability 為 Kubernetes 導入了代理式（Agentic）調查體驗，實現從警示到根本原因分析的自動化：

• 自動化調查工作流：在 Kibana 中，AI 代理會在觸發警示時主動介入，在工程師開啟儀表板前，就先提供包含證據與後續建議的「根本原因假設」。
• Kubernetes MCP ：推出全新的 MCP App，將 K8s 專屬的維運技能直接整合至 Claude 或 VS Code 等 AI 開發工具中。
• 即用型監控資源：內建多款儀表板、SLO 與機器學習任務，支援隨時進行更深入的即時分析。

觀測專用代理技能

Agent Skills 是開源的套件包，賦予 AI 開發助理原生的 Elastic 觀測專業能力，使其能在平台內執行實際的運作流程。本次更新涵蓋了 SRE 與開發者日常最核心的五大工作流：

• 使用 OpenTelemetry 進行應用程式檢測
• 搜尋日誌
• 管理服務水準目標 (SLO)
• 評估服務健康狀態
• 監控 LLM 應用程式

這些任務通常需要熟悉特定的 API、索引模式與 Kibana 操作流程。為了避免人工重複操作時出錯或耗費過多時間，Agent Skills 將這些領域知識封裝成可重複使用的模組，確保執行的精確度與一致性。

目前所有的技能套件已在 Agent Skills GitHub 儲存庫 開放，開發者可立即導入使用。

Elastic Cloud 正式支援 OTLP 託管端點

Elastic Cloud 已正式推出 OTLP 託管端點，讓團隊能更輕鬆地將 OpenTelemetry 的日誌、指標與追蹤資料直接傳入 Elastic。

• 簡化架構： 無需自行佈署或維運 Collector 即可完成基礎資料攝取，降低管理負擔。
• 降低成本： 減少導入 OpenTelemetry 的阻礙，加快資料上線速度，也省去了維護自託管收集層的成本。

Elastic Security

在 9.4 版本中，Elastic Security 透過正式發佈的 Workflows 將原生自動化直接導入平台，涵蓋了警示分流、資料富化、響應與案件管理，讓資安人員能在資料所在地直接完成處置。

此外，新推出的四項實體分析（Entity Analytics）能力 —— 包含精確識別、實體關聯、動態監控名單與實體驅動偵測 —— 為分析師提供了唯一的權威紀錄與風險背景，不僅提升了人工威脅獵捕的效率，也讓 AI 代理在處理資安資料時能有更精確的推理基礎。

透過 Elastic 9.4 的 Workflows，團隊能以更強大的方式，在各種環境中設計、自動化並擴展以工作流驅動的維運流程。

Agentic SOC 的原生自動化

Elastic Workflows 現已正式上線。這讓資安團隊能在整合了 SIEM 與 XDR 的平台中，實現 Agentic SOC 的自動化願景 —— 針對警示、調查與案件直接執行資料富化、分流與響應。由於處置流程直接發生在資料所在地，能大幅縮短偵測到應變的時間。

提升資料管理與合規性

自動化流程的可靠性建立在資料完整度與權限治理之上。Elastic 9.4 透過以下功能優化了管控能力：

• 細粒度的偵測與警示權限：現在可針對偵測規則與警示分別配置權限。這讓初級分析師能執行警示分流，同時確保核心偵測邏輯不會被誤改，強化了內部管控。
• SIEM 準備就緒檢核 ：提供集中化的健康度視窗，針對端點、身分、網路、雲端及應用程式等五大日誌類別，評估資料覆蓋率、品質與連續性，確保底層資料足以支撐偵測需求。

為資安打造的 Agent Skills

Elastic 9.4 為 AI Agent 導入了五項專屬技能，賦予其處理 SOC 核心流程的專業知識：警示分流、規則撰寫、實體調查、威脅獵捕與異常分析。此外，AI Agent 也能調用儀表板管理與圖表建立等平台通用技能，而「工作流撰寫」則作為 9.4 的實驗性功能同步推出。

此版本的亮點在於 AI Agent 具備連續執行技能的能力：在單次調查中，它能從威脅獵捕開始，接續進行偵測規則調校，最後直接建立自動化工作流。未來還將加入偵測模擬、二進制分析與警示去重等進階技能，持續強化 AI 在資安維運的實戰火力。

透過實體分析精準識別攻擊者

Elastic 9.4 透過 實體分析 (Entity Analytics) 從資料模型層級解決了身分識別的雜訊，不再只是提供更多儀表板，而是透過四項正式發佈的功能，為分析師提供整合了風險與背景資訊的「權威紀錄」：

• 精準實體識別：自動將分散的日誌統一為用戶、主機和服務的高可信度身分檔案。這由平台自動管理，無需分析師手動操作。
• 實體關聯：將 Okta、Entra、Active Directory 等碎片化的數位帳號，整合為每位員工唯一的統一紀錄。
• 動態監控名單：針對高價值對象（如高階主管、特權管理員或核心系統）套用風險評分加權，將組織背景納入風險評分的核心考量。
• 實體驅動獵捕線索 ：將威脅獵捕從被動轉為主動。系統會根據環境中的實際行為模式，提供帶有敘事背景的風險線索，讓分析師不再面對空白頁面不知從何下手。

更深層的取證，更快的處理速度

Elastic 9.4 透過四項正式發佈的功能，延伸了端點調查的廣度，讓團隊能從遠端腳本執行一路深入到跨平台的記憶體取證：

• 腳本響應動作與集中腳本庫：分析師能直接從控制台執行遠端腳本，或透過自動化規則調用。集中化的腳本庫確保了修復動作的一致性，並能滿足 MSSP 規模的維運需求。
• Linux 記憶體轉儲響應動作：將記憶體取證擴展至 Linux 環境。無需外部工具即可直接獲獲取程序記憶體，有效應對無檔案惡意軟體 (Fileless Malware) 與記憶體駐留攻擊。
• Osquery 體驗革新：重新設計查詢歷史與進階搜尋功能，解決操作門檻，大幅提升大規模分析時的效率。
• 取證查詢包與資料表擴展：針對瀏覽器紀錄與 Jumplists 提供預建查詢，能即時取得關鍵跡證，快速重建攻擊者的行為時間軸。

值得關注的亮點

在 9.4 發佈之際，Elastic 還有幾項不容錯過的進展：

• Elastic AutoOps 現已免費： 提供 Elasticsearch 診斷與營運洞察，協助優化環境且無需額外成本。
• 跨專案搜尋（預覽版）： 可在單一介面同時查詢多個 Elastic Cloud Serverless 專案。
• 統一 API 金鑰： 單一金鑰即可跨專案管理基礎設施與數據查詢。
• ARM 硬體效能大幅提升： 採用 Graviton4 與 Axion 處理器，性價比最高提升 40%。
• Serverless 持續擴張： 在全球 29 個地區（含 AWS、Azure、Google Cloud）上線。

立即體驗 Elastic 9.4

憑藉 Agent Builder、Workflows 等新功能，Elastic 9.4 將協助您將數據轉化為實質的洞察與行動。Elastic 9.4 已在 Elastic Cloud 正式上線，您可以立即體驗最新版本的完整功能！

本文翻譯自：Elastic 9.4: Workflows GA, Agent Builder updates, and Prometheus/PromQL support

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

對經歷過雲端遷移的領導者來說，現在的 AI 熱潮似曾相識。當年許多企業低估了架構協調的難度，導致資源失控、工具重疊，技術達標了，營運效益卻沒跟上。

現在，AI 正在重演同樣的劇本，且影響力更深層。

雲端主要是基礎架構的變革，但 AI 會直接影響決策機制與員工效能。如果底層邏輯設定錯誤，損失將不只是預算，而是整個企業的發展軌跡。領導者必須吸取雲端經驗，避免重踩舊坑，才能真正把 AI 轉化為競爭優勢。

為什麼錢花了，AI 卻看不到回報？

常見的 AI 投資錯誤通常是這樣的：CEO 宣示「AI 優先」，CIO 開始評估平台，各部門各自啟動試點專案，財務部則一筆筆審核預算。半年後，企業多了十幾種 AI 工具，卻伴隨功能重疊、數據標準不一、資安風險失控等問題。這導致採購分散且無法計算投資報酬率（ROI）。

這不是因為誰做了壞決策，而是大家都在做「局部決策」。當缺乏統一的治理邏輯時，各部門追求的是局部效益，結果卻湊成了一堆碎片化的專案，這不是轉型，只是花了大錢卻沒有核心價值的拼貼。

如何把錢花在刀口上：先定目標，再買工具

轉型成功的企業都有一個共通點：先求共識，而非盲目跟風買工具。 這代表決策層必須對「成功」有相同的定義，建立一個能串接策略與執行的框架，重點應包含：

• 以業務成果為核心： 關注決策是否變快、流程是否更精簡，而非技術多強。
• 投資前定好權責： 在砸錢之前，就先定好衡量指標與責任歸屬。
• 按進度撥款： 預算應與階段性成果掛鉤，設定明確的停損或加碼點。
• 規範內的實驗機制： 讓各部門在治理架構下嘗試，而不是脫軌演出。
• 企業級工具： 提供統一的數據環境，讓所有決策都有據可循。

雖然在快速衝刺時，「治理」常被忽略，但它正是縮短「高層願景」與「基層執行」鴻溝的唯一橋樑。

AI 轉型成功的三大關鍵

雲端轉型給了領導者一個深刻的教訓：如果只投硬體，卻忽略員工的接手能力與投資紀律，最後只會換來資源浪費。AI 的學費會更貴。在建立框架後，決策層必須同時在以下三個維度發力，才能確保 AI 真正落地：

人才與流程：避免轉型陷入「數位演戲」

如果員工缺乏操作技能，或者公司流程沒跟著改，AI 就只會變成一種昂貴的裝飾品。代理商現場常看到企業買了工具卻沒人會用，這就是典型的「轉型演戲」而非真正變革。

你必須確認：團隊是否有能力將 AI 轉化為產出？有沒有評估機制來判斷哪些工具該留、哪些該果斷剔除？

系統與數據：解決碎片化的效能殺手

每一塊錢的 AI 支出，都必須能追溯到它支援的業務成果。這需要堅韌的 IT 架構與治理機制。碎片化的數據不只會拖慢 AI，更會直接破壞 AI 的判斷品質。在 AI 深入滲透營運之前，先解決數據存取與一致性的缺口，是目前投資報酬率最高的一筆買賣。

投資組合管理：別讓 AI 專案只會「打游擊」

別讓 AI 投資分散在那些「阻力最小」卻沒什麼價值的邊緣專案。所謂的紀律，就是清楚知道什麼該投、什麼該擴大、什麼該果斷止損。如果資源只是分散在各單位打游擊，那是「技術實驗」不是「企業轉型」；唯有集中火力在能創造差異化價值的核心業務，才能拉開競爭差距。

讓每一筆 AI 投資都看得到成果

AI 佈局最怕「看不清全貌」。當 CEO、CFO 與 CIO 能用同一套財務情報看清成本與回收，共識就不再是談判，而是數據決策。

Apptio 統一了財務與營運數據，讓高層能以管理重大投資的嚴謹態度來掌控 AI 轉型。雲端時代最貴的錯誤是管理與數據失敗，AI 轉型絕不能重蹈覆轍。技術已到位，這次能否成功，取決於你的管理架構。

推薦閲讀：什麼是 Apptio？掌握 IT 投資效益與預算控管的 ITFM 工具

本文翻譯自：New Tech, Same Rules: Cloud Lessons for an AI Advantage

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

【Apptio 系列研討會】從 AI 成本黑盒到 FinOps 自動導航：掌握雲端 ROI 的關鍵兩堂課

導入 AI 與雲端技術後，您的預算還在「盲跑」嗎？

養 AI 龍蝦很潮，但隱藏在光鮮技術背後的 Token 消耗與動態雲端帳單，是企業看不見的預算殺手。

本系列專場將攜手 IBM Apptio 技術專家，從最微觀的 AI Token 帳單拆解，到宏觀的 FinOps 自動導航策略，帶您全面透視雲端成本，確保每一分投入都能轉化為穩定達標的 ROI！

活動場次

【場次一】5/21 | 帳單治理與 AI Token 成本歸戶

日期：2026.5.21 (四) 11:00 – 12:00

形式：線上

重點： 徹底穿透雲端黑盒，釐清 AI Agent 背後 Token 成本分攤與流向。

【場次二】5/28 | FinOps 升級與預算自動導航

日期：2026.5.28 (四) 11:00 – 12:00

形式：線上

重點： 運用 AI 預測模型在超支發生前精準攔截，確保預算精準達標。

(您可以根據需求分別報名，或同時參加兩場以獲得最完整解決方案)

活動議程

本活動完全免費，誠摯邀請公司行業及政府單位的主管、IT 相關及專業技術人員踴躍報名參加！若您不屬於上述類別人員，恕無法接受報名，敬請見諒，感謝您的理解與支持。

IBM 旗下的 Apptio 推出 IBM Apptio Essentials 套件，專為追求敏捷的現代企業打造。

這套解決方案結合了 Apptio 的專業經驗與技術，並簡化了操作流程，使用者能快速上手，將精確的成本數據即時提供給相關決策者。

因應現代需求的 IT 財務管理

市場對 ITFM 解決方案的需求持續增長，顯示企業急需提升 IT 支出的透明度。根據 Gartner 調查，「半數 CIO 將『證明 IT 業務價值』視為未來一年的首要任務。」為了達成目標，IT 主管需要更簡便的方式回答兩個核心問題：「錢花在哪？」以及「這些支出創造了什麼效益？」

但隨著 AI 和 Kubernetes 等新技術的普及，傳統試算表或自建工具已無法應付現今的業務需求。這些舊方法容易產生數據孤島與人工錯誤，導致難以即時掌握準確的資源全貌。這迫使 IT 與財務主管只能憑「直覺」做決策，最終不僅影響企業獲利，也削弱了 IT 支出的策略價值。

IBM Apptio 解決方案
為 ITFM 提供了全新選擇，專為想拿回預算主導權的企業設計。無論是剛開始規劃流程，或是尋求優化現有體系，這套現代化且功能齊備的方案，都能協助使用者全面控管 IT 財務。

業界實戰經驗結晶，助企業快速落地

IBM 旗下的 Apptio 自 2007 年深耕 ITFM 領域，服務全球 60% 的《財富》百強企業與超過 1,800 家客戶。其引擎具備處理大規模 IT 支出與巨量數據的能力，並由專業團隊持續優化，確保決策數據的實用性。

IBM Apptio Essentials：回歸核心功能

相較於複雜的架構，IBM Apptio Essentials 專注於 ITFM 的核心基礎。這套方案針對想淘汰手動試算表、簡化管理流程的企業所設計，提供更精簡的操作方式。

此方案協助財務與 IT 部門優化預算，並向管理層展示 IT 投資的實際成效。透過內建報表與代管服務 (TAS)，企業無需漫長等待，最快 30 天即可看到初步管理成果。

靈活擴充的 ITFM 成長路徑

IBM Apptio Essentials 採用與進階版相同的運算引擎，讓企業能依自身步調逐步強化 ITFM 功能，兼顧初期快速見效與未來的升級彈性。

以 Burns & McDonnell 為例，該公司在告別手動試算後，先透過精確的 IT 帳單功能建立數據責任意識，隨後將應用延伸至預算預測，成功將過去耗時一個月的作業，轉化為高效且即時的管理流程。

一站式掌握 IT 財務管理核心

IBM Apptio Essentials 整合成本透明化、預算規劃、費用分攤及基準對比，協助企業從被動處理轉向主動決策。以下是套件涵蓋的三大方案：

• IBM Apptio Costing Essentials： 建立 IT 支出與投資的可視性，簡化數據輸入流程。透過內建儀表板，企業能快速掌握核心支出，並利用基準對比 (Benchmarking) 驗證決策合理性。
• IBM Apptio Planning Essentials： 自動化管理 IT 預算與預測，涵蓋人力、供應商、合約與資產管理。這讓 IT 主管能精確排定專案優先順序，確保資金投入在高價值的增長項目。
• IBM Apptio Billing Essentials： 透過「單價 × 數量」的簡化邏輯，呈現各業務單位的服務使用量。這種透明度有助於落實部門的預算責任，確保各單位的消費行為符合企業財務目標。

為什麼選擇 IBM Apptio Essentials？

無需等待，即刻上手

許多企業認為必須等數據完美後才能導入 ITFM 系統，這往往導致轉型停滯。IBM Apptio Essentials 打破了這個迷思——即使您的數據不完整、存在缺失或格式老舊，依然可以快速啟動。

透過簡單的分攤架構，系統能自動匯入並結構化您的財務與營運數據。您只需從對公司最關鍵的數據（如重大 IT 投資或資源）開始，系統會自動連結並整合資訊，為您呈現精確且具參考價值的資源分配全貌。

直覺的洞察與報表

內建「即裝即用」的標準報表，能將來自多方來源的複雜數據轉化為清晰的圖表。這些預設報表能即時呈現關鍵數據，協助管理層迅速做出決策，無論是識別節流空間、落實預算責任，還是全面掌握 IT 預算，都能精準達成。

專家代管服務 (Turnkey Admin Services, TAS)

除了強大的工具，IBM Apptio Essentials 還包含 TAS 專家代管服務。這意味著使用者將擁有專屬的 Apptio 專家團隊，提供持續的技術支援、最佳實務建議與平台培訓，讓團隊能專注於更具策略價值的核心業務。

TAS 服務能大幅縮短「價值實現時間 (Time to Value, TTV)」。由專家協助處理行政設定、系統維護與月底結帳流程，讓企業以最少的人力投入，發揮系統的最大效益。

總結

IBM Apptio 以數據驅動的模式，協助企業精準證明 IT 價值、優化成本結構，進而帶動業務成長。無論您處於 ITFM 的哪個階段，這套解決方案都能確保您的管理實務走在業界最前沿。

本文翻譯自：Unlock the Power of IT Financial Management with IBM Apptio Essentials

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

IBM Apptio 的出現就是為了解決這個問題。它是一個專門管理 IT 財務的自動化平台，讓企業能看清楚每一筆技術支出，並把錢花在真正有產出的地方。

什麼是 Apptio？

Apptio 是 IBM 旗下專門處理 IT 財務管理 (ITFM) 與 技術商業管理 (TBM) 的專業工具。

它的核心價值在於「將複雜的技術數據，轉化為商業決策語言」。

因應企業現代化轉型，Apptio 提供強大的「雲地整合」管理能力，不僅能統整傳統機房支出，更能對接公有雲環境，是企業落實 FinOps（雲端財務管理）文化的核心引擎。

Apptio 透過自動化整合企業內部的財務與維運數據，讓 CIO 能精確掌握每一台伺服器、每一份雲端帳單、每一款應用程式背後的真實成本與效益。

使用 Apptio 的實際數據表現：

• 精省支出： 找出並省下 3–5% 的不必要浪費。
• 回答問題快： 處理臨時的成本查詢速度提升 95%。
• 預算更精準： 規劃週期縮短 75%，且實際支出與預算的落差小於 1%。
• 汰換低效 App： 抓出組織內超過 25% 重複或沒人在用的軟體資產。

IBM 已連續兩年榮獲 Gartner® 雲端財務管理工具領導者，並在最新的 2025 年魔力象限報告中，於執行力與願景指標中雙雙奪冠。作為 IBM FinOps 家族核心，Apptio 整合 Cloudability 與 Kubecost 技術，提供全球企業公認頂尖的雲地整合與成本優化指引。

Apptio 核心功能與運作模式

Apptio 建立了一套標準化的管理框架，將雜亂無章的營運數據轉化為決策資訊。以下是 Apptio 四大核心功能：

成本自動化透明 (Costing)

Apptio 會自動串接你現有的財務與 IT 系統，不需要再手動貼資料。它會自動把雜亂的數據分類，讓主管一眼就能看透 IT 預算的細項流向。

智慧預算與預測 (Planning)

這是一個讓財務跟 IT 部門共同工作的平台。它把年度預算和每個月的滾動預測自動化，除了省下人工對帳的時間，還能根據現況快速調整資源配置。

IT 服務帳單化 (Billing)

透過 Apptio，IT 部門可以產出「業務單位看得懂」的帳單。讓各部門知道自己使用了多少伺服器、儲存空間或軟體授權，推動內部的使用者付費觀念，減少資源濫用。

行業標準對比 (Benchmarking)

Apptio 內建了大量去識別化的產業數據。你可以拿自己的 IT 支出跟同業比對，了解自己的花費是貴還是便宜，作為調整預算編列的參考依據。

這四個功能串聯起來，剛好解決了 IT 財務管理的完整流程：
先看清現在的錢花在哪，接著簡化預算的編列，並透過服務帳單讓各部門分擔責任，最後還能參考同業數據確保自己沒花冤枉錢。這讓企業能從被動的對帳，轉變為有數據支持的主動管理。

Apptio vs. 傳統手動管理

透過下表可以直觀看出，Apptio 如何解決傳統手動管理方式（如使用試算表）難以對齊數據的痛點：

Apptio 解決的不只是工具問題，而是流程的數位轉型。當數據能夠即時且精準地對齊，IT 部門就能從繁瑣的帳務對帳中解脫，將心力轉向更有價值的決策分析。

誰適合使用 Apptio？

Apptio 的設計考慮到了組織內不同利害關係人的需求，提供一致的數據事實：

• CIO 與 IT 財務： 想要自動化管理預算，不再被瑣碎帳務淹沒，並減少 IT 資源浪費。
• IT 服務經理： 需要具備公信力的數據來證明技術投資對業務的實質貢獻。
• 應用程式負責人： 需要計算 App 的總擁有成本（TCO），決定資源優化或汰換的優先順序。

Apptio 為企業建立了一個跨部門的財務對話基準。無論是看預算的資訊長，還是管技術的負責人，都能在同一個數據基礎上做決策，避免了過往資訊不對稱導致的資源浪費。

結語

IT 預算管理不該再靠直覺或破碎的手動流程。作為 IBM 解決方案的一員，Apptio 的價值就是把「技術數據」變成「商業語言」。它讓 IT 部門不再只是單純的成本負擔，而是能透過精確的數據管理，成為推動公司競爭力的決策夥伴。

如果您正受困於理不完的 IT 帳單，Apptio 將是您重新找回技術預算主導權的最佳工具。

*本文內容整理自 IBM Apptio 官方公開資料，僅用於技術介紹與資訊分享。

*參考資料：https://www.apptio.com/products/ibm-apptio/

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

因此，Starburst MCP 伺服器 成為其 AI 平台的關鍵。作為數據閘道器，它將 AI 的推理能力與企業數據對接，滿足高效能的互動需求。Starburst 具備滿足此趨勢的獨特優勢，且平台功能正持續擴張。

Starburst 宣佈全面支援 NVIDIA Vera

為了實現高效能 AI，Starburst 宣佈支援 NVIDIA Vera，成為首家針對此推論運算平台優化的 AI 數據平台。透過這項整合，客戶能在受治理的聯邦式架構下，以極速執行即時 AI 分析。

這項合作結合了數據存取、治理與效能優勢，象徵 Starburst 與 NVIDIA 平台的深度整合。該消息已於 NVIDIA GTC 大會，由執行長黃仁勳的主題演講正式發布。

Starburst MCP 伺服器：為 AI 代理提供商業情境與結構化存取

什麼是 Starburst MCP 伺服器？

其核心價值在於推動從「傳統 BI 技術」轉向「AI 驅動洞察」的架構轉型。這是一場數據互動模式的結構性變革：傳統 BI 依賴靜態儀表板與集中式資料倉儲，而代理式 AI 則需要更具持續性、對話式的模式。

Starburst MCP 伺服器充當安全的介面，讓 AI 代理能跳過傳統 BI 層的繁瑣維運負擔。透過支援 MCP 協定，該伺服器提供了標準化方式，能更有效地提取商業情境與數據。

超越簡單的 Text-to-SQL 應用，這項技術實現了超越單純「文字轉 SQL」的功能：

• 跨平台代理連接： 透過開放標準端點，Starburst MCP 伺服器能讓 Claude、ChatGPT 等外部代理程式直接導覽數據目錄並抽樣數據產品。這種方法能確保產出的 SQL 指令建立在一致的商業邏輯與治理定義之上，確保結果的精確度。
• 輕量化數據抽樣： AI 代理能檢視欄位並抽樣列資料，藉此建立精確推理所需的上下文資訊。
• AI 工作負載智慧路由： 透過針對 AI 優化的智慧路由端點，系統會自動選擇最有效率的 Galaxy 執行路徑，確保 AI 代理能以即時互動所需的速度獲得解答。

將資訊轉化為知識

AI 代理若要發揮實質作用，不能只靠原始數據，更需要深層的組織情境 —— 而這些重要資訊過去往往受困於孤立的報表之中。

Starburst AI 平台解決了這個難題。它將企業知識轉化為 AI 模型可吸收的「受治理資訊」。

透過業務領域（Business Domain）來組織數據，並利用具備權限與政策管理的數據產品，確保 AI 是在經過篩選的資產上運作，而非雜亂的原始記錄。

Starburst MCP 伺服器扮演了關鍵角色，讓這層專業數據能直接對接到各類外部 AI 代理生態系。

Starburst MCP 伺服器如何與 NVIDIA Vera 協同運作

MCP 伺服器為 AI 代理提供標準化的軟體介面，而 NVIDIA Vera 則為其供應高效能的推論引擎。

NVIDIA Vera 專為推論時代打造，結合了優化過的 CPU 與 Groq 語言處理單元（LPU）技術，實現了具備確定性且節能的運算處理。

透過針對此全新架構進行優化，Starburst 確保從傳統 BI 轉型至 AI 驅動的商業智慧過程，能同時獲得企業級治理與史無前例的運算效率。

Starburst MCP 伺服器與 NVIDIA Vera 帶來的優勢

此方案排除了大規模導入 AI 時常見的效能限制，並帶來以下效益：

具備推論速度的聯邦式存取

Vera 讓 Starburst 能夠直接查詢散佈在資料湖、倉儲與運作系統中的聯邦式數據。這有效消除了 ETL 瓶頸，且在驅動 RAG 流程或代理工作流之前，無需進行資料集中化。

具備確定性的推理吞吐量

Vera 的架構為混合工作負載提供了可預測的效能。這確保了在處理複雜的跨來源數據集時，並行分析查詢與 AI 推論任務仍能維持穩定的吞吐量。

以數據治理作為擴展 AI 的基礎

在代理式 AI 時代，治理絕非事後補償。Starburst MCP 伺服器確保每一位 AI 代理都以受控角色進行互動。

所有經由核心通道執行的查詢，繼承了與真人用戶相同的細粒度存取權限控管與可追溯性。這讓數據工程師與平台擁有者能安全地擴展 AI 存取權限，而不必增加風險成本。透過將治理從儀表板層移至底層架構，存取能力將能隨著系統智慧化同步成長。

Starburst MCP 伺服器與 NVIDIA Vera 的應用

Starburst MCP 伺服器的價值在於能將複雜的分散式數據環境，轉化為單一的標準化 HTTP 端點供程式存取；而與 NVIDIA Vera 的整合，進一步擴展了這項價值。

如何操作 Starburst MCP 伺服器？

對於平台管理者而言，啟用這項功能非常簡單，只需在 Starburst 控制端進行配置。一旦完成設定，平台就會開放標準化介面，讓任何符合 MCP 協定的代理程式立即進行數據探索與分析。

從產品面來看，MCP 伺服器的設計確保了代理程式的存取既具備高效能，且嚴格限制為唯讀模式。在實際運作中，包含了以下技術防護機制：

經身份驗證的程式化存取

伺服器支援企業級驗證方式，如 OAuth 2.0 與 OpenID Connect。透過符合標準的元數據端點，代理程式能自動識別權限範圍與安全協定。

同步的結構化結果

代理程式會收到結構化的 JSON 格式結果。這種同步執行模式能確保代理程式在取得完整資訊後才進行推理，有效降低因數據不全而產生幻覺的風險。

架構安全防線

為防止代理程式過度消耗系統資源或誤動數據，伺服器會主動拒絕非唯讀的操作（如刪除或更動指令）。此外，管理員可設定回傳資料量上限，確保資訊內容保持高信號與低雜訊。

透過這些內建配置，企業能從實驗性質的 AI 轉向更成熟的應用，將 AI 代理視為一種既專業且受控的企業情報使用者。

Starburst 為企業 AI 打造核心基礎

面對「AI 驅動決策」的轉型，關鍵在於我們與資訊互動方式的改變。這需要一個能對話、懂情境，而且效能極高的技術架構。

透過 Starburst MCP 伺服器與 NVIDIA Vera 的結合，這套架構已經成形。這不僅打破了傳統靜態報表的限制，更為企業提供了一條明路，將 AI 願景轉化為實質生產力。

本文翻譯自：Starburst Becomes First AI Platform to Support NVIDIA Vera

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

雖然 Terraform 已成為基礎架構佈署的標準，但如何將散落在各處、未受控的舊有資源納入管理，一直是維運團隊的挑戰。為了解決碎片化流程，Terraform 1.14 版本推出了 搜尋 (Search) 與 批量匯入 (Bulk-import) 功能。

這項新工作流不只協助企業盤點雲端環境中未受託管的資源，更直接將其導入自動化的安全流程中。以下將透過實際案例，說明 Terraform 如何簡化資源匯入的繁瑣過程。

為什麼需要 Terraform 資源搜尋功能？

目前的雲端環境極其複雜，根據統計，高達 97% 的企業在管理基礎架構時面臨挑戰，且需解決預算超支的問題。其中，「混合雲與多雲環境」的營運複雜度，被公認為是目前最大的技術阻礙。

具體來說，維運團隊常遇到以下問題：

解決手動操作 (ClickOps) 的管理漏洞

直接在雲端控制台手動點選（ClickOps）產生的資源，因為繞過了 IaC 流程，缺乏版本控制與自動化，成為資安治理與成本控制的盲點。

解決雲端資源浪費與閒置風險

缺乏統一盤點工具會導致測試環境、閒置虛擬機或過期儲存空間被遺忘。這些「孤兒資源」大幅增加非必要支出，更因為設定過期或錯誤，成為駭客入侵的資安破口。

解決設定偏移隱患

當雲端資源的實際狀態與預期代碼不符，即產生「設定偏移」。若資源未透過 IaC 管理，偏移將變得不可控，並引發以下風險：

• 資安威脅： 未被追蹤的變更可能成為攻擊者的入侵破口。
• 營運中斷： 意外的設定變動會導致部署失敗或服務停機。
• 合規風險： 稽核員無法確認實際環境是否符合公司政策或安全標準。

解決政策執行與自動化治理的缺失

缺乏 IaC 的環境無法建立防護欄（Guardrails）或自動化合規檢查，因此容易繞過安全控制，增加營運風險並喪失環境可視性，進而造成違反法規或不符產業標準的情況。

Terraform Search 如何解決管理難題？

Terraform Search 支援 HCP Terraform 介面、版本控制系統 (VCS) 或 CLI 工作區，有效解決上述痛點。操作邏輯簡單：

• 定義查詢： 在設定檔中使用 list 區塊定義查詢條件，主動搜尋雲端環境中的現有資源。
• 自動生成代碼： 透過 terraform query 指令，自動產出匯入所需的 resource 與 import 區塊。
• 一鍵納管： 將產出的代碼複製到 main.tf 並執行 terraform apply，即可完成資源匯入。

這套工作流取代了過去耗時且容易出錯的手動匯入（terraform import）流程，實現更安全、可重複利用的自動化管理。

案例：透過 Terraform Search 匯入 AWS EC2 資源

本範例將示範如何搜尋並匯入已存在於 AWS 控制台、但尚未納入 Terraform 狀態檔（State）管理的 EC2 實例。目標是消除管理斷層，將資源統一納入 Terraform 管理。

若使用 HCP Terraform（版本 1.14 以上），可以在左側選單看到新增的 「Search & Import」 選項。本案例將以 CLI 操作為主，示範匯入流程所需的 HCL 代碼。

HCP Terraform 工作區中的「搜尋與匯入 (Search & Import)」功能介面

透過 search.tfquery.hcl 檔案內的 list 區塊 來定義查詢條件。此區塊包含兩個核心參數：指定執行查詢的 Provider，以及用來建構查詢條件的 config 區塊。

search.tfquery.hcl

list "aws_instance" "unmanaged" {
  provider = aws
 
  config {
    region = "us-east-2"
 
    filter {
      name   = "tag:ManagedBy"
      values = ["unmanaged"]
    }
 
    filter {
      name   = "instance-state-name"
      values = ["running"]
    }
  }
}

此範例透過 Terraform 搜尋 AWS us-east-2 區域中，所有標籤為 ManagedBy: unmanaged 的執行中 EC2 實例。

提示： 查詢條件可根據需求自定義。更多進階參數請參考官方的「批量匯入資源 (Import resources in bulk)」文件。

定義好查詢條件後，即可執行以下指令：

$ terraform query
Running query in HCP Terraform. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the query running remotely.
 
Preparing the remote query run...
 
To view this query run in a browser, visit:
https://app.terraform.io/app/acfaria-hashicorp/ec2-search/search/qry-ubTgayE2hnLsF3LL
 
Waiting for the query run to start...
 
Terraform 1.14
on linux_amd64
Initializing plugins and modules...
list.aws_instance.unmanaged   account_id=008971679752,id=i-011f5cd5c03cc2560,region=us-east-2   unmanaged-instance-6
list.aws_instance.unmanaged   account_id=008971679752,id=i-0ca0957c269603542,region=us-east-2   unmanaged-instance-2
list.aws_instance.unmanaged   account_id=008971679752,id=i-0553ba06da0a4ae8f,region=us-east-2   unmanaged-instance-4
list.aws_instance.unmanaged   account_id=008971679752,id=i-0f10ea0f0d579ed3d,region=us-east-2   unmanaged-instance-3
list.aws_instance.unmanaged   account_id=008971679752,id=i-0ebdff0b154a659df,region=us-east-2   unmanaged-instance-1
list.aws_instance.unmanaged   account_id=008971679752,id=i-02c648ca8076d113f,region=us-east-2   unmanaged-instance-5

Terraform 搜尋結果會同步顯示在 CLI 介面與 HCP Terraform 控制台：

HCP Terraform 控制台呈現的搜尋查詢與結果畫面

HCP Terraform 控制台會同步顯示查詢設定，可以檢視各項未受控資源的細節，勾選欲匯入狀態檔（State）項目、點擊 「Generate Starter Configuration」 來生成初始代碼。

已勾選欲匯入的未受控資源

HCP Terraform 控制台自動產出匯入所需的 import 與 resource 區塊（如下圖）。請確認生成的 HCL 代碼無誤後，即可將未受控資源匯入 Terraform 狀態檔（State）。

HCP Terraform 控制台生成的初始代碼（Starter Configuration）

將產出的初始代碼複製到工作區的 main.tf 並視需求調整（如：移除衝突參數、修改標籤值），即可執行 terraform apply 將未受控資源匯入狀態檔（State）。

提示： 針對架構較複雜（complex schemas）的資源，Terraform 生成的預設代碼可能不完全正確，匯入前須手動微調。詳細資訊請參考官方文件的「限制說明（Limitations）」章節。

$ terraform apply
Running apply in HCP Terraform. Output will stream here. Pressing Ctrl-C
will cancel the remote apply if it's still pending. If the apply started it
will stop streaming the logs, but will not stop the apply running remotely.
 
Preparing the remote apply...
 
To view this run in a browser, visit:
https://app.terraform.io/app/acfaria-hashicorp/ec2-search/runs/run-ULkrfr9NQNNEjgAw
 
Waiting for the plan to start...
 
Terraform 1.14
on linux_amd64
Initializing plugins and modules...
aws_instance.unmanaged_4: Refreshing state... [id=i-0ebdff0b154a659df]
aws_instance.unmanaged_5: Refreshing state... [id=i-02c648ca8076d113f]
aws_instance.unmanaged_2: Refreshing state... [id=i-0553ba06da0a4ae8f]
aws_instance.unmanaged_3: Refreshing state... [id=i-0f10ea0f0d579ed3d]
aws_instance.unmanaged_1: Refreshing state... [id=i-0ca0957c269603542]
aws_instance.unmanaged_0: Refreshing state... [id=i-011f5cd5c03cc2560]
 
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place
 
Terraform will perform the following actions:
 
  # aws_instance.unmanaged_0 will be updated in-place
  # (will be imported first)
 …
 
Plan: 6 to import, 0 to add, 6 to change, 0 to destroy.

資源會立即匯入 CLI 與 HCP Terraform 狀態中。

aws_instance.unmanaged_5: Modifying... [id=i-02c648ca8076d113f]
aws_instance.unmanaged_1: Modifying... [id=i-0ca0957c269603542]
aws_instance.unmanaged_0: Modifying... [id=i-011f5cd5c03cc2560]
aws_instance.unmanaged_4: Modifying... [id=i-0ebdff0b154a659df]
aws_instance.unmanaged_3: Modifying... [id=i-0f10ea0f0d579ed3d]
aws_instance.unmanaged_2: Modifying... [id=i-0553ba06da0a4ae8f]
aws_instance.unmanaged_0: Modifications complete after 1s [id=i-011f5cd5c03cc2560]
aws_instance.unmanaged_1: Modifications complete after 1s [id=i-0ca0957c269603542]
aws_instance.unmanaged_2: Modifications complete after 1s [id=i-0553ba06da0a4ae8f]
aws_instance.unmanaged_5: Modifications complete after 1s [id=i-02c648ca8076d113f]
aws_instance.unmanaged_3: Modifications complete after 1s [id=i-0f10ea0f0d579ed3d]
aws_instance.unmanaged_4: Modifications complete after 1s [id=i-0ebdff0b154a659df]
 
 
Apply complete! Resources: 6 imported, 0 added, 6 changed, 0 destroyed.

並同步顯示於 HCP Terraform 控制台。

你可以在 AWS 控制台確認變更是否生效（例如 ManagedBy 標籤已更新為 terraform，且實例名稱變更為 managed-instance-#）。

AWS 控制台呈現匯入資源後的變更結果

使用 Terraform MCP Server 生成搜尋設定

談到 Terraform Search，另一個值得關注的應用是利用 Terraform MCP Server。它能協助開發者根據組織需求，撰寫更精確且相關的 Terraform 設定。

隨著最新版本發布，使用者只需在支援 MCP 的生成式 AI 工具中輸入指令，即可自動生成搜尋設定，例如：「請幫我搜尋標籤為 unmanaged 的未受控 aws_instance 資源，並使用組織 HCP Terraform 私有註冊表（Private Registry）中的 X 模組來進行匯入管理。」

這不僅把散落在外的資源抓回來，還能確保匯入的資源直接套用公司核可的架構範本，維持架構的一致性。

溫馨提醒：清理環境
使用測試資源進行實作，結束後記得執行 terraform destroy 徹底清理環境，以免產生不必要的帳單費用。

總結

面對規模化且碎片化的雲端環境，手動追蹤資源不僅累人，更是資安與合規的破口。透過 Terraform Search，終於能將散落在外的「管理斷層」轉化為自動化工作流，一鍵納管所有資產。

目前首波僅支援 AWS 部分資源（後續將陸續開放更多 Provider），這是邁向全環境自動化治理的關鍵一步。現在就動手清理你的雲端環境，重拾資源主控權吧！

本文翻譯自：Terraform search and import: Find resources and bring them into Terraform

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！

好消息，今年我們將再度攜手 Elastic 參加 2026 資安大會！

我們準備了許多豐富的「內容」及「活動」要和大家分享。

還沒報名的朋友，趕緊跟著這篇文章，讓我們一起進入 Elastic Security 的世界吧！

2026 臺灣資安大會｜活動資訊

日期：5/5（二）~ 5/7（四）

地點：臺北南港展覽二館 1F（歐立威科技在 C223 攤位）

講者分享

時間：5/5 (二) 15:30 – 16:00

地點：臺北南港展覽二館 7F 701G

講者介紹

講者：Elena Lee

公司：Elastic

職稱：台港區域資深方案架構師主管

主題：AI 領航 SOC 轉型實戰：打造自動化與智慧化的資安監控中心

技術交流、精美好禮都在 C223 攤位！

我們準備了滿滿的乾貨內容要跟大家分享，歡迎帶上您的架構規劃或操作疑問來找我們聊聊。

現場除了有專業諮詢，也有「簡單解任務、拿精美周邊」的趣味挑戰，更有機會把抽獎大禮帶回家 ~

***詳細活動內容，請鎖定資安大會期間，前往 #C223 攤位瞭解更多***

會前閲讀 Security 文章

為了幫助大家快速了解 Elastic Security 解決方案，我們精選了一些技術文章。

包含 Elastic Security 的基本概念及功能介紹，以及真實客戶的應用案例。

這些參考資料可以幫助你更快的認識 Elastic Security 解決方案。

1. 10 分鐘了解 Elastic Security 四大功能，端點、雲端安全的全面防護！
2. Elastic Security 第一個發展為 AI 驅動的安全分析解決方案
3. Elastic Defend 如何優化？資安團隊兼顧效能與成本的關鍵策略
4. Elastic 9.3 新功能重點：資料對話、AI Agent 與自動化應用
5. 舊 SIEM 太慢？AI 助攻輕鬆搬家到 Elastic Security
6. 整合 Elastic Security、HashiCorp Vault 與 Elastic APM 的全面防護與效能優化
7. 需要更換 SIEM 的五個跡象！公開 SIEM 解決方案
8. 如何讓 Elastic Security 為您的公司創造價值？

更多精彩內容，都在 Youtube

如果你對影音內容比較感興趣，歡迎到我們的 Youtube 頻道看看！

我們有超過 10 部介紹 Elastic 的影片，你一定可以找到想要的內容！

針對這個挑戰，EDB 推出新一代 EDB Postgres AI Factory，協助企業在完全掌控資料的前提下，落實生成式 AI（GenAI）的推論應用。市場趨勢顯示，領先企業已不再將 AI 視為單一專案，而是將其納入基礎架構的一環。

推薦閲讀：EDB Postgres® AI 2026 第一季新功能亮點

成功關鍵：資料主權與架構

根據一項針對全球 2,050 位企業領袖的調查，雖然 95% 企業計畫在三年內建立自有的 AI 與資料平台，但僅 13% 能真正產生效益。他們的 ROI 是同業的 5 倍，在生產環境中部署的 AI Agent 數量也是兩倍以上。其優勢在於對「資料主權」的掌控：能完全管理資料的儲存、存取方式與 AI 運作邏輯，同時解決安全性、合規與規模化擴展的難題，而不必在技術間權衡取捨。

EDB Postgres AI 是為了解決這些挑戰而設計，新一代 AI Factory 則進一步強化了這項能力。

Gartner 報告指出，具備生成式 AI 功能的資料庫管理系統（DBMS）支出預計到 2028 年將成長三倍，且超過 75% 的企業將 AI-ready data 列為首要投資項目。Gartner 將 EDB 列為企業級 AI Agent 的代表性供應商，並強調資料庫在架構中扮演的三大關鍵角色：Agent 記憶（Memory）、知識來源（Knowledge source）與任務執行（Task execution）。目前的挑戰在於：如何在不產生技術債的情況下，滿足開發需求並將應用推向生產環境。

AI Agent 適用場景與分層模型

AI Agent 能處理自動化網路監控、多步驟客服流程及即時營運情資，其商業價值在於處理開放式任務、模糊輸入與跨系統調度。

例如：在處理資料庫效能問題時，Agent 能在秒級內分析慢查詢日誌（Slow query logs）、檢查鎖定表（Lock tables）並提供分析假設，這類高價值的推理能力是其優勢。

然而，針對具備明確邏輯的任務，如系統擴展、故障轉移（Failover）或組態變更，過度使用 Agent 反而會增加複雜度與風險。這類任務應採用確定性的（Deterministic）策略引擎，而非機率性的 AI 模型，以避免合規風險與難以除錯的行為。

成熟的技術架構不應是「全 Agent 化」，而是採用分層模型：

• Agent 層：分析、建議與綜合資訊
• 策略引擎層：驗證與最終決策
• 執行層：具體行動

此架構能確保在需要的地方發揮智慧，在關鍵的地方保持掌控。企業需要的解決方案應能輕鬆開發基於真實資料的 Agent，而非僅能在測試環境運作的原型，並彈性地將 Agent 置於合適的架構層級中。

日本電信商 NTT East 便採用 EDB Postgres AI Factory，在完全私有的環境中部署用於網路維運的 AI Agent，實現自動化偵測與問題回應。這證明了技術信心不僅來自模型，更來自底層的基礎架構。

Agent Studio：視覺化開發與整合

EDB AI Factory 最顯著的演進是重塑了 Agent Studio。它採用 Langflow 作為視覺化整合開發環境（IDE），並基於產業標準的 LangChain 生態系建構而成。

許多企業的 AI 計畫在從概念驗證（PoC）轉向生產環境時，常因開發環境與實際基礎架構脫節，導致需重新設計架構，耗費大量時間與預算。

Agent Studio 解決了這個斷層：在視覺化介面開發的原型即是產品，每個 Flow 都能直接轉換為 REST API 端點，無需額外的工程交接即可部署。

視覺化開發與 Python 擴充性

透過拖拉式介面，開發者能快速串接 LLM、儲存空間與資料源，並在部署前驗證邏輯。

當需求變得複雜時，系統也支援完整的 Python 擴充性，確保開發不受限。這種設計兼顧了開發效率（拖拉式）與細膩控制（寫程式），讓企業能根據需求彈性選擇。

企業級部署的核心能力：

• MCP (Model Context Protocol) 支援：任何 Flow 都能作為 MCP 伺服器供其他 Agent 或應用程式調用，支援企業建構模組化的多 Agent 協作架構。
• 安全 Agent 記憶體：將中間狀態與工具輸出儲存在本地的 Postgres 中，避免敏感資料傳輸至公用 LLM，滿足金融、醫療與電信等高度合規產業的需求。
• Agent 生命週期管理：整合 LangSmith、Langfuse 等觀測性工具，並內建 Agent Lifecycle Toolkit (ALTK)，在進入生產環境前預先識別推理邏輯或輸出品質的問題。

EDB 選擇以 Langflow 為基礎，反映了其擁抱開源技術的原則。這讓開發團隊能利用活躍的社群生態快速迭代，同時避免被單一廠商綁定，確保技術架構能跟上 AI 領域的快速演進。

向量資料庫升級：VectorChord 雙架構

AI Agent 的表現取決於資料的即時性與索引品質。

為了滿足不同規模的技術需求，新一代 AI Factory 對內建的向量資料庫功能進行了重大升級：在保留 pgvector 的同時，新增了 VectorChord 索引選項，讓 Postgres 在單一平台上展現專用向量資料庫的效能。

適應不同規模的索引選擇

對於多數企業的 RAG（檢索增強生成）應用，pgvector 仍是首選，能穩定處理千萬級別的向量資料。

然而，當 AI 應用規模擴展至「億級」向量、維度更高且需支撐數百個並發查詢時，傳統的 HNSW 索引在建立時間、記憶體消耗與吞吐量上會面臨挑戰。

VectorChord 正是為了突破此瓶頸而設計，其具備以下技術優勢：

• 超越專用向量資料庫的效能：採用 IVF-RaBitQ 索引架構，索引速度較 pgvector 快 100 倍，並在維持 95% 以上召回率（Recall）的前提下，提供 5 倍快的查詢速度。
• 高效率資源利用：處理 1 億筆 768 維向量時，在僅 32GB 記憶體的環境下，P50 延遲僅為 35ms。與**專用向量資料庫（如 Pinecone）**相比，每一塊錢能處理的向量數量高出 6 倍。
• 無痛升級：完全相容 pgvector 的資料型態與語法。企業可根據需求隨時切換索引，無需修改應用程式程式碼或遷移至其他資料庫。

三大效益：

1. 即時性與響應速度：更快的索引速度縮短了知識庫更新的延遲，讓 Agent 能基於最新資料運作，提升輸出的準確度與用戶體驗。
2. 資料主權與掌控：所有向量資料原生儲存在 Postgres 中，無需額外維護外部向量資料庫，降低資料外洩風險與治理成本，適合地端（On-premises）或隔離環境（Air-gapped）部署。
3. 規模化下的成本優勢：VectorChord 優異的儲存與記憶體效率，讓企業無需投資昂貴的專用硬體，即可在現有的 Postgres 環境中運行十億級規模的 AI 工作負載，實現資料庫架構的精簡與整合。

在可控資料架構下落實 AI 應用

AI Agent 的競爭關鍵在於穩定、安全且具備規模化的技術架構。EDB Postgres AI Factory 透過整合視覺化開發工具、高效能向量引擎與自動化 Pipeline，協助企業在完全掌控資料的前提下，大幅縮短從原型開發到生產環境的部署時程。

這套整合方案讓團隊能隨著 AI 技術演進靈活切換模型，且無需更動底層基礎架構，確保 AI 計畫能真正落地並產生實質的商業價值。

本文翻譯自：The Next Generation of EDB Postgres AI Factory: Built for the Agent Era

想瞭解更多？歡迎聯絡我們，或是 加入歐立威 Line 好友！