AIOps实战05：核心功能的需求描述（上），把AIOps需求写规范-二趣网

AIOps实战05：核心功能的需求描述（上），把AIOps需求写规范

我是老计。上一篇给了一款 AIOps 平台的功能全景，八个模块，那是概览。这一篇和下一篇，我们往前走一步，挑其中几个核心模块，写成更规范、更细致的需求描述，让你看清一份 AIOps 的功能需求，到底该怎么写、写到什么颗粒度。这一篇先讲最基础的三个：数据接入、告警降噪、异常检测。

一，为什么要把需求写规范

先说清这件事的价值，不然你可能觉得写需求是文档党的活。

我先讲个反面的教训。早年做一个内部小工具时，需求就一句话：做个能自动发现异常的东西。听着挺清楚，结果做起来全是坑：要发现什么的异常？数据从哪来？异常了怎么通知？多准算达标？这些全没定。做的人凭自己理解闷头做，做出来发现和提需求的人想的根本不是一回事，来回返工了好几轮，白白耗掉大把时间。事后复盘，问题不在技术，在一开始就没把需求描述清楚。从那以后我就认死一个理：动手前，先把每个功能的需求描述清楚，是把事情做对、少走弯路的前提。后来做 K8sChat，我在动键盘之前，老老实实把每个功能的目标、边界、要求先写明白，开发就顺畅多了。

一个功能，如果你说不清它的目标是什么、要吃什么数据、吐什么结果、满足哪些要求、怎么算做好了，那你多半也做不好它，团队之间也没法对齐。需求描述，就是逼你把一个模糊的想法，落成清晰的、可对齐的、可验收的规格。

我这里用的需求描述格式，是一个偏轻量但够用的结构：功能目标（这个模块要解决什么）、输入与输出（吃什么、吐什么）、关键需求点（必须满足的核心要求）、验收思路（怎么算做好了）。这不是严格的工业级 PRD，但足以把一个功能讲清楚。下面三个模块，我都按这个结构来写，你可以当模板参考。

多说一句为什么用这个结构。功能目标逼你想清楚做这个到底图什么，避免为做而做；输入与输出逼你想清楚它和上下游怎么衔接、依赖什么数据、产出什么结果，这一步最能暴露前置条件是否具备；关键需求点是这个功能的灵魂，把必须满足的硬要求和核心指标拎出来；验收思路则让需求可检验，避免最后谁也说不清做没做好。这四块合起来，就把一个功能从模糊的想法，变成了可对齐、可开发、可验收的规格。缺了任何一块，需求都是不完整的。

二，模块一，数据接入与治理

这是整个平台的地基，先写它。

功能目标：把分散在各处、格式各异的运维数据，统一采集进来，经过清洗、标准化、存储，形成干净、规范、可供上层分析的数据底座。一句话，为整个 AIOps 提供可靠的数据燃料。

输入与输出：

输入：多来源的运维数据，包括指标（如 Prometheus 的时序数据）、日志（各类应用和系统日志）、链路追踪、以及事件、配置、变更记录、告警等。
输出：清洗标准化后的、带统一标签体系的、可被检索和分析的结构化数据，存入相应的存储（时序库、日志库、图数据库等）。

关键需求点：

接入要广。支持主流的数据源和协议（如 OpenTelemetry、Prometheus、各类日志采集器），能灵活接新数据源。
采集要稳、不丢数据。高吞吐下不丢关键数据，有缓冲和重试机制。
数据要干净、要标准化。统一时间戳、统一标签命名、去除脏数据，因为垃圾进就是垃圾出，后面所有智能都建立在这层数据质量上。
要可扩展。数据量会持续增长，采集和存储要能水平扩展。

验收思路：能否成功接入约定的几类主流数据源、在压测流量下丢数据率低于约定阈值、输出数据的标签规范性和完整性抽检达标、新增一个数据源的接入成本在可接受范围。

三，模块二，告警管理与降噪

这是最容易见效、团队通常最先上的功能。

功能目标：统一接管来自各监控系统的海量告警，通过去重、压制、关联、分组，把噪音收敛成少数真正需要人关注的事件，治好告警疲劳。

输入与输出：

输入：来自各告警源的原始告警流（Prometheus Alertmanager、各云监控、各类监控工具）。
输出：去重压制后的告警、按关联关系聚合成的事件（一个事件包含一组相关告警）、以及推送给对应责任人的通知。

关键需求点：

多告警源接入。能统一对接主流监控系统的告警。
有效降噪。支持去重（同一问题反复告警合并）、压制（依赖项已知故障时抑制下游告警）、静默（维护窗口）。降噪率是这个模块的核心指标。
智能关联与分组。能基于时间、拓扑依赖、标签等把相关告警聚成一个事件，让人看到的是问题而不是一堆碎片。
灵活的规则配置。降噪、关联、分组、路由规则都要能灵活配置，适配不同团队的需要。
可追溯。每个被压制或合并的告警都要能查到，不能悄悄丢掉，否则运维不敢信任它。

