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

AIOps实战05核心功能的需求描述上把AIOps需求写规范我是老计。上一篇给了一款 AIOps 平台的功能全景八个模块那是概览。这一篇和下一篇我们往前走一步挑其中几个核心模块写成更规范、更细致的需求描述让你看清一份 AIOps 的功能需求到底该怎么写、写到什么颗粒度。这一篇先讲最基础的三个数据接入、告警降噪、异常检测。一为什么要把需求写规范先说清这件事的价值不然你可能觉得写需求是文档党的活。我先讲个反面的教训。早年做一个内部小工具时需求就一句话做个能自动发现异常的东西。听着挺清楚结果做起来全是坑要发现什么的异常数据从哪来异常了怎么通知多准算达标这些全没定。做的人凭自己理解闷头做做出来发现和提需求的人想的根本不是一回事来回返工了好几轮白白耗掉大把时间。事后复盘问题不在技术在一开始就没把需求描述清楚。从那以后我就认死一个理动手前先把每个功能的需求描述清楚是把事情做对、少走弯路的前提。后来做 K8sChat我在动键盘之前老老实实把每个功能的目标、边界、要求先写明白开发就顺畅多了。一个功能如果你说不清它的目标是什么、要吃什么数据、吐什么结果、满足哪些要求、怎么算做好了那你多半也做不好它团队之间也没法对齐。需求描述就是逼你把一个模糊的想法落成清晰的、可对齐的、可验收的规格。我这里用的需求描述格式是一个偏轻量但够用的结构功能目标这个模块要解决什么、输入与输出吃什么、吐什么、关键需求点必须满足的核心要求、验收思路怎么算做好了。这不是严格的工业级 PRD但足以把一个功能讲清楚。下面三个模块我都按这个结构来写你可以当模板参考。多说一句为什么用这个结构。功能目标逼你想清楚做这个到底图什么避免为做而做输入与输出逼你想清楚它和上下游怎么衔接、依赖什么数据、产出什么结果这一步最能暴露前置条件是否具备关键需求点是这个功能的灵魂把必须满足的硬要求和核心指标拎出来验收思路则让需求可检验避免最后谁也说不清做没做好。这四块合起来就把一个功能从模糊的想法变成了可对齐、可开发、可验收的规格。缺了任何一块需求都是不完整的。二模块一数据接入与治理这是整个平台的地基先写它。功能目标把分散在各处、格式各异的运维数据统一采集进来经过清洗、标准化、存储形成干净、规范、可供上层分析的数据底座。一句话为整个 AIOps 提供可靠的数据燃料。输入与输出输入多来源的运维数据包括指标如 Prometheus 的时序数据、日志各类应用和系统日志、链路追踪、以及事件、配置、变更记录、告警等。输出清洗标准化后的、带统一标签体系的、可被检索和分析的结构化数据存入相应的存储时序库、日志库、图数据库等。关键需求点接入要广。支持主流的数据源和协议如 OpenTelemetry、Prometheus、各类日志采集器能灵活接新数据源。采集要稳、不丢数据。高吞吐下不丢关键数据有缓冲和重试机制。数据要干净、要标准化。统一时间戳、统一标签命名、去除脏数据因为垃圾进就是垃圾出后面所有智能都建立在这层数据质量上。要可扩展。数据量会持续增长采集和存储要能水平扩展。验收思路能否成功接入约定的几类主流数据源、在压测流量下丢数据率低于约定阈值、输出数据的标签规范性和完整性抽检达标、新增一个数据源的接入成本在可接受范围。三模块二告警管理与降噪这是最容易见效、团队通常最先上的功能。功能目标统一接管来自各监控系统的海量告警通过去重、压制、关联、分组把噪音收敛成少数真正需要人关注的事件治好告警疲劳。输入与输出输入来自各告警源的原始告警流Prometheus Alertmanager、各云监控、各类监控工具。输出去重压制后的告警、按关联关系聚合成的事件一个事件包含一组相关告警、以及推送给对应责任人的通知。关键需求点多告警源接入。能统一对接主流监控系统的告警。有效降噪。支持去重同一问题反复告警合并、压制依赖项已知故障时抑制下游告警、静默维护窗口。降噪率是这个模块的核心指标。智能关联与分组。能基于时间、拓扑依赖、标签等把相关告警聚成一个事件让人看到的是问题而不是一堆碎片。灵活的规则配置。降噪、关联、分组、路由规则都要能灵活配置适配不同团队的需要。可追溯。每个被压制或合并的告警都要能查到不能悄悄丢掉否则运维不敢信任它。验收思路在真实告警流上告警总量收敛比例达到约定目标比如从每天数千条收敛到数十个事件、关联分组的准确性抽检达标、无因降噪导致真实问题被漏掉的情况、规则配置对普通运维人员足够易用。这里我特别想强调可追溯这一条它是我踩出来的。团队第一次上降噪时大家最担心的不是降噪率不够高而是它会不会把重要告警偷偷吞了。只要有一次运维发现某个该响的告警被降噪系统悄悄压掉、导致漏了事这套系统的信任就彻底崩了之后谁都不敢用。所以我把可追溯当成硬需求压了什么、合并了什么、静默了什么全都要能一键查到。信任是降噪能落地的真正前提而信任就建立在这种一切可追溯的透明上。四模块三异常检测这是让系统自己发现问题的核心能力。功能目标自动、智能地发现指标和日志中的异常摆脱人工设死阈值的老办法让系统能适应业务的动态变化、及早发现苗头。输入与输出输入清洗后的时序指标数据、日志数据。输出检测到的异常点或异常时段、异常的严重程度评分、以及触发的告警或事件。关键需求点支持大规模指标检测。现代系统有海量指标要能规模化地做检测而不是只盯几个关键指标。自动学习基线、适应变化。能自动学习指标的正常模式含周期性比如白天高夜里低、工作日和周末不同并随业务演进动态更新基线而不是靠人拍一个固定阈值。准确平衡漏报和误报。既不能漏掉真异常也不能误报太多误报多了运维就不看了这是异常检测落地最大的坑。准确率和召回率的平衡是核心难点。可解释、可追溯。报出一个异常最好能说明为什么判定为异常比如偏离基线多少否则运维难以信任和处理。可反馈调优。运维标记误报后系统能据此改进形成闭环。验收思路在带标注的历史数据上检测的准确率和召回率达到约定水平、误报率低于运维可接受的阈值、对典型的周期性波动不误报、报出的异常带有可理解的依据、支持人工反馈并能看到改进。五写需求时的几个通用心得写这三个模块的需求有几点通用的经验分享给你第一需求要可验收别写成口号。别只写检测要准要落到准确率召回率、误报率这类能衡量的标准上哪怕是定性的约定。不可验收的需求等于没需求。第二关键指标要点出来。每个模块都有它的核心指标告警降噪看降噪率、异常检测看准确率和误报率、数据接入看丢数据率。抓住核心指标就抓住了这个模块的要害。第三别忘了可解释和可信任。AIOps 的功能光准还不够还得让运维敢信、能追溯。一个黑盒的、无法追溯的智能功能运维是不敢用的这一点在需求阶段就要考虑进去。这也呼应我一直强调的AI 是辅助人要能理解和监督它。六写需求时的几个常见误区除了上面的心得再讲几个我见过、也踩过的常见误区帮你少走弯路。误区一把功能堆砌当需求。很多人写需求就是列一堆我要有 A、我要有 B 的功能点却说不清每个功能要解决什么问题、满足什么标准。功能清单不等于需求。需求的核心是目标和约束而不是功能的罗列。没有目标牵引的功能堆砌做出来往往是一堆用不上的花架子。误区二脱离数据现实谈功能。上层的检测、根因这些功能有多强根本上取决于底层数据的质量和完整度。我见过不少需求上来就要求很智能的检测和根因却对数据接入这个地基一笔带过。结果数据没打好上层智能全是空中楼阁。写需求时一定要让上层能力的期望和底层数据的现实相匹配。误区三忽视人的因素。AIOps 是给人用的运维信不信、会不会用、愿不愿用直接决定它有没有价值。一个技术上很先进、但运维看不懂、不敢信、不会用的功能等于没用。所以需求里要考虑易用性、可解释性、和现有工作流的融合别只盯着算法多先进。误区四需求一次写死、不留演进空间。AIOps 的能力是逐步长出来的呼应成熟度那一篇别指望需求一步到位。好的需求会区分核心必做和后续演进先把地基和高价值的核心功能定清楚给未来的能力留出扩展空间而不是一开始就想把所有高级功能都框死。避开这几个误区你的 AIOps 需求就能比大多数人写得更清醒、更落地。小结这一篇挑三个基础核心模块示范了 AIOps 功能需求该怎么写规范用功能目标、输入与输出、关键需求点、验收思路这个结构。数据接入与治理是地基要广、稳、干净、可扩展告警管理与降噪治告警疲劳核心指标是降噪率要能去重压制关联分组且可追溯异常检测让系统自己发现问题难点是自动学基线和平衡漏报误报要可解释可反馈。写需求的通用心得要可验收别写口号、点出核心指标、别忘了可解释和可信任。下一篇我们继续写另外三个更高阶的模块根因分析、预测、智能助手的需求描述以及贯穿所有模块的非功能需求。延伸阅读OpenTelemetry 官方文档运维数据采集标准opentelemetry.io/docsPrometheus 与 Alertmanager 官方文档指标与告警prometheus.io/docsGoogle SRE 官方在线书监控与告警章节sre.google/books时序异常检测综述可在 arXiv 检索 time series anomaly detection surveyarxiv.org本文为技术经验分享旨在梳理AIOps核心功能的需求描述方法。文中需求结构与指标为通用示意不构成具体产品或采购建议实际建设请结合自身环境评估。