【腾讯蓝鲸社区活动】嘉为蓝鲸吴文豪详解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. 当前的局限

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

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