验收思路：在真实告警流上，告警总量收敛比例达到约定目标（比如从每天数千条收敛到数十个事件）、关联分组的准确性抽检达标、无因降噪导致真实问题被漏掉的情况、规则配置对普通运维人员足够易用。

这里我特别想强调可追溯这一条，它是我踩出来的。团队第一次上降噪时，大家最担心的不是降噪率不够高，而是它会不会把重要告警偷偷吞了。只要有一次，运维发现某个该响的告警被降噪系统悄悄压掉、导致漏了事，这套系统的信任就彻底崩了，之后谁都不敢用。所以我把可追溯当成硬需求：压了什么、合并了什么、静默了什么，全都要能一键查到。

信任是降噪能落地的真正前提，而信任，就建立在这种一切可追溯的透明上。

四，模块三，异常检测

这是让系统自己发现问题的核心能力。

功能目标：自动、智能地发现指标和日志中的异常，摆脱人工设死阈值的老办法，让系统能适应业务的动态变化、及早发现苗头。

输入与输出：

输入：清洗后的时序指标数据、日志数据。
输出：检测到的异常点或异常时段、异常的严重程度评分、以及触发的告警或事件。

关键需求点：

支持大规模指标检测。现代系统有海量指标，要能规模化地做检测，而不是只盯几个关键指标。
自动学习基线、适应变化。能自动学习指标的正常模式（含周期性，比如白天高夜里低、工作日和周末不同），并随业务演进动态更新基线，而不是靠人拍一个固定阈值。
准确，平衡漏报和误报。既不能漏掉真异常，也不能误报太多（误报多了运维就不看了，这是异常检测落地最大的坑）。准确率和召回率的平衡，是核心难点。
可解释、可追溯。报出一个异常，最好能说明为什么判定为异常（比如偏离基线多少），否则运维难以信任和处理。
可反馈调优。运维标记误报后，系统能据此改进，形成闭环。

验收思路：在带标注的历史数据上，检测的准确率和召回率达到约定水平、误报率低于运维可接受的阈值、对典型的周期性波动不误报、报出的异常带有可理解的依据、支持人工反馈并能看到改进。

五，写需求时的几个通用心得

写这三个模块的需求，有几点通用的经验，分享给你：

第一，需求要可验收，别写成口号。别只写检测要准，要落到准确率召回率、误报率这类能衡量的标准上（哪怕是定性的约定）。不可验收的需求，等于没需求。

第二，关键指标要点出来。每个模块都有它的核心指标，告警降噪看降噪率、异常检测看准确率和误报率、数据接入看丢数据率。抓住核心指标，就抓住了这个模块的要害。

第三，别忘了可解释和可信任。AIOps 的功能，光准还不够，还得让运维敢信、能追溯。一个黑盒的、无法追溯的智能功能，运维是不敢用的，这一点在需求阶段就要考虑进去。这也呼应我一直强调的：AI 是辅助，人要能理解和监督它。

六，写需求时的几个常见误区

除了上面的心得，再讲几个我见过、也踩过的常见误区，帮你少走弯路。

误区一，把功能堆砌当需求。很多人写需求，就是列一堆我要有 A、我要有 B 的功能点，却说不清每个功能要解决什么问题、满足什么标准。功能清单不等于需求。需求的核心是目标和约束，而不是功能的罗列。没有目标牵引的功能堆砌，做出来往往是一堆用不上的花架子。

误区二，脱离数据现实谈功能。上层的检测、根因这些功能有多强，根本上取决于底层数据的质量和完整度。我见过不少需求，上来就要求很智能的检测和根因，却对数据接入这个地基一笔带过。结果数据没打好，上层智能全是空中楼阁。写需求时，一定要让上层能力的期望，和底层数据的现实相匹配。

误区三，忽视人的因素。AIOps 是给人用的，运维信不信、会不会用、愿不愿用，直接决定它有没有价值。一个技术上很先进、但运维看不懂、不敢信、不会用的功能，等于没用。所以需求里要考虑易用性、可解释性、和现有工作流的融合，别只盯着算法多先进。

误区四，需求一次写死、不留演进空间。AIOps 的能力是逐步长出来的（呼应成熟度那一篇），别指望需求一步到位。好的需求会区分核心必做和后续演进，先把地基和高价值的核心功能定清楚，给未来的能力留出扩展空间，而不是一开始就想把所有高级功能都框死。

避开这几个误区，你的 AIOps 需求，就能比大多数人写得更清醒、更落地。

小结

这一篇挑三个基础核心模块，示范了 AIOps 功能需求该怎么写规范：用功能目标、输入与输出、关键需求点、验收思路这个结构。数据接入与治理是地基，要广、稳、干净、可扩展；告警管理与降噪治告警疲劳，核心指标是降噪率，要能去重压制关联分组且可追溯；异常检测让系统自己发现问题，难点是自动学基线和平衡漏报误报，要可解释可反馈。写需求的通用心得：要可验收别写口号、点出核心指标、别忘了可解释和可信任。

下一篇，我们继续写另外三个更高阶的模块，根因分析、预测、智能助手的需求描述，以及贯穿所有模块的非功能需求。

企业官网建设流程全解析