官网原文（免费申请演示）：【腾讯蓝鲸社区活动】嘉为蓝鲸吴文豪详解BlueKing Lite：轻盈与智能的运维之旅

在过去三年，我们与近百家企业深度交流后，发现了一个现象：运维领域有很大一片需求空间，还没有被很好地满足。而这，正是我们希望去解决的问题。今天分享的不仅是一个新产品——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. 当前的局限

今天是“可用态”的里程碑，不是“完全体”的终点。我们的方向是清晰的，关键路径已被验证，核心骨架稳定运行。但要达到心中的“完全体”，还需要把更多真实场景做深做透，把性能与体验深度打磨。

未来，团队将每周同步产品改动与计划，确保每次更新都能带来用户可见的提升。