目前僅 13% 的企業成功將 AI Agent 專案導入生產環境，主因在於基礎設施限制。根據 EDB 的調查，企業急需一個能直接掌控，並統一處理交易、分析與 AI 工作負載的平台。

傳統資料堆疊因拼湊舊系統與各家雲端平台，導致資料自主權風險、效能不穩且成本難以預測。EDB Postgres® AI 提供 PB 級效能並節省 58% 成本，且無供應商鎖定（Vendor lock-in）。

PB 級分析：穩定效能與可預測成本

全方位資料倉儲監控與管理

EDB 致力於提升 Postgres 的分析引擎實力。根據 McKnight Consulting Group 的測試，WarehousePG 對比 Snowflake 與 Databricks 等雲端資料倉儲，表現如下：

• 成本效益： TCO 最高節省 58%，採用可預測成本模型，無隱藏費用。
• 高穩定性： 在高併發負載下，效能穩定度高出 52%。
• 部署彈性： 支援雲端、地端、隔離環境（Air gapped）或混合雲。

圖 1：EDB Postgres AI 對比雲端資料倉儲可節省 58% TCO。

維運優化：WarehousePG Enterprise Manager (WEM)

測試證實，PB 級分析不需依賴封閉平台或雲端綁定。為簡化維運，EDB 推出 WEM 管理工具，提供視覺化介面取代複雜的指令列，讓叢集管理與監控更直覺。

圖 2：WEM 視覺化介面提供單一窗口管理與監控 WarehousePG 叢集。

WEM 整合了即時遙測、AI 輔助開發與互動式配置功能，將複雜的分散式資料庫操作整合至單一管理介面。管理者可直接進行叢集健康檢查、SQL 效能調校，並在高效能環境中管理安全性。

透過大規模擴展能力與簡化管理的結合，EDB Postgres AI for WarehousePG 為 AI Agent 時代的維運需求提供了更簡便的標準。

推薦閲讀：分析型資料庫一定要多叢集？EDB WarehousePG 有不同做法

GPU 加速讓分析效能提升 91 倍

除了強化資料倉儲，EDB 也持續提升維運資料（Operational data）的分析速度。上個月在 NVIDIA GTC 大會上，EDB 發佈了 PGAA 擴充功能與 NVIDIA RAPIDS for Apache Spark 的深度整合。

透過 Spark 的橫向擴展能力，並將計算密集型的分析工作負載卸載（Offload）至 NVIDIA GPU，企業可消除傳統 CPU 的效能瓶頸。此 GPU 加速技術讓即時維運資料的分析查詢速度提升高達 91 倍，提供 AI Agent 即時處理與決策所需的高吞吐量與次秒級延遲。

使用 EDB Postgres AI 構建自主 Agent

根據 Gartner 預測，企業在 AI 資料庫系統的支出將於 2028 年增長三倍。Gartner 在報告中肯定了 EDB 具備 AI Agent 資料庫的三大關鍵角色：作為長期記憶、核心知識來源，以及任務執行的可靠引擎。

本季度 EDB Postgres AI 推出新一代更新，簡化了直接在現有資料上構建 Agent 的流程。這些功能旨在提供整合工具，協助團隊銜接原型開發（Prototype）與生產環境（Production）之間的差距，並有效地驅動資料與編排（Orchestrate）Agent 行為。

EDB 向量資料庫

AI Agent 的工作流品質，完全取決於底層向量資料庫知識庫的效能。本季度 EDB 強化了內建的向量引擎，推出高效能的 VectorChord，為企業提供更強大的 Postgres 向量資料庫解決方案，作為 pgvector 的高階補充方案。

此次更新為不同工作負載提供彈性的索引策略：

• pgvector： 仍為多數 RAG 應用的標準規格。
• VectorChord： 專為規模達十億級向量的企業級向量資料庫需求設計，提供隨插即用（Drop-in）的升級體驗。其索引速度提升 100 倍，並具備高併發多 Agent 系統所需的次秒級延遲。

Agent Studio 實現視覺化 AI 開發

EDB Postgres AI 的 Agent Studio 現已與 Langflow 整合，提供直觀的視覺化拖拉介面來構建、測試與部署 Agent。使用者可從零開始設計，或使用開源模板與自定義組件。

為強化 Agent 編排與資料之間的連結，EDB 在 Langflow 中引入了 MCP Server、資料庫與嵌入（Embedding）組件。透過 MCP（Model Context Protocol） 開放標準，Agent 能直接將 Postgres 資料庫作為工具進行互動，大幅消除自定義整合的障礙並提升連線安全性。

圖 3：EDB Postgres AI 的 Agent Studio 整合 Langflow 拖拉式介面，支援從零開始構建、使用開源範本或自定義模板，快速開發與部署 AI Agent。

AI Pipelines 現已支援多步驟流程的點選式配置（Point-and-click），統一資料準備與嵌入（Embedding）步驟，達成「一次構建、統一維護」。針對 SQL 使用者，AIDB 擴充功能強化了 PDF 解析與資料庫內建 LLM 能力，僅需幾行 SQL 指令即可原生導入複雜文件，並將非結構化資料自動摘要為具參考價值的資訊。

此外，模型推論（Model serving）功能現在可直接連接 Hugging Face 等供應商，無需手動編寫整合代碼（Glue code）。將模型直接對接平台，能有效減少資料移動、提升安全性，並確保 AI 堆疊的自主掌控權。

大規模 AI 基礎設施管理

AI Agent 時代不僅改變了開發模式，也改變了維運與基礎設施的管理邏輯。EDB 透過自然語言與業界標準自動化技術，簡化了企業對整體資料環境與基礎設施的管理流程。

自然語言簡化維運流程

EDB Postgres AI 現已內建聊天機器人（Chatbot），支援透過自然語言管理平台，無需編寫腳本（Scripting）。管理員可直接透過對話簡化以下任務：

• 建立或編輯遷移（Migration）專案。
• 修改使用者角色與權限。
• 直接獲取效能與健康檢查建議。

這項功能將手動操作轉化為互動式對話，朝向自動化管理邁進，讓團隊能專注於更具策略性的工作。

圖 4：EDB Postgres AI 內建聊天機器人，支援以自然語言提問並獲取資料庫與整體環境的建議，無需編寫程式碼即可快速獲得分析資訊。

瞭解，這段關於自動化與高可用性的內容，我將其併入前面的段落，並維持極簡、技術導向的風格：

此外，EDB 推出了自動化存儲擴展（Autonomous storage scaling），能根據工作負載自動增加容量。管理員可預設維護視窗或存儲上限，無需手動干預或預先配置過多資源（Over-provisioning），即可確保應用程式持續運行。

針對無法容忍停機的關鍵任務，Hybrid Manager 現已支援三地部署，提供 99.999% 的高可用性。這確保企業營運不會因單一區域或資料中心故障而中斷，強化業務連續性。

Red Hat Ansible 認證的自動化架構

EDB 與 Red Hat 共同驗證了參考架構（Reference Architecture），為 Red Hat Ansible Automation Platform (AAP) 提供高韌性的資料層。針對關鍵任務的自動化平台，穩固的基礎設施是確保業務流程不中斷的核心。

EDB Postgres AI 與 AAP 整合提供以下優勢：

• 高可用性（HA）： 支援多可用區（Multi-AZ）韌性，可在 30 秒內完成自動容錯移轉（Failover）。
• 災難復原（DR）： 提供強大的跨區域保護，確保營運不中斷。
• 無縫部署： 原生整合 Ansible，支援全堆疊（Full-stack）自動化流程。

目前每一版 AAP 釋出前皆會針對 EDB Postgres AI 進行完整測試，確保企業具備經認證、可投入生產環境的大規模自動化基礎。

本文翻譯自：EDB Postgres® AI Q1 2026 Release Highlights

想瞭解更多 EDB Postgres® AI 的應用與導入建議？歡迎聯絡我們，或是 加入歐立威 Line 好友！

Starburst 提供跨系統、跨雲、混合環境的資料整合與分析能力，讓企業能更快地從資料中取得可行動洞察。

什麽是 Starburst？

Starburst 是一個企業級資料整合與分析平台，專為跨系統、跨雲端及混合環境的資料整合與即時查詢設計。它建立在開源分散式 SQL 引擎 Trino 之上，延伸了 Trino 的查詢能力，提供高效能 SQL 查詢、彈性擴展與完整資料治理功能，支援 BI 報表、即時分析以及 AI 專案開發。

透過 Starburst，企業可以直接查詢原始資料，或將資料移入 Iceberg 優化表格，加快 AI 運算速度，同時降低資料搬移與重複整理的成本。所有查詢與操作都具備血緣追蹤、稽核及安全控制，確保資料使用透明且符合法規要求。

此外，Starburst 提供多種部署模式，包括雲端全託管與本地/混合環境，能依據資料量、使用者數量及 AI 專案需求自動擴展，保持查詢與分析效能穩定。對於需要即時資料洞察、跨來源整合和可靠資料治理的企業，Starburst 提供完整解決方案，支持資料驅動的業務決策與 AI 專案落地。

Starburst 與 Trino 的關係

