在過去三年，我們與近百家企業深度交流后，發現了一個現象：運維領域有很大一片需求空間，還沒有被很好地滿足。而這，正是我們希望去解決的問題。今天分享的不僅是一個新產品——BlueKing Lite，還有我們對“運維工具該往哪個方向演進”的思考。接下來，我將圍繞BlueKing Lite的核心洞察、價值主張、關鍵特性以及技術實現等方面展開，為大家介紹BlueKing Lite這一新產品。

以下內容整理自：騰訊藍鯨BKLite PMC 成員 吳文豪于「騰訊藍鯨社區活動：穩定筑基·輕量演進 邁向韌性、敏捷的下一代運維」的精彩分享——《BlueKing Lite：輕盈與智能的運維之旅》。

01. 問題發現

在過去許多年，運維軟件的演進?向?直很明確：讓?個?管理更?規模的資源。數據中?的建設、?數據、云計算——每?次技術浪潮的背后，都是業務規模的爆發式增?，業務在擴張，設備就在增加。正是這種持續增?的壓?，驅動著運維軟件不斷演進，去解決“如何管更多”的問題。集中化、?動化，成為這個階段的主旋律。

直到今天，運維軟件已經可以?效管理數據中??的上萬臺服務器。 但在與企業的深度交流中，我們發現了三個被?期忽視的現象。

1）現象?：規模小，問題不一定簡單

在此之前，我有一個問題：管50臺服務器和管5000臺服務器，哪個更簡單？

我猜大多數答案會是50臺。但實際情況是，管50臺服務器的團隊，面對的問題復雜度并不比管5000臺的低多少。他們要面對更緊張的硬件資源、更有限的人手以及更高的學習時間成本，且業務對穩定性和響應速度的要求并沒有降低。因此，我們認為小規模場景并非大規模場景的“縮小版”，而是一種約束條件完全不同的特殊場景。

進一步分析，導致“小規模不簡單”的原因主要體現在以下三個維度：

• 硬件資源維度：為大規模場景設計的運維平臺往往對資源要求很高，動輒需要128G內存起步的服務器才能跑起來。把這樣的平臺交給只管50臺服務器的團隊，會發現平臺本身消耗的資源，可能比他們要管理的所有服務器加起來還多。
• ??資源維度：大規模團隊可以配專人維護平臺、調優性能、培訓新人。小規模團隊往往只有一兩個運維人員，既要保業務穩定，又要學新平臺，還要處理日常瑣事。
• 時間成本維度：?規模團隊可以花兩三個?慢慢上線、逐步遷移，?規模團隊的業務壓?需要快速見效。

這三個維度揭示了同一個本質：規模變小了，但是問題的復雜度并沒有按比例下降。業務對穩定性的要求還是那么高，但硬件、人力、時間等方面的可用資源都大幅縮水。

2）現象二：完整的體系，有時反而是障礙

為大規模場景設計的一體化運維平臺通常都很強大，能夠實現CMDB、配置管理、作業平臺、監控告警等工具的閉環。但在小規模運維場景中，若想輕裝上陣，功能太全反而成了負擔，想盡快用起來，學習成本又較高。

為什么會出現這樣的現象呢？首先我們知道，完整體系的設計邏輯是：先建地基，再蓋房子。CMDB是地基，監控、告警、作業都是房子。管理一萬臺服務器，沒有CMDB做資產管理，后面確實會一團糟，所以這個邏輯在大規模場景下沒問題。

但在小規模場景下，一個運維?程師管50臺服務器，他清楚每臺服務器的用途。他現在就想把監控跑起來，看到數據，解決眼前的問題。CMDB對他來說，是“未來可能需要”，但絕不是“現在必須有”。

由此，為?規模設計的“正確架構”，在?規模場景下變成了“使??檻”。

3）現象三：AI帶來新可能，工具還沒跟上

隨著業務復雜度的提升，運維團隊??的?具越來越多，每個?具都要學習、切換、操作，人的認知負擔在不斷增加。

在過去的時間里，我們?直在做“自動化”。寫腳本、做集成、建統一門戶。但自動化有個根本限制：需要預先定義好每一步。遇到新情況，就要寫新腳本、改流程、加判斷。這就像給每個場景寫一本操作手冊，手冊越寫越厚，但永遠寫不完。

大模型的出現，讓我們看到了不同的可能。不需要再預先定義每一步，而是告訴AI“我要達到什么目標”，AI自己去調用工具、處理異常、完成任務。這不是自動化的升級版，這是交互方式的代際躍遷。但我們也發現，開源社區里，極少看到在設計之初就為“被AI調用”而設計的運維系統。

這就是第三個現象：AI帶來了新的可能，但運維工具還沒準備好。

02. 核心洞察

上述的三個現象，一開始看起來挺分散的，有的關于規模約束，有的關于架構設計，有的關于技術演進。當我們深入思考后，我們有了三個對新一代產品形態的洞察：

