AIOps实战04：一款AIOps平台该具备哪些功能，一份产品视角的功能全景

我是老计。前面三篇，我们从技术和认知的角度讲了 AIOps 是什么、能做什么、两代怎么融合。从这一篇开始，进入一个不太一样的板块：产品与需求视角。 我们换个身份来看 AIOps,不再是使用者或技术研究者，而是站在做产品、选产品、评估平台的角度问一个很实在的问题：一款完整的 AIOps 平台，到底该具备哪些功能？

为什么要专门讲这个？因为无论你是要参与内部 AIOps 平台的建设、要给公司选型一款商业产品、还是自己想做一个运维 AI 工具(像我做 K8sChat 那样),你都需要一张清晰的功能地图，知道一款像样的 AIOps 该长什么样、每块功能要满足什么。这一篇，我就带你梳理这张功能全景图，风格会偏向一份可读的功能规格。 这一篇讲全景和每块的核心需求，下两篇再挑核心模块写更规范的需求描述。

一，为什么要有产品视角

先说清这个视角的价值，免得你觉得这是务虚。

做技术的人，常常一头扎进算法和实现，却说不清楚自己要构建的东西整体上该是什么样。 结果就是，做出来的东西东一块西一块，缺乏整体设计，或者盲目跟风堆功能、堆了一堆用不上的花架子。产品视角，就是逼你先跳出来，从要解决用户什么问题、该提供哪些能力、每个能力要满足什么要求的角度，先把蓝图想清楚，再动手。

我做 K8sChat 时，深有体会。动手写代码之前，我先认真梳理了一份产品设计：这个工具要解决运维的什么痛点、要提供哪些核心功能、每个功能的边界和要求是什么、尤其是安全上的硬性要求。正是这份前置的产品思考，让我后面的开发有章可循、没有跑偏。功能全景和需求梳理，不是文档党的形式主义，而是把事情做对的前提。 尤其 AIOps 这种复杂系统，没有全景，很容易只见树木不见森林。

二，AIOps平台的功能全景

好，进入正题。我把一款完整 AIOps 平台的功能，分成八个模块。你可以把它当成一份功能清单来看。这八个模块，大体也沿着前面讲过的运维数据流动来组织。

我先用一个画面帮你把这八块串起来。 想象一次线上故障从发生到解决的全过程：数据平时就在源源不断地采进来（模块一在干活）；故障发生，一堆告警涌来，先被降噪收敛成几个事件（模块二）；其实在告警之前，异常检测可能已经嗅到了苗头（模块三）；运维要定位，根因分析帮着在乱象里找病根（模块四）；事后复盘，发现其实容量早有预警只是没注意（模块五）；对于明确的问题，自动化能直接处置（模块六）；整个过程里，运维用自然语言问智能助手拿信息、拿建议（模块七）；而这一切，都通过统一的可视化界面呈现、和现有工具打通（模块八）。八个模块，其实就是这样围着运维的一次真实作战流程展开的，不是硬凑的八个格子。 下面逐个说。

模块一，数据接入与治理。 这是整个平台的入口和地基。核心职责：把多来源、多格式的运维数据采集进来，并清洗、标准化、存储好。 要接的数据包括指标、日志、链路追踪，还有事件、配置、变更记录、告警等。核心需求：接入要广(支持主流的数据源和格式)、要稳(不能丢数据)、处理后的数据要干净规范(否则后面全是垃圾进垃圾出)。 这块是重中之重，没有好数据，后面所有智能都是空谈。我做 K8sChat 时最先啃的也是这块，数据接不进来、接不干净，上面什么都免谈。

模块二，告警管理与降噪。 核心职责：统一接管来自各处的告警，并做去重、压制、关联、分组，把海量噪音收敛成少数真正需要关注的问题。 核心需求：能对接各种告警源、能有效降噪(降噪率是关键指标)、能按关联关系把相关告警聚成一个事件、能灵活配置降噪和分组规则。这是最容易见效、往往也是团队第一个上的功能。 我见过太多团队，就是从治告警疲劳这一步，尝到 AIOps 甜头的。

