从数据孤岛到智能洞察：构建面向未来的 Operation intelligence 体系

news/2025/10/24 15:49:10/文章来源:https://www.cnblogs.com/alisystemsoftware/p/19163597

作者：孙廷韬（龙悟）

从数据孤岛到智能洞察：构建面向未来的 Operation intelligence 体系

在数字世界持续运转的过程中，系统每时每刻都在产生海量的数据。我们把这些数据统称为 Operation Data（运营数据）。它不仅记录着系统的运行状态，更蕴藏着驱动业务增长、保障系统稳定、防范安全风险的关键线索。更重要的是，这些数据不仅是“可观察”的，更是“可智能”的。研发工程师、运维人员、安全专家和业务决策者，正在围绕这些数据挖掘数字价值，沉淀行业智慧。今天的分享，我们聚焦于 Operation Data 的核心特征、落地挑战，以及我们如何通过系统性方法构建真正的 Operation intelligence 能力。

当前企业的关键数据主要来自三大维度，每一类都承担着独特的角色：

技术数据 —— 系统的“心电图”： 这是最基础也是最丰富的数据来源，包括日志、指标、链路追踪、事件告警等。它们如同系统的生命体征，实时反映集群水位、数据库负载、服务调用稳定性等关键状态。这类数据的核心目标是：保障业务稳定运行。它是运维团队最关注的信息源，也是系统可观测性的基石。
业务数据 —— 企业的“增长引擎”： 涵盖用户行为、交易流程、营销活动反馈、客户管理（CMR）等数据。通过这些信息，我们可以实时评估一次运营活动拉新了多少用户，某个新功能上线后用户的使用情况如何，是否存在用户流失风险。这类数据直接关联商业结果，决定了产品迭代方向与市场策略有效性，是驱动业务增长的核心动力。
安全数据 —— 企业的“免疫系统”： 包括安全日志、访问控制记录、入侵检测告警等。它们帮助我们识别异常登录、可疑操作、潜在攻击行为，及时发现数据泄露或内部违规风险。安全数据的价值在于防患于未然，确保企业在合规的前提下稳健发展。

尽管每一类数据都有其重要性，但我们必须认识到：孤立看待某类数据所获得的洞察，往往是片面甚至误导的。真正的价值，在于让不同维度的数据彼此连接、相互印证。例如：

当我们识别出某些关键用户时，能否结合他们的业务行为与技术体验，为他们提供更高优先级的服务保障？
在一场促销活动中，是否可以通过融合业务流量激增与异常登录模式，快速识别“羊毛党”的薅取行为？
当系统出现性能波动时，能否同时分析基础设施指标、用户投诉反馈和安全访问日志，精准定位根因？

只有当技术、业务与安全数据实现深度融合，我们才能从“被动响应”走向“主动预判”，真正实现以数据驱动智能决策。

回顾过去，我们在数据处理方式上经历了几个典型阶段：

手工时代 —— “救火队员”式运维： 早期，问题排查依赖人工登录跳板机、翻查日志、逐项验证。每个人都是“救火队员”，响应滞后，效率低下，且高度依赖个人经验。
脚本时代 —— 初步自动化： 通过编写监控脚本，我们将部分判断逻辑固化，实现了对已知问题的主动发现。但随之而来的是“告警风暴”——大量低价值信息淹没关键信号，团队疲于应对。更重要的是，脚本只能覆盖已知场景，对未知问题无能为力。
平台化时代 —— 物理聚合，逻辑割裂： 随着各类数据平台的建设，数据得以集中存储，“取数难”的问题得到缓解。然而，多数平台仅实现了数据的物理汇聚，并未完成语义打通。跨域分析仍需专家手动关联，沟通成本高，分析周期长，难以支撑实时决策。
AI 智能时代 —— 打破认知壁垒： 如今，AI 为我们提供了全新的可能性。我们不再满足于“人找问题”，而是希望“AI 帮人发现问题”，甚至“AI 发现人从未想到的问题”。

但要实现这一跃迁，我们必须正视一个现实：原始数据本身并不适合 AI 处理。为了更好地利用 AI 能力，我们需要深入理解三类数据的本质特征：

数据类型	核心特征	典型挑战
技术数据	高频、海量、持续生成	单日日志可达PB级，信噪比极低
业务数据	易变、以人为中心、结果导向	架构频繁变更，字段语义不一致
安全数据	稀疏、对抗性强	攻击行为隐藏在正常流量中，难以识别

尽管来源各异，这三类数据却有着共同痛点：数据量巨大但信息密度低、变化迅速，模型难以适应、缺乏上下文，单条记录难以判断意图。而 AI 模型恰恰要求输入数据具备高相关性、清晰语义、简洁表达。当前大多数原始数据远未达到这一标准。当我们试图将 AI 应用于运营场景时，会面临三重挑战：

数据鸿沟： 原始数据混杂、碎片化、噪声多，99% 以上可能是无效信息。AI 无法从中有效提取信号。
模型鸿沟： 模型存在“黑盒”特性，推理过程难以解释；还可能出现“幻觉”，生成看似合理但不符合事实的结果。
工程鸿沟： 每天数 PB 级的数据采集、清洗、存储、计算，对性能、成本、安全性提出极高要求。