Starburst 在 Trino 的基礎上，加入了企業級功能，使其不只是開源 SQL 引擎，而是一個完整的企業資料平台。它保留 Trino 的分散式查詢能力與高併發性能，同時增強了安全性、資料治理、成本優化與連接器支持，使 BI、即時分析與 AI 專案能在同一平台上高效運作。

簡單說，Trino 提供了核心查詢引擎，而 Starburst 將其能力延伸到企業級使用場景，解決了跨來源整合、資料治理與即時分析的痛點。這也是 Starburst 能在多雲與混合部署環境下，仍維持高效能查詢與 AI 運算的關鍵原因。

核心技術與運作模式

Starburst 的核心理念是「資料不搬移也能整合分析」。透過資料虛擬化技術，統一整合不同來源資料，使用者可以直接查詢原始資料，或將必要資料移入 Iceberg 表格以支援 AI 運算。

分散式 Trino SQL 引擎可支援高併發、多使用者環境下的高效能查詢，同時可搭配自然語言查詢與語意搜尋，加快資料轉化為洞察。資料治理與安全機制可追蹤血緣、稽核存取歷史，確保符合企業規範。

Starburst 提供雲端全託管（Starburst Galaxy）與本地/混合部署（Starburst Enterprise），可依資料量與使用者數自動擴展。

優勢與應用

Starburst 平台支援向量資料、串流資料及批次資料的整合，加快 AI 開發與驗證流程，協助生成式 AI 專案快速落地。隨著資料量與使用者增長，Starburst 可自動擴展，確保查詢與分析效能穩定，讓企業專注於創新與業務發展，而不受基礎設施限制。

此外，Starburst 適合多雲與混合部署環境，減少資料搬移成本，加速決策流程，並維持資料治理與安全合規，提供可靠的資料基礎支援企業資料驅動應用。

與 Lakehouse 及 Data Lake 的比較

為了選擇最適合企業的資料平台，我們比較 Starburst 與 Lakehouse、Data Lake 在查詢效率、資料整合與 AI 支援上的差異，幫助企業快速了解各自優勢與限制。

從表格可以看出，Starburst 在即時查詢、多來源整合、AI 支援以及資料治理上比 Lakehouse 與 Data Lake 更具優勢。

Starburst 能直接在原始資料上進行高效查詢，不必等待資料搬移或重整，降低資料管理複雜度。相比之下，Lakehouse 與 Data Lake 雖然各有特色，但在多來源整合與即時分析能力上仍存在限制，尤其對 AI 專案支援不如 Starburst 靈活。這也說明了為什麼 Starburst 能成為企業資料整合與 AI 專案的核心平台。

結語

Starburst 能同時支援 BI、即時分析與 AI 專案。在多雲與混合部署環境中，Starburst 提供可擴展、高效且安全的方案，幫助企業在資料驅動的業務與創新中保持競爭力。

展望未來，隨著企業資料量持續增長、AI 與即時分析需求加快，像 Starburst 這類能提供跨來源即時整合、支援多種分析與 AI 工作負載的平台，將越來越成為企業數位化與資料驅動策略的核心基礎。對於希望快速取得資料洞察並支援 AI 專案落地的組織而言，這類平台的角色與價值只會持續提升。

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

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

那麼，IT 領導者該如何突破 AI 困境，實現可量化成果？以下分享 Elastic 的三個 GenAI 策略。

用 Support Assistant 提升客戶體驗

挑戰：客服負擔加重

客戶越來越獨立，81% 會先嘗試自行解決問題，真正聯絡客服時，希望快速、高效得到解答。但客服工程師往往需要花大量時間查閱文件，導致解決速度慢、滿意度下降。

解決辦法：Support Assistant

Support Assistant 是 Elastic 的生成式 AI 聊天機器人，協助客服工程師回覆客戶問題，也讓客戶可以自行解決問題。

它採用 檢索增強生成（RAG）架構，搭配 OpenAI 的 GPT-4o 大型語言模型（LLM）與向量搜尋技術，存取大量企業知識庫，包括：

• 內部文件
• 客戶案例紀錄
• 已解決工單
• CRM 資料
• 白皮書與教育資源
• 產品缺陷與解決紀錄

透過向量搜尋與語意檢索（semantic search），Support Assistant 能理解查詢意圖，即使用詞不同也能找到相關資訊，並可整合多個來源內容、摘要案例討論，甚至建議下一步行動。

Support Assistant 提供對話式搜尋，讓客戶與客服都能快速取得相關資訊，加速問題分流與解決。

成效：上線 4 個月即見 ROI

Support Assistant 在 Elastic 的實作與測試中，直接整合生成式 AI 進入使用者與客服工程師的工作流程，上線僅四個月就回收投資成本。

成果顯著：

• 硬案件攔截率提升 6 倍：客戶透過 Support Assistant 找到答案，選擇不建立支援工單
• 平均首次回覆時間縮短 23%：客戶能更快獲得協助
• 人工支援案件量減少 7%：減輕客服團隊負擔，展現生成式 AI 的效率提升

用 ElasticGPT 提升生產力

挑戰：資料太多，時間不夠

企業每天產生大量資料，但員工卻難以快速找到分散在各系統中的相關資訊，加上部分資料孤島化，導致資訊不準確，也增加了重複查詢的工作量。

解決辦法：ElasticGPT

ElasticGPT 是公司內部的生成式 AI 工具，幫助員工快速找到所需資訊，提升工作效率。

它建置在 Elastic Cloud 上，整合向量資料庫、Elasticsearch、Observability 與企業資料連接器，並透過 RAG 提供可靠、最新的答案，能在公司內網、SlackBot 或 ElasticGPT 頁面使用。

同時，Elastic 建立了集中化基礎架構，支援多個生成式 AI 應用，方便擴展、避免技術負債，並讓更多企業系統與資料可供查詢。

此外，ElasticGPT 可安全連接多個 LLM，如需外部資料自動抓取，確保團隊能使用最新技術且運作安全。

成效： 2 個月就看到成效

ElasticGPT 上線 3 個月内，就讓員工能更快速、直覺地搜尋公司內部資料，每人每月平均節省超過 5 小時，每年約 63 小時。僅 2 個月，效率提升就足以抵銷 ElasticGPT 的建置與 LLM 運行成本。內部調查顯示，員工滿意度高達 98%。

用 Elastic AI Assistant 優化安全工作流程

挑戰：攻擊與威脅增加

隨著 SaaS 應用普及，攻擊面不斷擴大，新型複雜威脅也在 AI 助力下快速增長。傳統報告方式無法應對分散來源的威脅資訊，手動收集、分析與整理既耗時又效率低，難以快速取得可行情報並評估風險。

解決辦法：Elastic AI Assistant

Elastic AI Assistant 提升安全分析師的專業能力與效率，減少手動調查與回應的工作量，簡化威脅情報報告流程。

Elastic 建立了統一的 Markdown 報告模板，讓 AI Assistant 從威脅情資、部落格、事件報告等來源即時收集資料並生成初稿，分析師則專注於精煉洞察與風險評估。同時，它還能進行威脅趨勢分析，識別模式並預測新興威脅，幫助安全團隊掌握快速變化的威脅環境，提升資安成熟度。

推薦文章：Elastic AI Assistant：讓搜尋變簡單的資安小幫手！

基於 Elastic Search AI 平台的 Elastic AI Assistant for Security

成效：節省 75% 工作時間

導入 Elastic AI Assistant 後，安全團隊分析師節省了 75% 的工作時間，同時威脅情報報告產量提升 92%！

透過簡化手動流程，分析師能專注於高價值任務，例如：深入分析新興威脅在 Elastic 環境中的影響，並採取更主動的資安策略。

透過生成式 AI 創造商業價值

企業可以透過生成式 AI 發揮高價值，例如資料整合、預測分析、互動數位手冊、威脅追蹤等。

Elastic 成功的關鍵在於：找出客戶需求、員工支援與安全領域的真實問題；以高品質、企業專屬資料建立垂直領域的 AI 應用；將 AI 深度整合到工作流程中，而非僅在介面上提供工具；避免單一問題的短期解決方案，而是建立可持續發展的 AI 生態系統。

根據 Elastic 的案例，生成式 AI 不只是實驗工具，而能從試點順利推向生產環境，並帶來明確、可衡量的投資回報，而這一切都依靠 IT 與決策主管的支持推動。

本文翻譯自：3 real-world generative AI strategies for executives

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

資安事件來得快，您的回應速度夠快嗎？

警報堆積、事件複雜…傳統人工回應已無法追上威脅速度，每次延遲都可能讓小問題變成重大損失。本活動將示範 Elastic AI Agent 如何透過自動化威脅偵測與事件回應，加速決策流程，幫助企業提升資安防護效率！

活動資訊

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

形式：線上

活動亮點

• 自動化威脅偵測：精準識別真正威脅
• 事件回應加速：縮短反應時間、降低風險
• AI Agent 實務應用：案例示範與操作演練

我們誠摯邀請您，學習 Elastic 最新技術，掌握職場競爭力！

 活動議程

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

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

好禮領取

報名成功即可抽 Elastic 帆布袋 （限量 2 個）！活動前到 歐立威 FB 參加開源隨堂考，再抽 Elastic 帽 T （限量 1 件）！

隨著資料量與使用者需求成長，傳統多叢集架構在管理與效能優化上挑戰加大，分析團隊往往花更多時間控管成本，而非專注於提供洞察。