• 約束變了，最終解會反轉：

資源充足時，為大規模優化的架構是對的。資源受限時，面臨硬件緊張、人手不足、時間壓力等情況，這個時候，同樣的架構從高效變成負擔。由此，我們需要重新設計，不是調參數，而是換思路。

• 解耦不是降低標準，是承認現實：

完整體系強制先后順序，但現實場景天然碎?化。需要讓模塊獨??作，?組合應對多樣性。

• 不是造?具，是造AI??：

過去為?設計界?，現在為AI設計能?。AI不需要精美界?，?不再直接操作?具。應在設計之初就為AI設計，不是改造現有?具，?是重新設計以能力優先的系統。

有了這三個洞察，我們就清楚，需要在一個新的約束條件下重新設計運維系統。

03. 價值主張

基于以上三個洞察，我們提出了BlueKing Lite的三個核心價值主張，這三個價值主張，就是我們對“運維工具該往哪個方向演進”給出的答案。

1）輕量化：在資源約束下重新設計

我們將傳統運維平臺與BlueKing Lite進行對比，直觀感受輕量化帶來的優勢。

以“經典運維平臺”為例，其自身運行所需的內存資源往往需要128G內存。這類平臺通常為應對大規模的業務場景而設計，對小規模團隊而言，平臺本?消耗的資源，可能?他們要管理的所有服務器加起來還多。

而BlueKing Lite 能夠將自身資源占用大幅優化至4核CPU和8GB內存的水平。這并非通過“裁剪功能”實現，而是秉持“既然硬件約束變了，架構設計就要跟著變”的理念，通過選用和重新搭建更?效的組件，降低資源占用的同時，依然能夠跑通完整的運維功能。

2）漸進式：從任何起點開始，按需演進

傳統平臺強制“先建CMDB，再裝監控”，這是在假設??的演進路徑是統?的、可預設的。但現實是碎?化的。 有?急需監控，有?先要?志，有?想做批量操作。強制統?起點，本質上是?架構的便利性，綁架??的使??式。

BlueKing Lite的做法是：每個模塊獨??作，從哪?開始都可以，按需演進。

它打破了傳統模式的束縛，用戶可以根據自身的實際需求和運維現狀，自由選擇從任何一個模塊開始使用，實現服務的彈性擴展。其中，每個模塊都能獨立部署、獨立運行，用戶可以根據具體需求靈活地選用和組合功能，避免了不必要的資源浪費和功能冗余。用戶可以在需要時才逐步增加功能，避免一次性面對繁雜的系統。運維復雜度和學習曲線也能夠隨著實際需求而逐步提升，使得用戶始終處于可控的學習成本之內，大大降低了上手門檻。

3）AI First：把?具設計成“AI 的?具箱”

傳統模式中，工具是為了人而生，AI只是模擬人類操作圖形用戶界面，工具界面力求美觀、操作舒適，以適應人類直接操控的需求，其功能和交互邏輯仍然基于人類使用習慣構建。

但?具的主要用戶正在從?變成 AI。

然而，隨著人工智能的飛速發展，我們必須認識到，未來運維的核心交互將是人與智能體之間，而非人與工具本身。這意味著工具將不再遷就人類的操作習慣，而是要遷就AI的調用需求。因此，我們的設計思路需要轉向“工具遷就 AI”。不是讓AI學會使??的?具，?是讓?具天然就能被AI理解。運維?程師不再是?具的操作者，?是AI的指揮者。

04. 關鍵特性

圍繞這三個價值主張，我們在產品設計上做了五個關鍵特性的選擇。

1）邊緣?治：從“中心化的脆弱”到“自治化的健壯”

在傳統的中心化運維架構中，邊緣側Agent的職責僅限于數據采集與上報，核心處理能力高度集中于中心端。這種模式在網絡狀況良好時尚能支撐，一旦遭遇網絡中斷，整個運維鏈條就斷了。現場沒有分析工具，運維無工具可用，只能靠經驗盲查，出現“網絡中斷=運維中斷”的惡性循環。這就是中?化架構的脆弱性：邊緣側沒有獨?的運維能?。

所以，我們換了個思路，讓每個站點完全自治，保證在網絡中斷時，運維“不中斷”。

邊緣自治架構通過在每個站點部署完整的BlueKing Lite服務，使其具備本地化的運維能力。即便網絡中斷，邊緣自治節點仍可獨立完成監控、告警及數據分析等核心運維任務。?絡斷了，告警繼續跑，數據繼續存，分析繼續做。即使在網絡故障時，現場運維人員依然能夠依托本地服務進行操作與排查，有效避免運維中斷，打破對中心網絡的強依賴性。

2）持有成本低：能耗?的改善