这些问题环环相扣，形成了 AI 在实际应用中的“价值断点”。若仅从单点突破，难以根本解决。

破局之道：构建系统性的“数据炼金术”

要跨越这道鸿沟，我们需要一套系统性的方法论——我们将这个过程称为 “数据炼金”，就像从矿石中提炼金属一样，把低密度的原始数据转化为高价值的智能信号。这一过程包含三个关键步骤：

统一底座 —— 构建融合的数据平台

一切智能的前提，是一个统一、可靠、高性能的数据存储与处理平台。我们打造了基于分布式架构的可观测性基础设施，全面支持日志、指标、追踪等多模态数据的实时接入与持久化。自去年起，已在全量环境中升级至三可用区（3AZ）高可用架构，保障数据安全可靠，且对用户透明、零额外成本。

今年，我们将推出 UModel 建模机制，支持跨数据域的语义关联与统一建模，真正打破数据孤岛。

深度提炼 —— 提升信息密度

原始数据需要经过多层次加工，才能成为 AI 可用的高质量信号：

结构化提取：通过模式识别与解析技术，从非结构化日志中抽取实体、指标、事件等关键信息；
上下文补全：结合领域知识，将技术 ID（如trace_id）与业务 ID（如user_id）进行精准映射，丰富数据语义；
语义增强：利用 Embedding 技术生成向量表示，支持自然语言级别的语义检索，新数据写入后 10 秒内即可被语义搜索命中。

当数据拥有了完整的上下文和语义表达，后续分析才具备意义。

生成智能信号 —— 激活 AI 潜能

经过融合与提炼后的数据，构成了 AI 模型的理想输入。此时无论是异常检测、根因分析，还是趋势预测与风险预警，AI 的准确率都将显著提升。我们正致力于打造“先见之明”的能力体系——让系统不仅能发现问题，更能预判问题、解释问题、推荐解决方案。

为了支撑上述理念，我们打造了端到端的一站式可观测平台日志服务 SLS。它的核心愿景是：提供一个“上帝视角”——所有你需要的数据，都在同一个地方，随时可查、可联、可析。这意味着：不再需要在多个系统间跳转拼接；一条查询语句即可横跨日志、指标、调用链完成关联分析；分析过程无需手动整合，平台自动完成上下文对齐与语义打通。这不是一次简单的功能升级，而是一场思维方式的根本变革。我们正从“规则驱动”的自动化时代，迈向“数据驱动 + AI 增强”的智能时代。在这个过程中，数据不再是被动记录的结果，而是主动创造价值的源泉。未来属于那些能够更快感知、更深理解、更早预见的企业。而我们所构建的，正是这样一个让组织具备“数字第六感”的智能基础设施。

构建一体化可观测平台：让数据真正“可查、可联、可析”

在上一部分中，我们阐述了运营智能（Operation Intelligence）的核心理念——通过融合技术、业务与安全三类数据，实现从被动响应到主动洞察的跃迁。而要支撑这一愿景，必须有一个强大、统一、智能化的数据底座。

接下来，我们将深入介绍我们在平台能力建设方面的具体实践：如何打造一个真正具备“上帝视角”的一站式可观测平台。

统一存储：构建高可用、高性能的数据基石

自去年起，我们的 SLS 已在所有支持环境中全面升级至三可用区（3AZ）高可用架构，确保数据跨地域容灾、持久可靠。整个过程对用户完全透明，且不产生额外费用。在此分布式存储基础上，我们实现了多源数据的实时采集与处理：支持开源 Agent 接入；兼容多种自定义数据格式；数据毫秒级汇聚至平台中心。不同类型的观测数据（日志、指标、链路、事件等），会根据其特性和使用场景进行分层存储，做到“按需存储、高效利用”。今年，我们进一步推出统一数据建模机制，支持将分散的数据源进行语义级关联与建模，为后续的融合分析打下坚实基础。与此同时，我们常说：“存不好，取不快，后续计算再强也难发挥价值。” 面对异构、高频、海量的数据挑战，单一存储方案无法满足全场景需求。因此，我们设计了多种存储与索引策略，适配不同工作负载。

倒排索引： 支持千亿级日志秒级检索。针对非结构化日志数据，采用倒排索引技术，实现关键词快速定位。即使面对 PB 级日志规模，也能做到查询响应在秒级内完成。
内存加速层： 满足高并发、低延迟分析需求。对于需要实时聚合与大规模分析的场景，我们将热点数据缓存在内存中，显著提升复杂查询性能。
向量索引： 原生支持语义搜索。AI时代对数据的理解提出了更高要求。我们原生集成 Embedding 能力，在数据写入时自动完成向量化，并以向量形式存储。新数据写入后 10 秒内即可支持语义检索，让自然语言查询成为可能。
实时引擎优化： 应对持续高吞吐压力。针对长期运行的海量高吞吐数据流，我们对底层实时数据引擎进行了深度优化：内置压缩与降采样机制；全链路性能调优；显著提升写入吞吐与读取效率。