為何 BI 工作負載擴展方式不同？

雲端資料倉儲是為了處理大規模資料工程與排程分析而設計，目的是在執行批次 ETL 或機器學習任務時能有效利用資源。用量計價的模式可以讓系統在任務執行時使用資源，完成後自動釋放，降低不必要的成本。

商業智慧（BI）系統的使用節奏

BI 與傳統排程分析不同。業務人員全天刷新儀表板、資料科學家執行探索性查詢、財務分析師生成報表，AI agent 也同時提供對話式分析。這種同時操作的模式對系統資源與效能管理帶來極大挑戰。

不同平台在處理高併發 BI 使用者時的資源分配方式差異很大：有些平台會啟動多個叢集，有些只需要少量叢集；排隊時間可能從瞬間到 30 秒以上；查詢失敗率最高可達 4%。

即便是相同工作負載，成本也可能因自動擴展方式不同而差異高達 73%。這些都顯示，高併發 BI 的架構設計對成本與效能影響非常明顯。

併發對 AI 世代的重要性

BI 不只來自人類使用者，AI agent 也會自動查詢資料庫，增加更多併發負載。

每個 AI agent 像超級使用者，數秒內執行數百筆查詢，並根據結果決定是否發出更多查詢。即便資料倉儲能跟上，高併發 BI 也會讓成本迅速飆升，迫使分析團隊將時間花在控管資源，而非專注於產出洞察。

架構為何影響高併發工作負載？

雲端資料倉儲原本針對間歇性任務設計，能在突發需求時快速擴充運算資源，任務完成後再自動釋放。這對批次 ETL、機器學習訓練或週期性分析非常適合，彈性架構與用量計價相輔相成。

但高併發 BI 工作負載並非突發，而是可預測的持續需求。即便有 AI agent 參與，整體查詢模式仍高度可預測：你大致知道上班時間內有多少分析師與 agent 同時查詢資料。

問題在於：當為突發負載設計的平台遇到可預測的高併發查詢時，成本反而難以控制。使用者越多，啟動的叢集越多，帳單越高，即便實際使用模式沒有改變。

簡單來說：彈性架構會帶來彈性成本，而非彈性的工作負載反而造成錯配。

Postgres 替代方案：可預測的效能與成本

Postgres 為基礎的資料倉儲採取了完全不同的方法。基於 MPP（Massively Parallel Processing）大規模平行處理架構，經過數十年驗證技術，可以在不需要多叢集協調的情況下處理高併發工作負載。

圖 1：MPP 架構透過將資料列與運算分散到多個獨立的 segment 主機上來擴展效能

Segment 協調器會建立最佳執行計畫，指示每個 segment 如何並行處理其專屬的資料區塊（例如 16 個 segment 各自處理 16M 列資料表中的 1M 列）。

獨立基準測試顯示這種方法效果非常顯著。初步結果指出，Postgres 架構在高併發、高容量分析工作負載下可節省成本高達 62%，在併發擴展效率上比主流雲端資料倉儲高出 63%，同時維持可預測的成本結構與一致的使用者體驗。完整基準結果將在未來幾週公開。

對於關鍵業務操作來說，穩定性至關重要。MNTN，一個管理 PB 級資料的領先連網電視廣告技術平台，多年來一直使用 Postgres 資料倉儲。他們對效能一直滿意，但需要一個開源替代方案以及企業夥伴，來保證營運不中斷並提供快速支援。EDB Postgres AI for WarehousePG 就是他們的解決方案。MNTN 的資料主管 Greg Spiegelberg 表示：「效能穩定，系統可靠，支援快速，正如應有的。我很安心，即使半夜遇到問題，也有人能協助我，不必自己手動修改開源程式碼來恢復資料庫。」

EDB WarehousePG：單叢集處理高併發 BI

當你掌握每天的儀表板刷新、定期報表週期以及分析師查詢模式時，高併發 BI 工作負載其實是可預測的，無需冒高風險去更換基礎架構。

差異在於可預測性：

• 用量型平台（Consumption-based）：針對突發、不可預測的負載優化，你按使用量付費，但「實際使用量」會受到隱藏變數影響，例如平台自動擴縮的積極程度、叢集保持活躍的時間、查詢是排隊還是立即執行，以及為應對併發需求啟動了多少叢集。
• 容量型平台（Capacity-based）：針對已知負載優化，你根據併發需求配置運算核心，無論執行 1,000 筆還是 100,000 筆查詢，成本都保持固定。當平台需要啟動 3~5 個額外叢集應對高峰併發時，容量型成本不受影響。

對大多數已建立 BI 工作負載的企業而言，可預測性往往比彈性更重要。

轉換到容量型平台不代表必須拆掉現有架構。WarehousePG 基於 Postgres，團隊可立即使用熟悉的 SQL 技能。對於已在使用 Greenplum 的組織，轉換只需簡單的二進位替換（binary swap），可在數小時內完成，而非數月。

歐洲泛歐市場基礎設施 Euronext FX 就採用了這種轉換，藉此避免被既有 Greenplum 供應商綁定。Euronext FX 全球 CTO Grigoriy Zeleniy 表示：「我們很高興能與 EDB Postgres AI 合作。它對 Greenplum 工作負載的支援，讓我們能掌控開源軟體的部署位置與方式。」WarehousePG 提供了無縫二進位替換，並在四個全球資料中心提供卓越企業支援與開源控制。

在 GDPR、資料存放地要求以及日益嚴格的法規監管下，這種掌控力非常重要。組織必須確切知道資料存放位置與存取權限，同時不犧牲效能與可預測性。

除了成本可預測性，WarehousePG 的 MPP 架構 可處理大量報表與高併發 BI，並透過工作負載管理優先處理關鍵查詢。內建 向量化功能（pgvector） 支援 AI 特徵工程與模型訓練，可直接在資料上操作，不需將資料移到其他基礎架構。即時資料流（streaming ingestion）支援即時日誌與事件分析，跨資料湖的聯邦查詢打破資料孤島，無需複雜 ETL 流程。

推薦閲讀：EDB Postgres 向量搜尋怎麼做？核心技巧公開

選擇適合的架構與定價模式

如果高併發 BI 工作負載出現不可預測的成本，你並不孤單。雲端資料倉儲的用量計價模式，雖然對資料工程非常吸引人，但對商業智慧分析而言，經濟效益可能不同。

透過容量型架構與 EDB Postgres AI for WarehousePG，獲得明確的優勢：

• 成本可預測：按核心計價，取代用量計費
• 操作簡化：管理的系統元件減少，小型團隊也能輕鬆維護
• 效能提升：與 Tableau 直接連線，無需額外抽取流程
• 維持資料主權：資料可留在 VPC 中，符合法規要求

重點不在於現代雲端平台能否擴展（它們當然可以）。關鍵是，你是否為多叢集與彈性擴縮付費，而你實際需要的只是可預測的效能與可控成本。

立即體驗 EDB Postgres AI for WarehousePG！看看 Postgres 架構如何處理高併發 BI 工作負載並保持成本可預測，或聯繫我們的團隊進行工作負載評估。

本文翻譯自：Why Your Analytical Database Needs Multiple Clusters to Do What WarehousePG Does With One

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

什麼是向量搜尋？為什麼重要？

向量搜尋依據語意或資料特徵找到相似內容，即使文字或數值完全不相符。

例如，查詢「如何重設密碼？」時，系統仍能找到《登入憑證重設步驟》，即使字詞不同。這種以語意而非文字匹配的能力，是建構智慧應用的關鍵。

向量搜尋應用廣泛，包括：

• 語意搜尋：理解查詢意圖，超越關鍵字比對。像客服平台輸入「無法登入」，仍可找到「密碼重設」文章。
• 文件檢索：將報告、知識庫或工單轉為向量，快速找到最相關內容，並支援 RAG 提供上下文答案。
• 文件比較：銀行、保險或稽核可比對大量文件，即使改寫或重組，也能找出重複或相似內容。
• 圖像相似性搜尋：向量可表示視覺特徵，電商推薦相似商品，媒體檢測重複或近似圖片。
• 推薦系統：將使用者與商品向量存於 Postgres，依語意相似度推薦商品、電影或文章，考量偏好、購買紀錄或評論情感。

透過 EDB Postgres 的 pgvector 擴充功能，向量資料可直接存放、索引與查詢，讓 AI 任務與企業現有交易或分析工作無縫整合。

向量搜尋如何運作？

向量搜尋的運作方式，是將資料轉成向量（embedding），再依相似度找出最相關內容。具體流程可分為四個步驟：

1. 向量生成：使用模型（如 OpenAI、BERT、CLIP）將文字、圖片或音訊轉為多維浮點數向量，就像為語意建立「GPS座標」，概念相似的向量會聚在一起。
2. 存放於 Postgres：透過 pgvector 將向量存入專用欄位，每列對應一份文件、圖片或資料紀錄。
3. 相似度搜尋：查詢先轉為向量，再比對資料庫向量的相似度（如餘弦距離或歐氏距離）。
4. 排序與回傳：系統依相似度分數排序，回傳最相關結果。

這種架構簡單卻強大，將結構化資料、非結構化資料與向量搜尋整合在同一 Postgres 平台中，實現高效、統一的搜尋體驗。