模块三，异常检测。 核心职责：自动地、智能地发现指标和日志中的异常，而不依赖人工设死阈值。 核心需求：支持对大量指标做检测、能自动学习正常基线并适应变化(比如业务有周期性波动)、检测要准(既别漏报、也别误报太多)、检测结果要能追溯和解释。这里我要先埋个伏笔：这块最大的坑是误报，后面专门有一篇讲，它能决定异常检测到底能不能活下来。

模块四，根因分析。 核心职责：当故障发生、一堆告警和异常同时出现时，帮助快速定位最可能的根本原因。 核心需求：能整合告警、异常、拓扑依赖、变更等多方信息、能基于关联和依赖关系做推理、能给出可能的根因排序和依据(而不是一个黑盒结论)。这是运维最费脑、也最能体现平台价值的功能之一。

模块五，预测与容量管理。 核心职责：基于历史数据，预测资源使用趋势、容量瓶颈、潜在故障，支撑从被动到主动。 核心需求：能对关键资源(CPU、内存、磁盘、流量等)做趋势预测、能提前预警容量风险、预测要有合理的准确度和置信度说明。

模块六，自动化与自愈。 核心职责：对明确的、风险可控的问题，自动执行处置动作，减少人工介入。 核心需求：能定义和编排处置动作(如自动扩容、重启、切流)、能设置触发条件、尤其关键的是，危险操作必须有严格的权限、审批和回滚机制，不能让自动化闯祸。 这一块能力最高级，也最需要谨慎设计，安全是第一位的。

模块七，智能助手(大模型带来的新模块)。 核心职责：提供自然语言交互能力，让用户能用大白话查询状态、分析问题、获取建议，并整合运维知识。 核心需求：能理解运维领域的自然语言提问、能结合实时数据和知识库(RAG)给出有依据的回答、涉及执行操作时必须有安全护栏(白名单、确认、审计), 这正是我做 K8sChat 的核心。

模块八，可视化与集成。 核心职责：把上面所有能力的结果，清晰地呈现给人，并与现有的运维工具链打通。 核心需求：提供直观的仪表盘和大屏、告警和事件的清晰展示、能和现有的监控、工单、通知、协作工具集成。再强的能力，也要通过好的呈现和集成，才能真正融入团队的工作流。

三，几点整体性的说明

梳理完八个模块，再补几点整体层面的认识，帮你更好地理解这张功能地图。

第一，不是每款平台都要全有，也不是都要自己做。 这八个模块是一个完整的参考全景，但现实中，不同的平台会有不同的侧重，不同的团队会按需取舍。有的平台强在告警降噪，有的强在根因分析，有的主打大模型智能助手。 你评估或建设时，要看的是它在你最需要的模块上做得够不够好，而不是苛求它八块全都顶尖。

第二，模块之间是有依赖和顺序的。 数据接入是所有一切的地基；告警降噪和异常检测是中间的核心能力；根因、预测、自动化是更高阶的应用；智能助手和可视化贯穿其上。建设时要尊重这个依赖顺序，先打好数据地基，别地基没夯实就冲上层的自动化和智能。 这和前一篇讲的成熟度演进是一致的。

第三，安全和权限要贯穿所有涉及操作的模块。 凡是能对生产系统做出改动的功能(自动化自愈、智能助手的执行能力),都必须有严格的权限控制、操作审批、审计留痕、回滚兜底。这是我做运维 AI 工具时守得最死的一条线，后面需求描述里还会作为非功能需求专门强调。 一款不重视安全的 AIOps 平台，能力越强，越危险。

小结

这一篇从产品视角，梳理了一款完整 AIOps 平台的功能全景，分成八个模块：数据接入与治理(地基)、告警管理与降噪、异常检测(核心能力)、根因分析、预测与容量管理、自动化与自愈(高阶应用)、智能助手(大模型新模块)、可视化与集成(呈现与打通)。每个模块我都点出了它的核心职责和核心需求。三点整体说明是：不必苛求全有全自研、模块间有依赖顺序要先打地基、安全和权限要贯穿所有涉及操作的模块。

有了这张全景图，下一篇我们挑其中几个核心模块，写成更规范、更细致的需求描述，让你看清一份 AIOps 功能需求到底该怎么写。

AIOps实战04：一款AIOps平台该具备哪些功能，一份产品视角的功能全景