此外，图存储与上下文关联为 AI 提供推理基础。除了传统存储方式，我们也引入了图存储能力，重点解决“上下文缺失”问题。只有当数据之间建立起语义联系，AI 才能真正理解其背后的意义。例如，通过关联用户的设备、IP、账号、行为等信息，我们可以将原本孤立的安全告警或技术故障点串联成完整的攻击链路或故障传播路径，极大增强 AI 在异常检测与根因分析中的推理能力。这也正是我们数据建模能力的核心所在——不是简单地把数据放在一起，而是让它们“彼此认识”。

智能计算引擎：兼顾深度分析与极致实时

有了强大的存储系统，下一步是构建灵活高效的计算引擎。我们面临两类典型需求：涉及海量数据、复杂计算，要求结果绝对精确的深度分析型任务，以及如 Dashboard 展示，强调低延迟、高响应速度的实时交互型任务。为此，我们在计算层做了多项关键升级：

完全精确模式：打破资源限制，保障结果完整性。过去，为了控制资源消耗，查询常被设置各种底层限制，导致结果可能“少算一条”。但在深度分析场景中，哪怕遗漏一条记录，结论都可能失真。我们重新抽象这个问题，取消原有的各类资源约束，仅保留最长执行时间限制（默认 10 分钟）。在此范围内，系统可在大集群中将任务拆分为数千个子任务，以 Pipeline 方式分布式执行，最终返回完整、准确的结果。
自动物化视图：实现 Dashboard 性能数量级提升。对于高频访问的 Dashboard 或固定分析模板，我们推出了自动物化视图功能。数据流入平台的同时，系统会自动预计算并生成中间结果，持久化为物化视图。当用户发起查询时，引擎智能判断是否可复用已有结果，并将其与原始数据动态融合。这意味着：用户无需修改任何 SQL 或手动管理物化表；查询仍面向原始数据编写；平台自动完成加速。实际应用中，部分客户配置的 Dashboard 涉及十几个图表，每个需处理超 200 亿条数据。以往加载缓慢，体验极差；启用物化视图后，延迟降低达 1~2 个数量级，用户体验大幅提升。

统一建模：让 AI 看懂“完整的故事”

真正的智能，不是识别单个异常，而是还原事件背后的完整逻辑。举个例子：一位用户多次异地登录失败后，在一台从未使用过的设备上成功登录，随后疯狂调用航班查询接口，短时间内拉高数据库 CPU，最终兑换了一张高价机票。单独看这三个事件：

安全日志：异地登录 → 可疑？
技术指标：API 调用量突增、CPU 升高 → 故障？
业务数据：里程兑换机票 → 正常交易？

每一条都无法独立定性。但如果我们能通过统一建模，把这些碎片拼成一张完整的图谱：“一个陌生设备登录 → 大量扫描航班信息 → 快速兑换高价值机票”这就构成了典型的“盗刷里程”攻击链条。这正是我们构建统一模型层的意义所在。它包含三个核心部分：

实体建模：定义用户、设备、会话等核心对象；
可观测数据建模：描述各实体产生的日志、指标、链路等；
关系建模：刻画实体间的调用、归属、行为序列等关联。

整个建模过程虽由人工设计，但主要服务于 AI 推理。它是上下文补全的基础，也是实现跨域分析的前提。

统一查询语言 SPL：打破数据孤岛的最后一公里

即便有了统一存储和模型，如果查询仍需切换多种语法、跨多个系统操作，效率依然低下。我们推出的 SPL（Search Processing Language）正是为了终结这一痛点。它是一个统一入口，屏蔽底层差异，支持对日志、指标、追踪、图数据、实体模型等多类型数据进行一体化查询。更重要的是，SPL 不只是一个查询语言，更是一种能力贯穿体系：在数据采集阶段，可通过 SPL 提前做字段提取、正则解析、结构化转换，减轻下游处理负担；在 Flink 消费时，可将数据处理逻辑下推至平台侧，获取高度规整的结构化输出；在前端展示时，同一语句可用于生成时序图、热力图、拓扑图等多种可视化形式。不仅如此，SPL 还具备强大扩展性：可调用外部函数；支持接入大模型进行辅助判断；支持图形渲染、异常检测等高级分析流程编排。例如，一段 SPL 脚本可以从日志中提取关键事件 → 生成时序曲线 → 自动检测异常点 → 渲染为可视化图表，全流程自动化完成。

让我们回到最初的“盗刷机票”案例，看看在统一平台下的处理效率有多高。只需一次 SPL 查询：读取嫌疑人用户实体档案，获取其常用设备、登录习惯；--> 关联其当前登录行为、API 调用频次、订单操作记录；--> 判断是否存在异常登录 + 高危操作组合；--> 将结构化行为序列输入大模型，辅助生成研判建议。

整个过程无需跨系统协作、无需多个团队联动，从发现到分析再到决策支持，仅需几分钟。相比过去依赖多个工具、多人协同的“救火式”处理，效率提升不止一个量级。