向量搜尋的相似度指標

向量搜尋的核心在於比較向量，找出哪些已存向量最接近查詢向量。不同的距離指標決定了「相似度」的計算方式。

兩個最常用的指標是 餘弦相似度 (Cosine Similarity) 與 歐氏距離 (Euclidean Distance)，兩者皆由 pgvector 原生支援。

向量搜尋的索引與擴充

當資料量從數千筆向量增加到數百萬筆時，逐一比對每個向量的「暴力搜尋」成本太高，這時向量索引就很重要。

什麼是向量索引？

向量索引會將向量依特徵分群或組織，讓系統能快速找到相似向量，而不需掃描整個資料集。

常見向量索引類型

• IVF（Inverted File Index）：將向量分成多個群集，僅在最相關群集內搜尋。
• HNSW（Hierarchical Navigable Small World）：圖結構索引，將相似向量連結，提供超快查詢速度。
• PQ（Product Quantization）：將向量壓縮成較小表示，降低儲存與計算成本。

近似最近鄰搜尋（ANN）

ANN 能有效擴充向量搜尋規模，不必找出精確最近鄰，只找到「近似最近鄰」，以極小精度換取大幅效能提升。

對於即時 AI 場景，如：聊天機器人、推薦系統或語意搜尋等，ANN 索引提供了速度與精準度的理想平衡。

EDB Postgres AI 向量搜尋

雖然市面上出現許多新向量資料庫（如 Pinecone、Milvus、Weaviate 等），企業仍偏好 EDB Postgres，原因包括：

• 統一平台
  利用 pgvector，無需額外資料庫存放向量，AI 工作負載可直接在處理交易或分析資料的 Postgres 實例中運行，架構更簡單。
• 企業級可靠性
  EDB Postgres 延續 Postgres 多年的穩定性，提供企業級可靠性、複寫與高可用性，適合關鍵任務，不同於實驗性向量資料庫。
• 無縫整合
  支援各種擴充套件、FDW 與整合框架，讓結構化資料、向量與外部 AI 模型能混合分析。
• 彈性擴充
  搭配 EDB Postgres Advanced Server、WarehousePG 或 Postgres Distributed，可跨節點擴充向量運算，同時兼顧分析效能與向量相似度搜尋。
• 治理與安全
  金融、公共單位等行業對資料治理與自主管控要求高，在 EDB Postgres 上執行向量搜尋可確保資料主權、稽核與合規性。

結語

在生成式 AI 的應用中，向量搜尋是核心，但穩定性才是落地關鍵。透過 EDB Postgres 與 pgvector 的整合，你可以在熟悉的 SQL 環境中處理語意搜尋與 RAG，不需要額外維護一套複雜的專用向量資料庫。

推薦閲讀：資料庫遷移全攻略：掌握變更管理一次看懂

本文翻譯自：Getting Started with Vector Search in EDB Postgres

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

開放原始碼資料平台，讓結構化與非結構化資料都能轉化為可用洞察

新版本除了強化開發者在情境工程（context engineering）與 AI Agent 建置上的支援，也為 Elastic Search & AI、Elastic Observability 與 Elastic Security 帶來新功能與能力更新。

Elastic 9.3 帶來哪些新功能？

Elastic 9.3 引入多項功能升級，涵蓋工作流程自動化、AI Agent 開發、向量索引加速與 Jina AI 模型整合，全面提升 Search & AI、Observability 與 Security 的效能與便利性。

Search & AI

Elasticsearch 提供穩健基礎與完整情境工程平台，讓客製化 AI Agent 開發更簡單、加速完成。無論是與資料對話、提升搜尋相關性（幾乎不增加運維負擔）或優化向量索引，新版本都能提供支援與效能提升。

Search & AI 在 Elastic 9.3 的亮點：

• Elastic Agent Builder（正式推出）：提供一系列 AI 驅動能力，開發者能直接與 Elasticsearch 資料對話，並簡化客製化 AI Agent 的開發流程。Agent Builder 能搭配 Elastic Workflows 使用，使 Agent 能執行可靠的自動化操作。
• 三款 Jina AI 模型 (jina-embeddings-v3,  jina-reranker-v2-base-multilingual, & jina-reranker-v3)可透過 Elastic Inference Service（EIS）使用，提供快速 GPU 加速的多語言向量嵌入與高精準度重新排序。未來，所有新的最先進 Jina AI 模型也將透過 EIS 提供。
• GPU 加速向量索引（技術預覽）：透過整合 NVIDIA cuVS（GPU 加速向量搜尋與資料聚類的開放原始碼函式庫），Elastic 9.3 支援高效能向量資料庫（vector db）操作，自建 Elastic 環境的使用者可使用 NVIDIA GPU 提升資料索引效能。
• EIS via Cloud Connect（正式推出）：讓自建集群能將推理運算卸載到 Elastic Cloud 的管理型 GPU 基礎設施，同時保持資料、儲存與索引本地化。無需配置 GPU 或管理模型操作，就能在私有或受規範環境中部署語意搜尋、多語言檢索、重新排序以及 RAG（agentic retrieval augmented generation）工作流程。

更多細節： Search & AI 9.3 版本說明文件

Elastic Observability

在 Dimensional Research 針對 2026 年可觀測性趨勢所做的報告中，98% observability 團隊表示會使用生成式 AI，但「如何落地」仍是挑戰。

Elastic 9.3 針對「如何」提供了具體方案：Elastic Streams 能在資料接收時自動解析日誌，新的 Amazon Bedrock 整合將管理型 LLMs 帶入觀測工作流程，而 agentic 功能則幫助團隊從被動調查轉向 AI 輔助的根因分析。

Elastic 9.3 讓 Elastic Streams 從原始訊號創造價值更簡單

主要亮點：

• Pattern-based log compression：新增 pattern_text 欄位類型（正式推出），可將日誌訊息欄位的存儲量減少最多 50%。
• ES|QL metrics 加速（技術預覽）：查詢延遲最多降低 5 倍，提供更多時間序列聚合指令、指數直方圖與輕量化 metrics downsampling，讓分析更全面。
• Amazon Bedrock AgentCore 整合（技術預覽）：為在 Amazon Bedrock 上運行的 agentic AI 應用提供端到端的 observability 解決方案。
• Elastic Streams 改進（技術預覽）：透過 agentic workflow，使用者可直接從日誌文件的 message 欄位解析日誌，點擊一次即可完成。
• Elastic Workflows（技術預覽）：讓操作人員建立可用於編排與自動修復的工作流程，並整合 Elastic Agent Builder，實現與外部系統整合的 agentic workflow，用於調查與根因分析。

更多細節： Elastic Observability 9.3 release notes

Elastic Security

Elastic 9.3 帶來多項新能力與優化，協助安全工程師、SOC 分析師與威脅獵人偵測複雜威脅並建立 AI 驅動的 SOC。

Elastic 9.3：AI 生成 Entity 風險摘要，涵蓋異常、漏洞與資產重要性

主要亮點包括：

• Automatic Migration for Rules（技術預覽）：擴充支援 QRadar SIEM，讓使用者更輕鬆採用 Elastic 的 AI 驅動檢測與調查解決方案。
• Entity Analytics → Entity AI Summary（正式推出）：提供基於異常、漏洞、錯誤配置與資產重要性的 AI 生成風險摘要，並附清晰建議行動。
• Elastic Workflows：提供原生自動化引擎，消除人工分流並執行可靠的回應操作；整合 Elastic Agent Builder，分析師可呼叫基於運營資料的 AI Agent，加速複雜調查。Elastic 9.3 也推出全新預建威脅獵捕 Agent，整合 Alerts、Attack Discovery 與 Entity Risk Scores，提升調查效率。
• Automatic Gap Filling（正式推出）：自動補齊規則執行中可能遺漏的部分，快速恢復未觸發警示並降低漏報。
• Endpoint Security 新功能（正式推出）：新增 Windows Memory Dump 回應動作、兩個 osquery 擴充（Browser History 與 Amcache）、以及新的預建 osquery 查詢與套件庫。

更多細節： Elastic Security 9.3 release notes

Elasticsearch Platform

每次版本更新，Elasticsearch Platform 都協助開發者與專業人士縮短企業資料與高品質 AI 體驗之間的落差。

透過精準的相關性與上下文支援、維持開放原始碼與標準，確保平台可在任何客戶需要的環境中使用，Elastic 核心平台的更新讓所有使用者受益。

主要亮點：

• Elastic Workflows（技術預覽）：將自動化帶到資料所在的位置，支援規則式與 agentic 自動化，讓團隊能直接對資料執行營運或業務流程、回應與調查，並使用 Elastic 的上下文、權限與擴展能力。
• ES|QL 進階分析：9.3 將 ES|QL 轉為多維分析引擎，新增 inline stats 支援多階段邏輯，同時保留行級資料與彙總資訊；進階時間序列函數與全文檢索 join，可在單一 piped query 中關聯複雜的遙測與安全資料。

更多細節： Elasticsearch Platform 9.3 release notes

Elastic Cloud Serverless

Elastic Cloud Serverless 現已覆蓋 18 個全球區域，並在 AWS 上完成重大基礎建設升級，提供高達 35% 搜尋延遲降低、26% 吞吐量提升，為搜尋、可觀測性與安全提供更高效的基礎環境。

