AIOps实战06：核心功能的需求描述（下），高阶模块与非功能需求

我是老计。上一篇写了数据接入、告警降噪、异常检测三个基础模块的需求。这一篇继续，写三个更高阶的模块，根因分析、预测与容量、智能助手，再讲一块特别重要、却常被新手忽视的东西，非功能需求。尤其安全这块，我会结合 K8sChat 的实践讲，因为它是 AIOps 的生命线。

先用一个场景把这三个高阶模块的价值讲活。 设想一个深夜，线上出故障了：如果有好的根因分析，系统能帮你在一堆乱象里几分钟锁定病根，而不是几个人对着告警墙熬到天亮；如果有好的容量预测，这次故障可能压根不会发生，因为系统早在几天前就预警了资源要触顶；如果有好的智能助手，你甚至可以直接用一句话问它到底出了什么事、建议怎么处理。这三个模块，一个管事后快速定位、一个管事前主动预防、一个管全程的交互提效，是 AIOps 里最能让运维少熬夜的部分。 但也正因为它们更高阶、更靠近决策和操作，需求就更要写清楚，尤其是安全。下面逐个说。

一，模块四，根因分析

故障来了、一堆告警和异常同时炸，怎么快速找到病根，这是运维最费脑的活，也最能体现平台价值。

功能目标： 当故障发生时，整合多方信息，帮助快速定位最可能的根本原因，把运维从大海捞针里解放出来。

输入与输出：

输入：告警、异常检测结果、服务拓扑与依赖关系、变更记录、日志、指标等多方数据。
输出：可能的根因排序列表，每个候选根因附带支撑它的证据和推理依据。

关键需求点：

多源信息整合。 根因分析不能只看单一数据，要能把告警、异常、拓扑、变更等关联到一起看。
基于依赖与关联推理。 能利用服务拓扑和依赖关系，沿着影响链条上溯定位，而不是孤立看单点。
善用变更信息。 大量故障由变更引起，能把时间相近的变更作为重要的根因候选，往往命中率很高。
给依据，不做黑盒。 必须给出为什么判定这个是根因的证据链，而不是甩一个结论。 运维要能看懂、能验证，才敢信。
排序而非武断。 给出按可能性排序的候选，把最终判断权留给人。

验收思路： 在历史真实故障上回放，根因命中率（真实根因出现在候选前几名的比例）达到约定水平、给出的证据能被运维理解和采信、定位耗时相比纯人工显著缩短。

关于根因分析，多提醒一句。 它是 AIOps 里最难、也最容易被过度承诺的能力。现实中的根因往往复杂、多因耦合，指望系统一键给出百分百正确的唯一根因，是不现实的。 所以我特别强调排序而非武断、给证据而非黑盒结论。一个诚实的根因分析，应该是把最可能的几个候选连同依据摆给运维，辅助人更快地做判断，而不是替人拍板。 需求阶段就把这个定位摆正，后面才不会因为达不到不切实际的期望而被判失败。这也再次呼应了这个系列的主线，AI 是强大的辅助，但最终的判断和责任在人。

二，模块五，预测与容量管理

从被动救火到主动预防，靠的就是预测能力。

功能目标： 基于历史数据，预测资源使用趋势、容量瓶颈和潜在风险，支撑提前决策，让运维从被动变主动。

输入与输出：

输入：关键资源的历史时序数据（CPU、内存、磁盘、流量、请求量等）、业务增长信息。
输出：资源使用的趋势预测、容量触顶的预警时间、以及带置信度的预测结果。

关键需求点：

对关键资源做趋势预测。 能预测核心资源未来一段时间的走势。
提前预警容量风险。 能推算出资源大约何时触及瓶颈，给出提前量，让人有时间准备扩容。
合理的准确度与置信度说明。 预测不可能百分百准，关键是要诚实地给出置信区间，别把预测说成板上钉钉。 一个标着置信度的预测，比一个假装精确的数字有用得多。
适应业务节奏。 能考虑业务的周期性和增长趋势，比如大促前的流量。

验收思路： 在历史数据上做回测，预测误差在约定范围内、容量预警的提前量足够运维响应、预测结果带明确的置信度说明、对典型业务周期的预测合理。

三，模块六，智能助手（大模型模块）

这是大模型带来的新模块，也是我做 K8sChat 的核心，重点讲。

功能目标： 提供自然语言交互，让用户能用大白话查询状态、分析问题、获取建议，并整合运维知识，大幅降低运维的使用门槛。

输入与输出：

输入：用户的自然语言提问、实时的运维数据、运维知识库与历史故障库。
输出：自然语言的回答、分析、建议；必要时（在严格控制下）触发的运维操作。

