运维监控PRD需求文档专业版提示词

角色定义与任务定位

请以“资深运维产品经理”或“技术方案架构师”的身份，你的核心目标是：为开发团队、测试团队及运维团队，撰写一份逻辑清晰、要素完备、技术描述准确的《运维监控平台产品需求文档》。这份文档将作为项目开发的唯一需求基准，旨在定义一套从数据采集、处理、告警到可视化展示的完整监控解决方案。

适用场景

• 规划全新的企业级统一监控平台项目。
• 对现有分散的监控工具进行整合与升级改造。
• 为满足合规性审计（如等保）要求，需要标准化监控需求。
• 向管理层或客户汇报监控系统的整体能力与建设蓝图。

核心提示词

可直接复制并填充具体内容，用于构建PRD主干：

• 文档概述：本文档旨在定义[平台名称]运维监控平台的需求，涵盖基础设施监控、应用性能监控、业务指标监控与日志集中分析，目标用户为运维工程师、开发人员及系统管理员。
• 业务目标：降低平均故障恢复时间（MTTR），实现故障预测与智能告警，提供统一的监控数据视图，支撑容量规划与成本优化。
• 功能需求-数据采集：支持通过Agent、SNMP、API、日志文件等多种方式，采集服务器（CPU、内存、磁盘、网络）、中间件（如Nginx、Redis、MySQL）、应用（JVM、自定义指标）及业务关键交易链路数据。
• 功能需求-告警管理：支持多级阈值告警（警告、严重）、灵活的告警规则配置（表达式、持续时间）、多种通知渠道（钉钉、企业微信、短信、邮件），并提供告警收敛、降噪与认领闭环功能。
• 功能需求-可视化：提供可自定义的仪表盘，支持多种图表（曲线图、柱状图、拓扑图、地理分布图），并具备大屏监控视图模式，关键指标要求支持实时刷新。
• 非功能需求：数据采集延迟小于30秒，平台自身可用性不低于99.9%，支持水平扩展以应对日均TB级数据量，所有敏感数据传输与存储需加密。

风格方向

• 文档风格：采用严谨、客观、无歧义的技术文档风格，避免口语化和营销性描述。
• 结构层次：遵循“总-分”结构，从业务背景到具体功能点逐层细化，使用标准的编号体系（如1., 1.1, 1.1.1）。
• 视觉辅助：在描述系统架构、数据流、部署拓扑时，明确标注“需提供架构图/流程图”，并简述图示要点。

构图建议（用于需求描述的可视化构思）

• 系统架构图：分层构图，展示数据采集层、传输层、存储计算层、告警引擎层和应用展示层，用箭头明确数据流向。
• 仪表盘布局草图：采用网格划分，描述关键仪表盘（如全局概览、基础设施详情、应用性能、业务健康度）的组件排布与核心指标。
• 拓扑图：用于展示网络设备、微服务调用链或主机集群的逻辑关系与状态映射。
• 状态流程图：清晰描绘告警从触发、通知、处理到关闭的完整状态流转过程。

细节强化

• 指标定义：对每个监控指标，需明确定义其名称、采集方式、计算频率、单位及正常范围阈值。
• 交互细节：描述关键操作，如“在仪表盘编辑模式下，用户可通过拖拽方式添加或调整图表组件”。
• 权限模型：明确不同角色（如管理员、运维员、只读用户）对数据、告警规则、仪表盘的访问与操作权限。
• API与集成：列出需要对外提供的核心API（如数据查询、告警触发）以及需要集成的第三方系统（如CMDB、ITSM工单系统）。

使用建议

• 在使用本提示词生成具体章节时，请将方括号“[ ]”内的示例替换为项目的实际名称和具体数值。
• “核心提示词”部分可直接作为PRD各章节的标题和核心段落模板，在此基础上进行扩展和细化。
• 建议配合UML工具或绘图软件，将“构图建议”转化为实际的示意图，并作为附件插入PRD文档，使需求更直观。
• 在撰写完成后，可基于此文档结构，向大语言模型进一步提问，以生成更细粒度的功能点描述或用户故事。