立即體驗 Elastic 9.3

Elastic 9.3 已在 Elastic Cloud 上線，包含所有新功能。從 Elastic Workflows 原生自動化到 Elastic Agent Builder 正式推出，搜尋、觀測與安全的 AI 應用都更容易上手。現在就開始試用，體驗新功能帶來的效率與便利！

本文翻譯自：Elastic 9.3: Chat with your data, build custom AI agents, automate everything

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

API 金鑰、Token 與憑證決定系統間信任，一旦外洩，攻擊者可橫向擴散至環境、雲端與生產系統，引發連鎖影響。

下文將介紹五大敏感資訊外洩來源及企業防護方法。

攻擊如何發生？

攻擊通常從取得存取權限開始，而非直接從勒索軟體或資料竊取。一個本不應外洩的敏感資訊外洩，就可能引發多重資料外洩，形成連鎖攻擊。

一般流程如下：

1. 釣魚或憑證竊取：攻擊者先取得 Slack、Jira 等協作工具的存取權限
2. 發現外洩敏感資訊：Token 或連結引導他們進入程式碼庫或 CI/CD 系統
3. 橫向擴散：取得的憑證開啟資料庫、雲端服務或生產系統
4. 影響階段：資料外洩、服務中斷或部署勒索軟體

敏感資訊往往不是單點外洩，而是散布在多個工具和工作流程中。了解來源與偵測方法，是阻斷攻擊鏈、避免損害的關鍵。阻斷攻擊鏈、避免損害的關鍵。

推薦閲讀：整合 Elastic Security、HashiCorp Vault 與 Elastic APM 的全面防護與效能優化

來源一：協作工具（Slack、Jira、Confluence）

協作工具之所以存在風險，不僅是因為它們存放資料，更因為它們承載了系統間的信任關係。這些平台會記錄從故障排除討論、設定筆記，到環境細節的每一次交流，對取得存取權限的攻擊者而言，是極為完整的脈絡資訊。

敏感資訊常出現在以下情況：

• Slack 訊息中分享故障排除紀錄或憑證
• Jira 工單包含程式碼片段或環境變數
• Confluence 頁面記錄設定步驟與敏感資料
• 為方便而上傳的日誌檔或設定檔

由於這些系統設計為開放而非限制，暫時分享的敏感資訊往往長期留存。攻擊者一旦入侵單一工作區，就能快速描繪依賴關係，並橫向擴散至相關系統。

協作工具通常未納入敏感資訊掃描系統，卻儲存高價值、長期有效的憑證，讓攻擊者取得深度存取權限。

來源二：程式碼倉庫（GitHub、GitLab、Bitbucket）

程式碼倉庫是現代開發的核心，但也是最常發生敏感資訊外洩的來源之一。在交付壓力下，開發人員常會無意間提交敏感資訊。

常見情況包括：

• 測試後遺留的 API 金鑰或憑證
• 內含密碼的設定檔
• .env 檔案不小心被提交到版本控制
• 範例或測試程式碼被推到生產分支

一旦敏感資訊被提交，它通常不會消失，而是透過 fork、clone、pipeline 與備份傳播，存在於每個分支和快取中。

程式碼倉庫原本並非為管理敏感資訊設計，但實際上已成為其儲存場所。若缺乏持續掃描與自動修復，倉庫會成為發現漏洞的目標。

來源三：容器映像檔

容器加速了交付速度，但也帶來新的隱性風險。在映像檔建立過程中嵌入的敏感資訊，可能被持續複製到各環境中，往往超出傳統監控範圍。

常見外洩情況包括：

• Dockerfile 中的硬編碼憑證
• 設定檔直接複製到映像檔內
• 建置時定義的環境變數，而非執行時
• 依賴套件或套件管理器中嵌入的敏感資訊

由於容器的分層特性，即使後續刪除敏感資訊，舊層仍可能保留，攻擊者可透過簡單工具提取。

所有容器映像檔都可能將敏感資訊散布到整個組織，每次被拉取、分享或重用都會放大風險。

來源四：CI/CD pipeline

在 CI/CD pipeline 中，各環節都需要使用敏感資訊以保持建置與部署流程順暢，因此這些資訊常被重複存在設定檔、腳本、日誌與工具中。隨著敏感資訊擴散，更新與撤銷變得困難且緩慢，任何憑證外洩都可能擴大影響範圍，單一錯誤就可能引發更大資安事件。

敏感資訊常出現於以下情況：

• 憑證直接嵌入 pipeline 設定檔
• 建置或部署過程中被記錄在日誌
• 共用模板將相同憑證複製到多個專案

這會形成一個隱性的依賴網路，一個外洩的 token 可能危及數十個應用程式或服務。

CI/CD pipeline 是交付的關鍵連結，一個外洩的 pipeline 憑證就可能讓攻擊者取得整個生態系統的特權存取。

來源五：雲端儲存桶（S3）

錯誤設定的雲端儲存仍是憑證外洩最常見的根本原因之一。敏感資訊常透過自動化流程進入儲存桶或 blob，流程以速度為優先，而非監控安全。

常見外洩情況包括：

• 權限設定錯誤導致儲存桶公開可存取
• 備份中包含 .env 檔或設定資料
• 日誌匯出中含有 token 或服務憑證
• 應用程式快照內嵌敏感資訊

一旦攻擊者發現外洩的儲存位置，就可能提取敏感資料與可重複使用的憑證，進而橫向影響連接的系統或雲端服務。

儲存桶通常不在日常程式碼或 pipeline 掃描範圍內，缺乏監控。將敏感資訊可視化，統一管理於倉庫、pipeline 與儲存層，是防止外洩的關鍵。

從可視化到掌控

降低敏感資訊風險，不只是定期掃描。敏感資訊不只出現一次，它會隨程式碼、建置物件與基礎架構流動。保護敏感資訊需要在整個軟體生命週期中持續可視化。

傳統工具多半是在事件發生後才偵測外洩，而 HashiCorp Vault Radar 能即時揭露暴露的敏感資訊。

使用 Vault Radar，組織可以：

• 持續監控程式碼與 CI/CD pipeline，在敏感資訊進入生產前就偵測
• 擴展監控至協作工具、日誌與檔案伺服器（如雲端儲存桶），捕捉在壓力下或無意間分享的敏感資訊
• 監控運行環境，辨識所有持續存在的憑證
• 將敏感資訊視為動態資產，從偵測、優先排序到全程管理

這種以生命週期為核心的方式，將資安從事後清理轉為主動掌控。

透過 Vault Radar，組織能即時移除暴露的敏感資訊，降低資安事件風險：

• 限制橫向擴散，縮小攻擊者可存取範圍
• 提升營運韌性，同時不拖慢開發速度

數千起資安事件都源於單一敏感資訊外洩。成功防禦的組織，不是反應更快，而是更早看見風險。Vault Radar 提供這種可視化能力，將敏感資訊從隱藏風險轉變為可管理的憑證。

本文翻譯自：The top 5 sources of secret sprawl, and how attackers exploit them

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

在 Elastic，我們將資安團隊視為「零號客戶（Customer Zero）」，所有產品皆使用最新版本，Elastic Defend 會在工作站群中部署，並在新版本釋出後 24 小時內更新。

本文說明 Elastic 資安團隊如何最佳化端點資料收集，透過事件篩選與進階策略提升效能並降低成本。

推薦閲讀：如何讓 Elastic Security 為您的公司創造價值？

什麼是 Elastic Defend？

Elastic Defend 是功能強大的 端點偵測與回應（EDR）代理程式，提供完整的進階威脅防護，包括預防、偵測與回應。

除了端點本機偵測與警示，還會收集豐富的事件遙測資料並送至 Elastic Stack，包括：

• 程序執行、網路連線、DNS 事件
• USB 裝置事件
• DLL 與驅動程式載入
• API 事件、檔案系統變更、註冊表修改

從版本 8.3.0 起，Elastic 預設啟用事件篩選（Event Filtering），會自動過濾已知良性系統事件（可在進階策略中關閉）。除了內建篩選之外，你也可以新增自訂事件篩選，進一步降低資料量與成本。

透過 事件篩選 與 進階策略設定（Advanced Policy Settings），Elastic 資安團隊大幅減少噪訊、提升叢集效能，同時節省儲存成本，維持穩健的資安防護。跟隨這些策略，你只需數小時操作，就能顯著降低 EDR 成本。

分散式工作團隊與端點挑戰

Elastic 採用遠端優先策略，團隊成員分布在全球 43 個國家。

近一半員工是開發人員或工程師，使用 Mac、Windows 和 Linux 工作站進行軟體編譯、客製化 Linux 核心建置，甚至在工作站上透過 Kubernetes 運行 Elasticsearch 叢集，產生大量良性但噪訊多的檔案與程序活動。

最初部署 Elastic Defend 時，我們先在少數工作站試點，了解事件量與噪訊來源，逐步每週增加更多工作站。若未啟用事件篩選，每台工作站每小時平均產生 48,000 個事件，其中多數來自良性但噪訊高的管理軟體，如 Qualys、Jamf、Intune。我們需要策略來過濾雜訊，同時避免資安分析盲點。