過去?年，開源社區在基礎組件領域的演進?向很明確：更好的性能，更優的成本。?家都在朝著提升能耗?這個?向做設計，確保即使在有限的資源配置下，系統也能穩定、高效地運行。時序數據庫、?志引擎、圖數據庫、消息隊列等運維系統依賴的基礎組件，都在持續優化資源消耗與處理能?的?值。

因此，我們選擇了能耗?更優的技術，按照我們的架構理念——運維軟件不應該有那么?的開銷和持有成本，進行重新組裝。

具體來說，日志處理選擇新一代引擎，在保持檢索性能的同時降低存儲成本；監控指標選擇?效時序數據庫，保證查詢速度的同時降低寫?壓?；CMDB選擇圖數據庫，多層關聯查詢不再是性能瓶頸；部署?式基于容器編排，資源調度、故障?愈能力無需自建。

這不是某個單點的突破，是整個技術棧能效?的系統性改善。我們站在社區的肩膀上，把這些改善整合到了產品?。

3）漸進式體驗：弱耦合的關聯設計

前?講到完整體系會成為使用?檻，其原因在于傳統平臺的強耦合。傳統設計模式下，模塊之間存在必然的強依賴關系，當用戶想要啟用某個特定模塊時，必須首先建立完整的依賴鏈條。在大規模場景下，資產關系復雜，強制關聯能夠保證數據一致性。但這種“牽一發而動全身”的設計理念，讓用戶在初次接觸或希望快速應用某個功能時，不得不面對復雜的配置和前置條件，這提升了產品的使用門檻。

為此，BlueKing Lite采用了“弱耦合”的關聯設計，每個模塊可以獨?交付價值，關聯式可選地，不是必須的，降低了使用的復雜性。例如：當用戶啟用CMDB后，監控能力將自動得到增強，實現更精細化的管理和洞察。但即使不啟用CMDB，基礎的監控功能依然可用。

這種設計使得用戶可以根據實際需求，逐步引入和配置模塊，無需一次性完成所有設置。每?步都?即有?，學習成本始終可控。這種循序漸進的體驗，讓用戶可以在探索和使用的過程中，不斷積累經驗，逐步深化對系統的理解和應用，從而實現更高效、更愉悅的運維旅程。

4）智能化：能?優先的?具設計

BlueKing Lite的設計邏輯，是構建一個能夠驅動OpsPilot智能體高效完成運維工作的平臺。為此，我們聚焦于能力優先的工具設計，旨在將運維工程師的經驗和技能轉化為可復用的數字能力，賦能智能運維。具體通過以下路徑來演進：

• 明確運維職責邊界：明確運維工程師在“故障排查、巡檢、應急響應”等核心場景的日常職責。
• 能力原子化抽象：將運維工程師的職責進一步細化為一系列原子操作，如“查監控、搜日志、翻拓撲、執行腳本”等。
• 能力服務化注冊：將這些原子化能力，如“監控”、“日志”、“CMDB”和“作業”等，統一注冊到NATS服務總線。
• OpsPilot 智能體賦能：通過獲取并調動服務總線上的各類能力，OpsPilot 智能體將不再是冰冷的程序，而是能夠模擬人類運維工程師的思維和操作，進化為“智能運維工程師”。

通過這種“能力抽象——服務總線集成——智能體賦能”的邏輯流，致力于讓OpsPilot智能體結合自身工作職責和所獲取的各項能力，掌握運維核心技能，實現智能運維，從而提升效率，降低人工介入，并保障系統穩定性。

5）?態化：為社區伙伴預留設計

當前運維系統品類豐富，為了匯聚更多社區力量共建生態，BlueKing Lite在設計之初就做了預留規劃。我們采用基于NATS的服務接入方式，簡化貢獻流程：開發者只需實現對應能力接口并注冊到服務總線，即可快速參與到BlueKing Lite的生態建設中。這種低門檻的接入模式，能有效降低社區伙伴的參與成本，讓更多人輕松加入，推動BlueKing Lite生態持續繁榮。

05. 技術實現

接下來，我們來看看這些特性在技術層?是如何實現的。

BlueKing Lite的架構核心思路是 “90%成熟技術棧+10%創新”。90%都是像S3、Redis這類經典基礎設施，以及采集、監控、日志這些相對簡單的成熟鏈路，數據采集后會分發到對應存儲組件，整體結構并不復雜；而那10%的創新，正是針對未被滿足的需求做的技術洞察與架構設計，這也是BlueKing Lite的核心價值所在，比如我們用來構建智能體的智能服務模塊，就屬于這部分創新。

06. 當前的局限

今天是“可?態”的?程碑，不是“完全體”的終點。我們的?向是清晰的，關鍵路徑已被驗證，核??架穩定運?。但要達到?中的“完全體”，還需要把更多真實場景做深做透，把性能與體驗深度打磨。

未來，團隊將每周同步產品改動與計劃，確保每次更新都能帶來用戶可見的提升。