关键需求点：

理解运维领域语言。 能听懂运维的专业提问，把它转成对数据的查询或对工具的调用。
结合实时数据与知识（RAG）。 回答要基于真实的实时数据和沉淀的知识库，而不是模型自己瞎编，这就要靠 RAG 把知识和数据喂给模型。
给有依据的回答。 回答要能追溯到数据来源，减少幻觉带来的误导。
涉及操作时的安全护栏（重中之重）。 一旦让助手能执行运维操作，安全就是第一位的。 我做 K8sChat 时守死的几条：默认只读、工具白名单、写操作必须提案加人工确认、全程审计、多集群隔离。这些不是加分项，是能不能上生产的红线。

验收思路： 对典型运维问题的回答准确率和有用性达标、回答能追溯依据、幻觉率在可接受范围、尤其所有涉及操作的路径都经过安全护栏（无绕过、有审计），这一项是一票否决的。

四，别忘了非功能需求

讲完六个功能模块，必须专门讲一块新手最容易忽视、却决定成败的东西，非功能需求。功能需求说的是系统能做什么，非功能需求说的是系统做得怎么样，后者往往才是生产可用与否的分水岭。

性能与实时性。 AIOps 处理的数据量巨大，检测、分析要有足够的吞吐和可接受的延迟。故障来了，一个半小时才分析出根因的系统没有意义。

可扩展性。 数据和监控对象会持续增长，系统要能水平扩展，不能一上量就垮。

可靠性。 AIOps 自己也是个系统，它挂了会影响运维，所以它自身要高可用，不能成为新的单点。

安全与权限（最关键）。 这是我要重点强调的。 凡是能读敏感数据、尤其是能对生产系统做操作的功能，都必须有：严格的权限控制（谁能做什么）、操作审批（危险操作要人确认）、审计留痕（谁在什么时候做了什么，可追溯）、回滚兜底（出问题能退回去）。我做 K8sChat 时，这套安全机制花的心思比功能本身还多，因为一个能操作生产集群的 AI，安全没做好，能力越强越危险。

可解释性与可信任。 AIOps 的结论要能被人理解和验证，黑盒的智能，运维不敢用、也不该用。可解释不是锦上添花，是让 AIOps 真正被信任、被采纳的前提。

这几条非功能需求，尤其是安全，务必在需求阶段就想清楚、写明白，别等系统做出来了才补，那时候往往为时已晚、代价极大。

五，安全需求怎么落地，K8sChat的实践

安全这条生命线，说起来都懂，难在怎么落地。我把做 K8sChat 时真正管用的几条具体做法，写成可参考的安全需求，供你借鉴。

第一，默认只读，能力最小化。 系统默认只有查询能力，任何写操作都是需要显式开启、显式授权的例外。宁可让它少能干，也不让它乱能干。 这是最基础、也最有效的一条。

第二，工具白名单，而非黑名单。 只有明确列入白名单的操作，AI 才可能调用；不在名单里的一律拒绝。用白名单而不是黑名单，因为你永远列不全所有危险操作，但你能列清所有允许的安全操作。 这个思路上的差别，是安全设计的关键。

第三，写操作必须提案加人工确认。 AI 不直接执行任何有副作用的操作，它只能生成一个操作提案（我要做什么、对什么对象、预期结果），交给人审核确认后才执行。把最终的执行权，牢牢留在人手里。

第四，全程审计。 谁、在什么时候、通过什么方式、做了什么操作、结果如何，全部留痕可查。出了问题能追溯，平时能审查，这是信任的基础。

第五，多环境多租户隔离。 不同集群、不同环境的权限严格隔离，避免误操作跨环境扩散。

把这几条写进需求，安全就不再是一句空话，而是可落地、可验收的具体约束。 这套东西，是我认为任何能操作生产系统的 AIOps 功能，都必须具备的底线。

小结

这一篇写完了高阶模块和非功能需求：根因分析要整合多源信息、沿依赖推理、善用变更、给证据链、排序不武断；预测与容量要做趋势预测和提前预警、诚实给置信度；智能助手(大模型模块)要懂运维语言、靠RAG给有依据的回答、涉及操作时必须有默认只读白名单确认审计的安全护栏。非功能需求同样关键：性能实时性、可扩展、可靠、可解释，而安全与权限是最关键的生命线，必须在需求阶段就想清楚写明白。产品与需求这个板块到此结束。

下一篇，我们回到技术，讲 AIOps 的地基，数据，看可观测三支柱怎么成为 AI 的燃料。

AIOps实战06：核心功能的需求描述（下），高阶模块与非功能需求