步驟 1：辨識雜訊事件

在尋找噪訊事件時，通常有兩種類型需要注意：

1. 大部分工作站都會產生的軟體事件
2. 單一主機產生的事件遠高於其他主機

建議先從第一類著手，因為篩選後對整體影響最大。常見來源包括 MDM 代理程式或其他持續執行相同良性操作的應用程式，如寫入日誌或透過網路傳送日誌到叢集。

若單一主機事件量異常，通常是設定錯誤或程式漏洞，最好直接修正主機問題，而非只加事件篩選。例如，我們曾發現一台 Linux 系統的腳本持續重啟，每秒崩潰數千次，修正後不僅降低噪訊，也提升系統效能。

對於只在個別主機安裝的軟體，可針對該主機使用事件篩選，常見於單一伺服器（如資料庫或 Web 伺服器）產生大量網路或檔案事件。

在 ES|QL 查詢中，我們使用 logs-endpoint.events* 索引模式，這是 Elastic Defend 預設用來儲存端點事件的索引。若使用自訂設定或跨叢集搜尋，索引模式可能不同。

最噪訊的事件類別與操作：使用這個查詢找出產生最多警示的類別與操作，是篩選噪訊的最佳起點。

FROM logs-endpoint.events*
| STATS event_count = count(*) BY event.category, event.action
| SORT event_count DESC
| LIMIT 10
| KEEP event.category, event.action, event_count

10 大噪訊主機：這個查詢可以幫助你找出產生最多事件的工作站或伺服器。

FROM logs-endpoint.events*
| STATS event_count = count(*) BY host.id, host.name
| SORT event_count DESC
| LIMIT 10
| KEEP host.id, host.name, event_count

單一主機的噪訊事件：當你找出噪訊主機後，可使用此查詢進一步分析，找出造成大量事件的特定程序、指令列或檔案路徑。你可以在以下任何查詢中加入| WHERE host.id == "{HOST_ID}" 篩選，以聚焦單一主機的事件。

FROM logs-endpoint.events*
| WHERE host.id == "{HOST_ID}"
| STATS event_count = count(*) BY event.category, event.action, process.name, process.command_line, file.path
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, process.command_line, event.category, event.action, file.path, event_count

最噪訊的程序名稱：使用此查詢可找出在整個工作站群中，產生最多事件的應用程式或系統程序。

FROM logs-endpoint.events*
| STATS event_count = count(*) BY process.name
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, event_count

最噪訊的檔案路徑：使用此查詢可找出被頻繁存取或修改的檔案或目錄，通常代表日誌或暫存檔活動。

FROM logs-endpoint.events*
| WHERE event.category == "file"
| STATS event_count = count(*) BY file.path, event.action
| SORT event_count DESC
| LIMIT 10
| KEEP file.path, event.action, event_count

按程序名稱統計的前 10 大網路事件：使用此查詢可找出產生最多網路連線事件的程序，有助於辨識頻繁通訊的代理程式或服務。

FROM logs-endpoint.events*
| WHERE event.category == "network"
| STATS event_count = count(*) BY process.name
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, event_count

按檔案事件統計的前 10 大程序名稱：使用此查詢可找出產生最多檔案系統事件的程序，並將它們與網路或註冊表等其他事件類別區分開來。

FROM logs-endpoint.events*
| WHERE event.category == "file"
| STATS event_count = count(*) BY process.name
| SORT event_count DESC
| LIMIT 10
| KEEP process.name, event_count

步驟 2：精準事件篩選

利用前一步收集的資料，我們在 Elastic Defend 中使用事件篩選，直接在端點過濾特定事件，避免傳送到 Elasticsearch。這不影響惡意程式或端點防護，只能阻止不必要事件送入叢集，同時節省網路頻寬、磁碟空間和 CPU 資源。

篩選範例 1：Elasticsearch 檔案噪訊

在 Elastic，許多使用者會在工作站上自行安裝 Elasticsearch 進行測試或開發。隨著文件被寫入，Elasticsearch 會頻繁產生檔案事件，噪訊較多。每個篩選器依作業系統而異，可能需要針對不同 OS 建立多個版本。

以下是我們 MacOS 版本的事件篩選範例：

篩選範例 2：Linux 日誌檔修改

在 Linux 系統中，日誌檔會持續更新。此篩選器可排除所有.log 檔的修改事件，但仍會保留日誌檔的建立或刪除事件。

篩選範例 3: Docker 執行 ps

在 MacOS 系統安裝 Docker 時，Docker 後端程序會定期執行 ps 命令以取得容器資訊。我們的工作站群每月就觀察到超過 1.53 億次這類事件。此篩選器可將這些事件排除，降低噪訊。

小技巧：在設定篩選器時，可在 UI 的「備註（Comments）」欄位記錄篩選原因，並連結相關工單或調查報告，有助於長期維護。

步驟 3：端點效能最佳化

除了事件篩選外，也可透過 Elastic Defend 策略的進階設定，減少每個事件的大小與生成量，而不影響安全防護。有幾項功能能有效降低 Elastic Agent 的資料量。

禁用多餘雜湊

Elastic Defend 會為檔案事件與警示計算 MD5、SHA-1 與 SHA-256 雜湊。8.18 之前預設會收集三種雜湊，但 8.18 及更新版本預設僅保留 SHA-256。雜湊計算會消耗 CPU 與叢集儲存空間，而 SHA-256 已足夠。

若你使用 8.18 以前的 Elastic Agent，可在整合策略中禁用 MD5 與 SHA-1：

1. 進入 Integration Policies → Elastic Defend
2. 點選 Show advanced settings
3. 在 Windows/macOS/Linux event settings 中將以下值設為 false：
   • windows.advanced.events.hash.md5 / sha1
   • linux.advanced.events.hash.md5 / sha1 
   • macos.advanced.events.hash.md5 / sha1 

事件聚合

Elastic Defend 會自動將短暫的程序與網路事件合併成單一事件文件，避免每個程序產生多個 start、fork、end 事件。

此功能對快速啟動與關閉的程序很有用，8.18 及更新版本預設啟用，舊版本可透過進階設定 [linux|mac|windows].advanced.events.aggregate_process 開啟。我們發現啟用後，大幅降低事件量，且不影響事件調查。

成效與影響

經過這些設定，我們在效能與成本上都看到了顯著改善：

• 降低 CPU 使用率：不再為每個檔案事件計算三種雜湊
• 減少事件大小：每個 JSON 事件稍微變小，累計可節省大量儲存空間
• 事件量下降：每台主機每小時事件從 ~48k 降至 ~12k，噪訊減少 75%
• 成本節省：以 1KB/文件估算，4,000 台主機每天可減少 3.5TB 資料，每月約節省 100TB 儲存空間，省下數千美元（實際節省依設定與叢集環境而異）
• 改善訊號比：分析師看到的良性事件減少，更容易辨識真正威脅

結論

透過事件篩選與策略優化，我們提升了分析效率、降低成本，並保持完整的端點安全能見度。

將資安團隊視為「零號客戶」證明，積極管理噪訊與優化設定，能在不犧牲安全的前提下節省資源並改善效能。善用 ES|QL、Lens 與事件篩選，即可全面掌控端點資料與防護。

注意：本文描述的功能與發佈時程由 Elastic 全權決定，尚未提供的功能可能延後或不會發佈。

本文翻譯自：How Elastic Infosec Optimizes Defend for Cost and Performance

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

當企業持續優化投資、並將可觀測性的價值延伸至傳統 IT 之外，機會與挑戰也隨之而來。以下是 2026 年值得關注的趨勢。

想了解更多？點我報名 1/28【Elastic 2026 最新攻略：新功能亮點與未來方向速覽】！

加速可觀測性成熟度

企業的可觀測性成熟度明顯進展，這反映出企業在工具、專業能力、人才與組織文化上的大量投資，並逐步從單純監控轉向更全面的預測能力與可視性。

專家級企業已導入完整資料收集與現代化 AI 技術，成熟企業運用 AIOps 並建立或考慮設立跨部門卓越中心（CoE），正在發展的企業積極使用現代技術提升效率、擴展規模並進行根因分析，而少數企業仍停留在初期採用階段，主要依賴日誌資料。

推薦閲讀：Observability 3 本柱＋Profile 打造完整可觀測性解決方案

可觀測性成本管理

隨著可觀測性日益成熟，成本管理成為企業關鍵課題。研究顯示，97% 的企業曾遇過意外支出，其中 67% 定期發生，11% 頻繁出現。

成本驚喜與企業規模高度相關：員工超過 2 萬人的公司，有 18% 頻繁遇到意外成本，而員工 500–1,000 人的小型企業僅 4%。這些額外支出可能來自未計畫的資料量、雲端基礎建設突增、意外稽核或彈性授權模式等因素。

可觀測性預算趨勢

可觀測性支出的關注日益提高。超過 54% 的 IT 決策者表示，管理層要求更嚴格地說明相關費用。

企業對預算的規劃也因此出現變化：17% 視其為需新增投資的成長領域，13% 認為可觀測性已成熟，可進行成本縮減；大多數（70%） 則傾向優化現有支出，透過提升效率而非單純擴張或縮減。

整體而言，可觀測性已展現營運價值，但額外投資意願可能放緩。

企業的因應措施

企業正透過具體措施控制可觀測性成本，96% 的企業已採取行動。常見做法：

• 51% 合併現有工具套件
• 41% 在非關鍵系統使用低成本工具
• 37% 運用資料轉換工具
• 29% 將可觀測性工作負載從雲端移回內部部署

然而，部分策略可能增加風險或造成可觀測性空缺，例如只部署於關鍵環境（42%） 或減少代理程式 / 資料收集器數量 （33%）。這樣雖能短期降低支出，但非關鍵環境的問題可能進一步影響生產系統。

從營運指標到商業價值

在可觀測性實踐中，企業逐步將焦點從單純的營運指標擴展到商業影響，但大多數組織仍未完成這一轉型。

• 僅 17% 的觀測團隊專注於營運資料，例如服務水平指標（SLI）與服務水平目標（SLO）
• 24% 的受訪者將商業影響指標（如服務水平協議 SLA、營收影響與客戶體驗）提升到與營運資料同等重要
• 多數 (58%) 仍以營運指標為主，商業影響則被視為附加價值

報告實踐仍有落差：雖然 93% 的企業會以某種形式向管理層呈報財務與商業影響，但只有 19% 定期報告，多數偶爾報告（43%）或僅在要求時（31%）。

成熟度與報告頻率相關：專家級團隊中 47% 定期報告，成熟團隊 20%，進行中團隊 11%，初期團隊僅 5%。

實際能力也是挑戰：僅 40% 的企業能快速整理重大故障的完整財務與商業影響報告，約半數（49%）需投入大量時間，8% 則認為以現有能力無法完成。

可觀測性資料的普及化

可觀測性資料的使用範圍已超越傳統 IT 與雲端運維團隊。99% 的企業中，額外內部團隊也在使用可觀測性資料，其中 72% 支援三個以上核心 IT 以外的團隊。

在這些額外使用者中，資安團隊最為重要，佔 68% 的企業。可觀測性與資安的整合凸顯了兩者互補性：可觀測性資料可支援多種資安功能。最常見的應用包括：事件回應（61%）、警示關聯（53%）、零信任合規與稽核（45%）、即時合規監控（45%）以及稽核紀錄產出（40%）。

可觀測性與資安團隊之間的合作大致順暢，但仍有改進空間。僅 19% 認為關係不佳或存在問題，63% 則承認仍有優化餘地。隨著資安團隊對可觀測性資料的依賴增加，優化跨部門合作與流程變得至關重要。

滿足合規與治理需求

約 43% 的企業治理、風險與合規（GRC）團隊已開始使用可觀測性資料，顯示另一個重要趨勢：可觀測性平台逐漸支援法規與合規需求，提供稽核紀錄、支援法規報告，並證明符合各種合規框架。

這種擴展角色需要謹慎規劃資料治理、存取控制與呈現方式。不同利害關係者需要對相同資料有不同視角：例如，合規團隊需特定的控制效能證據，資安團隊需威脅情報，業務團隊則關注對客戶的影響指標。

成熟的可觀測性企業能更好地滿足這些多元需求。他們通常已建立完善的資料架構、存取機制與報告能力，同時維持適當的安全與治理控管。

可觀測性的策略意涵與結論

研究結果指出，可觀測性領導者需關注幾個策略重點：

• 成本優化：在不犧牲可視性或增加盲點的前提下進行。合併工具、優化資料量、提升基礎建設效率都是可行方法，但完全移除非關鍵環境的可觀測性可能帶來風險。
• 加速商業影響報告能力：目前多數企業缺乏快速呈現商業價值的流程與基礎架構，需透過文化變革與技術落實來建立能力。
• 資料普及化：跨團隊使用可觀測性資料可提升投資回報，但有效服務多元利害關係者需謹慎規劃資料治理、存取控制與客製化呈現方式。

可觀測性團隊需要從技術與營運專家轉型為策略性業務夥伴，包括理解商業指標、建立跨部門合作關係，並持續展示可觀測性投資對組織目標的支持。

能有效應對這些挑戰的企業──在不犧牲可視性的前提下控制成本、清楚呈現商業價值、滿足多元利害關係者需求──將把可觀測性打造為不可或缺的策略能力與競爭優勢。

過去一年觀察到的快速成熟趨勢顯示，部分企業已完成這一轉型，為其他組織樹立標竿。祝您的可觀測性團隊在新的一年持續成功！

本文翻譯自：Observability trends for 2026: Maturity, cost control, and driving business value

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

以 PostgreSQL / EDB Postgres Advanced Server（EPAS）而言，這常意味著實作 primary–standby 複寫、自動故障切換、備援監控、WAL 備份系統 等。

然而，多數企業在建置 HA 時，常忽略了另一個關鍵問題：資料庫監控與管理系統是否也需要高可用性？

EDB 所提供的 Postgres Enterprise Manager（PEM） 是許多企業監控 PostgreSQL / EPAS 的核心平台；一旦 PEM 當機，雖不影響資料庫運作，但企業將失去監控、警示、效能分析與自動化管理能力。

因此，讓 PEM 本身具備 HA 能力，是完整高可用方案中不可或缺的延伸。

為什麼需要 PEM HA？

PEM 在 EDB 架構中扮演以下角色：

• 集中式監控：收集所有 Postgres / EPAS、Barman、pgBouncer … 等資訊
• 告警（Alerting）：發出 Email、SNMP、Webhook 告警
• 效能診斷（Performance Diagnostics）

一旦 PEM Server 無法提供服務：

• 通知與告警中斷
• 監控與歷史趨勢資料中斷
• 自動化工作無法執行
• 監控代理 PEM Agent 無法上傳資料
• 管理者難以判斷高可用切換後的叢集狀況

對大型環境（>20+ DB instances）是一個不可忽視的風險。因此，在企業級資料庫環境中，為了實現完整的高可用管理鏈，PEM HA 是一個不可忽略的部署元件。

PEM HA 同地 / 異地架構概念

PEM 同地高可用架構的基本核心架構：

• 透過 streaming replication 將PEM Server 後端資料同步於 primary / standby
• PEM Server 使用虛擬 IP（VIP）提供單一服務入口點
• PEM Agents 全部指向 VIP，而不是指向單一 PEM Server
• PEM Server 故障切換後，PEM Agents 會自動重新連線

針對以上核心原則，PEM 同地 HA 架構會如下圖呈現：

説到這，其實你會發現 PEM HA 與資料庫的 HA 有著一模一樣的核心架構。

透過 EDB 提供的 Failover Manager，使PEM server 也可以綁定 Virtual IP 並且達成自動故障切換，進而減少因 PEM 故障而產生的 downtime 時間。

同樣的，PEM HA 與資料庫 HA 有著相似的特性 ：資料庫的高可用架構中，唯有 Primary 可提供讀寫功能在PEM 高可用架構中，所有的連線（包含Web UI）都只會指向 Primary。

那麼，PEM 可以達成異地高可用架構嗎？

值得補充的是，自 PEM 10.1 版本開始，PEM Server 在高可用架構上有了更彈性的部署方式。

以同地高可用架構為例，若要讓 PEM Server 本身具備高可用能力，通常會搭配 Failover Manager（EFM） 與 Virtual IP（VIP），形成 Primary / Standby 的雙機架構。然而，VIP 受限於 Layer 2 網段，無法跨區域使用，因此若想將 PEM Primary 與 Standby 部署在不同機房或地理區域，就會受到架構限制。

自 PEM 10.1 開始，PEM Server 支援 PostgreSQL 的 multi-host connection string，使 PEM Agent 以及 PEM 本身都能同時連接多個主機，進一步提升異地高可用的可行性。

這代表：

• PEM Primary 與 PEM Standby 可以分別部署在不同地區、不同網段
• 不再依賴 Virtual IP
• Agent 在 Primary 不可用時，可自動切換連線到新的 primary
• 整體架構更彈性，也能真正做到跨區域的高可用

實際架構看起來會像這樣：

PEM HA 同地 / 異地 實際測試

那麼，如何建立 PEM 監控的高可用架構呢？我們先來簡單介紹其組成元件。

• 兩台 PEM Servers
  • 主節點：PEM Primary (範例 ip → 172.16.1.76)
  • 備援節點：PEM Standby (範例 ip → 172.16.1.77)
• 資料同步
  • 建議使用 EDB 整合的 Streaming Replication
  • synchronous / asynchronous 取決於可用性 vs 性能
• Virtual IP
  • 透過 EDB Failover Manager 將 virtual ip (172.16.1.155) 綁定至各主機上
• PEM Agent
  • 透過資料庫主機上 PEM Agent 的設定來決定Failover 發生時資料庫該連向哪一個 PEM Server

PEM HA 同地 高可用架構（EFM + VIP）

將 PEM primary 設定好後，透過 streaming replication 將 PEM standby 也同步到 PEM primary 的資料，並且將兩個節點都加入到 Failover Manager 的叢集內，會呈現以下狀態：

可以看到我們已經將 virtual ip 透過 Failover manager 綁定到兩台 PEM Server，現在再到資料庫主機端的 PEM Agent 設定檔去修改要連線的 ip 。

上圖就是在資料庫端所安裝的 PEM Agent 的設定檔。

PEM Agent 欲連線的 PEM Server 的 ip 以及 port，還有其運作過程所產生的 log 的位址等設定都會存取在該設定檔裡面。

只需要將第一項設定 pem_host 修改成我們前面設定的 virtual ip,，將 PEM agent 服務重啟後，監控資料就能順利指向 PEM Server 所綁定的 virtual ip。

當 failover 狀況發生時，由於我們指向的目標 ip 是 virtual IP，無需手動更改資料庫連線的資訊，virtual ip 就會自行綁定至當前可提供服務的 PEM server。

以下嘗試將 PEM primary 的資料庫服務停止（systemctl stop postgresql-17）：可以看到 EFM 狀態顯示 PEM Primary 斷線，並且 EFM 自動將 standby promote 成 primary。

透過 virtual ip 去訪問 PEM web 介面，可以發現服務是依舊正常顯示：

這樣一來就成功驗證了 PEM 同地 HA 架構的可行性！

PEM HA 異地 高可用架構（EFM + Multi-host connection）

如前文所述，VIP 天生受到 Layer 2 網段限制，而無法跨區域部署。我們可以透過 PEM 10.1 版本之後支援的 multi-host connection， 來達成部署異地PEM的高可用架構。

基本上，唯一與同地高可用架構不同之處，就是 PEM Agent 端的設定檔案。

在修改設定檔案之前，我們先看當前 EFM 叢集狀態：

因為沒有額外綁定 Virtual IP 在資料庫的主機上，可以看到這次狀態的頁面在 VIP 的欄位是空白的。

接著就到 PEM Agent 設定檔，新增兩台 PEM Server ip 。

過去 PEM Agent 設定中，pem_host 欄位只允許一組 PEM server ip。但自 PEM 10.1 版本開始，該設定檔便支援了填入一組以上的 ip 。

現在只要將兩台 PEM server 的 ip 依照 primary >> standby 的順序填入後，PEM Agent 就會自行依照順序去尋找當前可供讀寫（當前 primary）的 PEM host， 進行後續的連線。

接下來，實際將當前的 PEM Standby promote 成新的 primary，並且觀察是否可以透過 PEM standby 進行連線。

透過 efm promote <叢集名稱> –switchover 將原先的 standby promote 成 primary：

由於 PEM HA 有著與資料庫 HA 相同的特性（連線一律指向 Primary），可以看到我們用 PEM 舊 primary ip 是無法訪問 Web UI 介面的：

相反的，這時就可以透過 PEM standby（新的 primary） ip 去做訪問：

這樣一來，我們也驗證了如何透過 multi-host connection 去達成 PEM 的高可用架構！

結語

在 PostgreSQL / EDB 高可用架構中，PEM 的角色比多數人想像中來得更加關鍵。若資料庫本身已經做到 PG / EPAS HA，但監控平台仍是單點，就等於整個 HA 架構仍有進步的空間。

透過引入 PEM HA：

• 整個 PostgreSQL 監控、管理、告警與自動化流程都能具備高可用性
• 真正達到企業級的完整資料庫 HA 生態

如果您的企業正在規劃或已經部署 PostgreSQL 高可用架構，建議下一步就是將 PEM 納入 HA 設計，讓整個系統達到更完整的韌性與可靠性。

文章參考資料：

[1]  EDB Official Document 

[2] https://www.enterprisedb.com/docs/pem/latest/considerations/ha_pem/#connections-must-go-to-the-primary

[3] https://www.enterprisedb.com/docs/pem/latest/considerations/ha_pem/#multi-host-connection-strings

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

這不僅僅只是工程效率挑戰，更是管理複雜度、風險控管與生產力的綜合議題。

近期，Let’s Encrypt 於官方社群發布即將調整憑證簽發與用途設計的公告（原始資料來源：Let’s Encrypt Community）。這些變化，正好與先前所討論的方向形成呼應，也進一步凸顯：

憑證管理，已經進入需要被制度化治理的階段。

Let’s Encrypt 官方公告

根據 Let’s Encrypt 的公告，接下來幾年將陸續推動以下關鍵調整：

憑證有效期持續縮短

TLS 憑證的生命週期，將從 90 天，逐步邁向更短的有效期限。這意味著憑證輪替不再是偶發事件，而是高度頻繁、不可中斷的日常流程。

憑證階層與用途更明確區分

Let’s Encrypt 正導入新的 Root / Intermediate 憑證架構，並同步調整 Extended Key Usage（EKU）策略。其中一個非常重要的改變是：Client Authentication（Client Auth）將不再是預設用途。

換句話說，未來若要使用 mTLS，就必須在設計與管理層面「明確宣告」這是一個 client 憑證的使用場景。

mTLS 不再是附帶功能，而是需要被治理的使用場景

這項調整背後的意義十分清楚：mTLS 不再只是「順便開啟」的安全功能，而是一種需要被清楚管理、定義與稽核的信任機制。

台灣金融業的 mTLS 管理視角

在台灣，金融業屬於高度監理產業，所有與資訊安全相關的設計與流程，皆需符合金管會（金融監督管理委員會）所訂定的監理與管理要求。

當 mTLS 被視為一項「需要被明確定義與管理」的安全機制時，實務上不只是工程選項，而會直接牽動：內部控制制度（內控）、內部稽核（內稽）、以及資安治理與風險管理。

金融機構常被要求清楚回答：

• 哪些系統使用了 mTLS？
• 哪些是 Server Auth？哪些是 Client Auth？
• 憑證從哪裡來？誰負責管理？
• 是否具備輪替、撤銷與稽核紀錄？

這些問題，都是治理層級的問題，而非單一系統設定。

製造業與半導體：同樣高度依賴 mTLS

在台灣的製造業與半導體產業中，mTLS 早已是關鍵基礎：

• 產線設備與後端系統的安全通訊
• MES、SCADA、設備控制平台
• 工廠與資料中心、雲端平台之間的信任建立
• 跨公司、跨供應鏈的 B2B 系統整合

在這些場景中，被驗證的對象同樣不是「人」，而是系統、服務與設備本身。

什麼是機器身份（Machine Identity）？

所謂的機器身份，指的是：任何需要被系統信任，並能自主與其他系統進行通訊的非人類主體。

這可能是：後端 API 或微服務、一個 Kubernetes Pod、一條產線設備、或是自動化排程或整合流程。

這些元件不會輸入帳號密碼，但仍必須被驗證「你是誰」。

機器身份，早已存在我們的系統

以 Kubernetes 為例：

• Pod 透過 Service Account 向 API Server 驗證身份
• Service Account 搭配 RBAC 控制權限
• Pod 並非使用人員帳號，而是系統身份運作

同樣概念，也廣泛存在於 API、設備與系統整合中。

為什麼 mTLS 與 client certificate 成為核心載體？

在 mTLS 架構下，client certificate 提供明確且可驗證的系統身份，不依賴人工輸入，並可設定用途、期限與撤銷機制。

這些特性使其特別適合金融業的內控與稽核需求、製造業設備長期穩定運作，以及大量系統身份並存的環境。

真正的挑戰：不是憑證變短，而是管理方式跟不上

當憑證有效期縮短、mTLS 成為常態，企業實際面臨的是：

• 憑證數量快速增加
• 人工作業風險放大
• 稽核與追蹤成本提高

此時，問題已不在於「要不要用憑證」，而是：是否具備一套能長期運作、可治理、可自動化的管理方式？

為什麼需要一個憑證與機器身份管理工具？

正如 上一篇文章 中所提到的，當憑證不再只是少量靜態資源，而是大量、短效、持續輪替的系統身份載體時，企業自然會開始思考：

• 如何集中管理憑證生命週期
• 如何降低人工介入
• 如何讓流程符合內控與稽核需求

在這樣的背景下，像 HashiCorp Vault 這類工具，並不是被「推銷」進來的，而是在複雜度自然上升後，被用來承接管理責任的解法。

Vault 協助企業集中管理憑證與機器身份，自動化簽發、輪替與撤銷流程，並提供完整稽核與追蹤紀錄。

這正好回應了 Let’s Encrypt 政策變化、mTLS 治理需求，以及金融與製造產業的實務挑戰。

結語

Let’s Encrypt 的調整，並非單一技術事件，而是整個 TLS 生態系走向：短效憑證、明確用途、可治理的信任機制。

無論是受金管會監理的金融業，或高度自動化的製造業與半導體產業，mTLS 與機器身分管理都已成為營運與治理能力的一部分。

關鍵不在於是否採用新政策，而在於：我們是否已準備好一套，能長期承接這些變化的管理方式。

當憑證有效期持續縮短、mTLS 成為需要被明確治理的使用場景，企業勢必要有一個能集中管理憑證與機器身分的核心平台，來承接這些持續發生的變化，而不是仰賴零散腳本或人工流程。

在實務上，越來越多企業選擇以 HashiCorp Vault 作為這個承接點，將憑證的簽發、輪替、撤銷與稽核紀錄納入同一套管理機制中，讓 mTLS 與機器身分不再只是「能運作」，而是可治理、可追蹤、可長期維運。

這並不是為了因應某一次政策調整，而是為了讓企業在憑證生命週期持續縮短、系統身分數量不斷成長的環境下，依然能維持安全、穩定與管理上的可預期性。

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