# 一体化运维平台完整蓝图与分期落地方案 生成来源：`/office-hours` 生成日期：2026-06-21 分支：`main` 仓库：`ops` 状态：草案 模式：企业内部项目交付 ## 问题陈述 当前项目已经从招标文件和菜单规划表中提取出 33 条一体化运维平台需求，覆盖资源监控、告警、工单、拓扑、IP 地址管理、数据中心、资产、机柜、知识库、报表、大屏、权限和系统管理。 真正的问题不是缺少功能清单，而是需求按资源类型和菜单组织，容易形成“页面很多、闭环很弱”的平台。医院当前高概率存在多工具监控、手工台账、微信群或人工派单混用的状态。平台需要把分散的运维信号、处理动作和验收证据统一到同一条运维事件链路中。 ## 当前现状 基于本次需求讨论输入，当前假设的现场状态为： - 多套监控或厂商工具并存，告警来源分散。 - Excel 或人工方式维护设备、IP、机柜、业务系统等台账。 - 告警通知和故障处理依赖人工沟通，缺少统一受理、派单、升级、关闭和复盘记录。 - 大屏和报表容易变成展示层，若没有真实事件链路支撑，验收时会被追问数据来源、处理过程和审计证据。 该假设需要在现场调研阶段确认，但足以指导蓝图设计：平台必须围绕“资源上下文 + 事件生命周期 + 处理闭环证据”组织。 ## 会议结论补充 本轮会议对部分前期待确认项给出了更明确边界： - 现场设备以 H3C/华三为主，厂商适配优先级应向 H3C 设备倾斜；第 1 阶段不追求全厂商覆盖。 - 3D 机房前端已经外包，OPS 侧不承担 3D 前端实现，只需要提供数据中心、机房、机柜、U 位、设备和告警状态等后端接口。 - Windows PowerShell 主要用于本地开发、调试和文档命令示例；验收部署环境需要面向 Linux 与麒麟系统。 - 医院当前有老运维平台，但首期不做迁移或集成；后续可能需要做历史数据迁移。 - 告警渠道中，平台站内消息、短信、邮件需要优先打通。 - 暂不考虑独立移动端；前端页面需要具备移动端适配能力。 - 数据中心、机柜、设备等已有现有数据，但短期内拿不到；首期需要支持后续导入和接口预留，不能依赖这些数据才能完成验收。 - 验收是否允许使用模拟 Trap、模拟 Syslog 和可控 URL/API 故障仍需确认。 - 建议引入国产或国内生态成熟的时序数据库，用于承载高频指标、采集样本和后续趋势分析。 ## 目标用户与最小可验收闭环 ### 核心用户 - 一线值班运维人员：需要及时知道哪些告警要处理、归属谁、下一步怎么做。 - 网络、主机、数据库、虚拟化等专项管理员：需要看到所属资源指标、拓扑关系、历史趋势和故障上下文。 - 运维负责人：需要看到告警处理效率、未恢复风险、资源健康、报表和大屏。 - 系统管理员：需要管理用户、角色、权限、字典、系统参数和日志审计。 ### 最窄可验收闭环 以一个关键业务系统或关键资源组为样例，完成： 1. 纳管主机、网络设备、数据库、虚拟化或 URL/API 等关键资源。 2. 采集指标、Syslog、SNMP Trap 或探测结果。 3. 触发告警并进入统一事件池。 4. 执行去重、压缩、屏蔽、抑制、级别判断和通知路由。 5. 值班人员确认、忽略、派单或升级。 6. 工单处理并关闭，沉淀处理记录和关联知识。 7. 首页、大屏、报表、历史告警和审计日志能证明完整过程。 ## 约束条件 - 蓝图要覆盖招标需求，但落地路线不能把 33 条需求全部压进同一期。 - 现场设备以 H3C/华三为主，但仍需确认具体型号、协议开放情况和账号权限。 - 平台事务数据仍面向 PostgreSQL 设计；高频指标和采集样本需要引入时序数据库选型，不把所有时序数据压入 PostgreSQL。 - 开发期可使用 SQLite 内存库做真实测试，不以 mock 数据库代替行为验证。 - 模板目录只能作为初始化来源，实际业务代码应落在 `server/`、`web/`、`deploy/`。 - 需求、架构和验收文档需要中文维护；本地开发命令示例使用 Windows PowerShell，验收部署需另行提供 Linux/麒麟适配说明。 ## 设计前提 1. 平台蓝图采用“双主线”：资源监控覆盖 + 告警事件闭环，两者并行。 2. 告警事件生命周期是业务主轴，资源、资产、拓扑、机柜、IPAM 是上下文，不是孤立菜单。 3. 资源监控蓝图完整覆盖，落地路线从主机、H3C/华三网络设备、数据库、虚拟化、URL/业务可用性等关键样例开始。 4. 告警能力必须包含去重、压缩或归并、屏蔽、抑制、升级、确认、忽略、派单、历史和报表证据。 5. 工单、知识库、报表、大屏围绕同一条事件链路产生证据。 6. 拓扑、IPAM、机柜、资产、动环属于完整蓝图必备能力，但按资源上下文和影响分析能力分期接入；3D 机房前端由外部团队负责，OPS 侧负责后端接口和数据模型。 7. 验收设计从“菜单是否存在”升级为“故障从发现到关闭是否可追踪、可审计、可报表”。 ## 外部产品校准 外部校准显示，同类 ITOM/AIOps 平台的核心价值正在从“展示更多指标”转向“服务上下文、告警降噪、事件归并、工单处置和持续复盘”。 - Grafana 告警最佳实践强调：告警应面向一线响应人，必须可理解、可行动；基础设施信号适合辅助诊断，不应全部作为高优先级打扰；需要分组、抑制抖动和定期复盘。参考： - ServiceNow ITOM 强调跨监控工具聚合事件、服务映射、去重、关联和突出可行动告警。参考： - Atlassian 事故管理强调可重复的记录、诊断、解决和活动留痕。参考： - PagerDuty Event Orchestration 把动态路由、事件规则和事件编排作为告警治理核心能力。参考： - TDengine TSDB 官方文档说明其面向物联网、工业互联网、金融、IT 运维等时序场景，提供 SQL、连接器、集群、流式计算和数据订阅能力。参考： - Apache IoTDB 官方介绍其定位为工业物联网时序数据库，支持边云协同、多协议兼容、高压缩比、高吞吐读写和 Grafana 等生态集成。参考： - openGemini 官方介绍其聚焦可观测性海量数据存储与分析，支持指标、日志、链路数据存储，具备分布式集群、高基数和压缩能力。参考： 结论：招标需求应按事件生命周期重组，而不是按菜单平铺；指标和采集样本需要单独进行国产/国内生态时序数据库选型，避免 PostgreSQL 同时承担事务数据和高频时序数据压力。 ## 备选方案 ### 方案 A：事件生命周期主轴平台 以“资源纳管 -> 指标/日志/Trap -> 告警事件 -> 降噪归并 -> 通知/升级 -> 工单处理 -> 知识沉淀 -> 报表/大屏”为平台骨架。 优点： - 同时满足资源监控覆盖和告警闭环。 - 验收故事强，能演示故障从产生到关闭的完整证据链。 - 33 条需求可以归入统一架构，而不是散成菜单清单。 缺点： - 对领域模型要求高，资源、指标、事件、告警、策略、工单要一次设计清楚。 - 前期接口、状态机和数据模型设计工作较重。 - 需要额外维护招标需求映射矩阵，向非技术干系人解释每个需求落点。 ### 方案 B：模块矩阵型平台 按需求文档中的模块直接建设：综合监控、告警管理、工单、拓扑、IPAM、资产、知识库、报表、大屏、权限、系统管理独立推进。 优点： - 和招标清单结构一致，容易解释“每个模块都有”。 - 适合做投标响应和逐项验收映射。 - 模块可以表面并行拆分。 缺点： - 容易形成模块孤岛。 - 后续补事件链路时会返工。 - 开发优先级不清晰，容易先完成页面而不是闭环。 ### 方案 C：分层能力底座平台 按采集接入层、资源/资产模型层、事件治理层、应用体验层建立底座，再把监控、告警、工单、拓扑、大屏、报表作为上层应用。 优点： - 长期架构更稳，适合扩展多厂商、多协议、多资源类型。 - 能统一 SNMP、Syslog、Trap、Agent、URL 探测、数据库脚本等接入方式。 - 适合完整蓝图和多期演进。 缺点： - 单独作为交付路线过重，容易离验收演示太远。 - 如果没有事件生命周期牵引，可能先做底座但缺少业务价值证明。 ## 推荐方案 采用方案 A，并吸收方案 C 作为内部架构原则。 工程和产品表达上，平台以事件生命周期为主轴。内部架构上，按能力分层建设，保证后续多资源、多协议、多厂商扩展不推倒重来。方案 B 只作为需求映射和验收矩阵，不作为工程主结构。 ## 蓝图架构 ### 1. 采集接入层 职责：把不同来源的指标、日志、Trap、探测结果和手工录入数据接入平台。 能力范围： - 主机 Agent 或无代理采集。 - SNMP 轮询和 SNMP Trap 接收，第 1 阶段优先覆盖 H3C/华三设备的常见指标、接口状态和 Trap 样例。 - Syslog 接收和规则解析。 - URL/API、端口、服务、进程、Webservice 探测。 - 数据库连接和自定义 SQL 脚本监控。 - 中间件、虚拟化、存储、安全设备、动环设备适配。 - 跨网代理和主动/被动数据推送。 关键设计： - 所有采集结果先归一为 `MetricSample`、`LogEvent`、`TrapEvent`、`ProbeResult`、`DiscoveryResult`。 - 采集配置、凭据引用、调度周期、失败重试和最近采集状态必须可审计。 - 采集失败本身也应能产生平台内部告警。 ### 1.5. 指标与时序数据存储层 职责：承载高频指标样本、探测结果、采集状态和趋势分析数据，避免事务库承担所有时序写入压力。 存储分工： - PostgreSQL：保存资源、资产、告警、事件、工单、策略、权限、审计、报表配置等事务数据。 - 时序数据库：保存指标样本、探测样本、接口流量、采集健康度、后续容量趋势和性能趋势。 - 对象存储或文件存储：保存导出报表、附件、截图、录像和大屏快照等非结构化证据。 候选方向： - TDengine TSDB：适合 IT 运维、物联网和工业互联网等时序场景，需验证麒麟部署、Go 连接器、集群运维和授权模式。 - Apache IoTDB：适合工业物联网和设备树结构数据，需验证资源模型映射、SQL 能力、Grafana 集成和运维复杂度。 - openGemini：适合可观测性海量指标、日志和链路数据，需验证项目成熟度、麒麟适配、社区活跃度和长期维护风险。 选型原则： - 必须支持 Linux 与麒麟部署，能在验收环境稳定运行。 - 必须提供 Go 后端可用的连接方式，支持批量写入、范围查询、聚合、降采样和保留策略。 - 必须支持与 PostgreSQL 中的资源 ID、指标编码、时间范围关联查询。 - 首期不把时序库能力暴露为复杂产品卖点，只作为监控指标和报表性能底座。 ### 2. 资源与资产模型层 职责：提供统一上下文，回答“这个告警来自什么资源、归属哪个业务、影响哪些对象”。 核心对象： - `Resource`：主机、网络设备、安全设备、存储、数据库、中间件、虚拟化对象、URL/API、动环设备等统一资源。 - `ResourceType`：资源类型和指标模板。 - `MetricDefinition`：指标编码、单位、阈值建议、采集方式。 - `MetricSeries`：时序数据中的指标序列映射，关联资源、指标定义、采集任务和时序库存储位置。 - `BusinessSystem`：HIS、LIS、PACS、EMR 等业务系统。 - `TopologyNode`、`TopologyLink`：网络拓扑和业务拓扑。 - `Asset`、`DataCenter`、`Room`、`Rack`、`RackUnit`：资产、数据中心、机房、机柜和 U 位。 - `IpSubnet`、`IpAddress`、`IpLease`、`IpConflict`：IP 地址管理。 关键设计： - 资源必须能绑定业务系统、组织、责任人、位置、资产和权限范围。 - 资产台账和监控资源要允许先分离后关联，避免现场台账不准时卡住监控接入。 - 拓扑不只用于展示，还要为告警影响分析和归并提供上下文。 - 数据中心、机柜、设备等现有数据短期拿不到时，系统必须允许先纳管监控资源，后续再通过导入或接口补齐资产位置关系。 ### 3. 事件治理层 职责：把原始异常转为可处理、可路由、可归并、可关闭的运维事件。 核心对象： - `RawEvent`：来自指标阈值、Syslog、Trap、探测失败、采集失败的原始事件。 - `AlertRule`：阈值、匹配条件、持续时间、恢复条件、作用范围。 - `Alert`：平台告警实例。 - `Incident`：归并后的事件或故障单元，可关联多个告警。 - `SilencePolicy`：屏蔽策略和屏蔽时间段。 - `DedupRule`：去重规则。 - `CorrelationRule`：压缩、依赖、抑制和关联规则。 - `EscalationPolicy`：升级策略。 - `NotificationPolicy`：通知路由。 状态建议： - `Alert`: firing、acknowledged、ignored、recovered、expired。 - `Incident`: open、assigned、in_progress、suspended、resolved、closed。 - `Ticket`: created、accepted、transferred、withdrawn、suspended、restarted、closed。 关键设计： - 告警不等于工单。告警是信号，事件是归并后的处置对象，工单是执行记录。 - 所有降噪策略必须留下规则命中和处理轨迹，便于验收和追责。 - 高级别告警优先、升级、通知失败重试、通知历史都要可查；第 1 阶段优先实现平台站内消息、短信、邮件三类渠道。 ### 4. 流程闭环层 职责：把事件处理从“人工沟通”变成平台内可追踪流程。 能力范围： - 告警确认、忽略、恢复、失效、导出。 - 手动创建工单、告警直接派单、策略自动派单。 - 接单、转交、撤回、挂起、重启、关闭。 - 知识库分类、发布、审核、附件、检测点关联。 - 处理记录、通知记录、审核日志、操作日志。 关键设计： - 工单必须能回链告警、事件、资源、业务系统、知识条目和处理人。 - 知识库不是独立文档仓库，应优先服务告警检测点和故障类型。 - 危险操作或策略变更需要审计日志。 ### 5. 应用体验层 职责：向不同角色提供可操作的页面和验收证据。 核心应用： - 首页总览：待处理告警、资源健康、告警趋势、网络状态、模块化配置。 - 综合监控：资源列表、资源详情、指标趋势、采集状态、模板绑定。 - 告警中心：实时告警、历史告警、降噪策略、模板、通知、升级、派单。 - 工单管理：事件工单流转和处理记录。 - 业务系统视图：业务健康、业务拓扑、影响范围、时间轴、笔记和文档。 - 网络拓扑：设备、链路、布局、告警图标、统计、下载。 - IP 地址管理：子网、地址状态、扫描、冲突、租约、变更、报表。 - 数据中心与资产：数据中心层级、机房、机柜、U 位、资产变更和容量。 - 知识库：分类、审核、关联检测点、附件下载。 - 报表管理：TopN、故障、服务器、网络设备、流量、统计报告和导出。 - 可视化大屏：分组、个人配置、轮播、拓扑、实时告警、接口流量、业务状态。 - 用户权限与系统管理：组织、用户、角色、数据权限、字典、参数、消息、日志。 ## 需求映射 | 能力域 | 覆盖需求 | | --- | --- | | 首页与大屏 | OPS-001、OPS-028 | | 资源监控 | OPS-002 至 OPS-012、OPS-031、OPS-032 | | 网络拓扑与流量 | OPS-013、OPS-014、OPS-015 | | IP 地址管理 | OPS-016、OPS-017 | | 告警治理 | OPS-018、OPS-019、OPS-020、OPS-021 | | 工单闭环 | OPS-022 | | 数据中心、机柜、资产 | OPS-023、OPS-024、OPS-025 | | 知识库 | OPS-026 | | 报表 | OPS-027 | | 用户权限、系统管理、日志 | OPS-029、OPS-030 | | 业务系统视图 | OPS-011、OPS-033 | ## 分期路线 ### 第 0 阶段：现场确认与验收基线 目标：把蓝图变成可执行范围。 交付物： - 现场资源清单和样例设备清单。 - 通知渠道确认：平台站内消息、短信、邮件为第 1 阶段优先渠道；企业微信、钉钉、电话等作为后续扩展。 - 账号、协议、网络连通性和安全边界确认。 - 验收矩阵：每个 OPS 编号对应演示路径、数据准备、通过标准和截图/录像证据。 - Linux 与麒麟验收部署环境确认，包括发行版、CPU 架构、数据库部署方式和网络策略。 ### 第 1 阶段：双主线核心闭环 目标：完成资源监控和告警事件闭环的最小可验收主干。 范围： - 资源模型、资源类型、指标定义、采集任务、采集状态。 - 主机、H3C/华三网络设备、数据库、虚拟化、URL/API 至少各一类样例接入或现场可替代样例。 - 时序数据库完成选型验证并接入指标样本写入、查询和保留策略。 - 指标阈值告警、Syslog/Trap 样例告警、URL/API 探测告警。 - 告警去重、压缩或归并、屏蔽、抑制、级别、升级、通知历史。 - 平台站内消息、短信、邮件三类通知优先打通。 - 告警确认、忽略、恢复、派单和历史查询。 - 工单基础流转：创建、接单、转交、挂起、关闭。 - 首页总览、告警大屏、基础报表、权限和操作日志。 - 3D 机房前端所需后端接口草案，包括数据中心、机房、机柜、U 位、设备坐标/位置、资源健康和告警状态。 不承诺： - 所有厂商全量适配。 - 除平台站内消息、短信、邮件之外的所有通知渠道全部打通。 - 3D 机房前端实现、复杂 IPAM、全量知识审核流程。 - 老运维平台迁移或集成。 ### 第 2 阶段：资源上下文增强 目标：让告警更容易定位影响范围和责任边界。 范围： - 网络拓扑、业务拓扑和资源关系。 - IP 地址管理、自动扫描、冲突、租约、变更记录。 - 数据中心、机房、机柜、U 位和资产关联；在现场数据可获得后支持批量导入、校验和资源关联。 - 面向外包 3D 机房前端的稳定后端接口和权限控制。 - 知识库检测点关联和审核日志。 - 更多资源类型和厂商适配。 - 老运维平台历史数据迁移评估和一次性导入方案。 ### 第 3 阶段：运营治理与智能化 目标：从“可处置”升级为“可优化”。 范围： - 告警质量评分、噪声分析、规则优化建议。 - 业务健康度、SLA/SLO、容量趋势和风险预测。 - 自动化处置建议、脚本执行审批、回滚和审计。 - 更完整的大屏编排、专题报表和领导视图。 ## 成功标准 ### 蓝图成功标准 - 33 条 OPS 需求均能映射到能力域和分期路线。 - 每个核心对象都有清晰归属：资源、指标、原始事件、告警、事件、工单、知识、报表、审计。 - 平台能解释“为什么这不是菜单堆叠，而是运维闭环”。 ### 第 1 阶段验收标准 - 至少完成一个端到端故障演示：资源异常触发告警，告警被归并和通知，值班人员确认并派单，工单处理关闭，报表和大屏可追踪全过程。 - 至少覆盖主机、H3C/华三网络设备、数据库、虚拟化、URL/API 中的关键样例。 - 告警策略、模板、级别、平台站内消息、短信、邮件、升级、历史、导出可演示。 - 指标样本进入时序数据库，资源详情、趋势图、报表能从真实采集或可控样例数据读取。 - 3D 机房后端接口可返回数据中心、机房、机柜、设备和告警状态样例数据，但不要求 OPS 交付 3D 前端。 - 权限、数据权限和操作日志能证明平台安全边界。 - 报表和大屏数据来自真实后端记录，不使用静态展示数据作为验收依据。 ## 交付与部署计划 平台作为内网部署 Web 服务交付。本地开发和调试以 Windows PowerShell 为主，验收部署目标面向 Linux 与麒麟系统。 建议交付形态： - `server/`：Go、Gin、GORM 后端服务，提供 REST API、后台任务、采集调度和事件处理。 - `web/`：Vue 3、TypeScript、Pinia、Vue Router、Arco Design Vue 前端。 - `deploy/`：数据库迁移、本地初始化脚本、Linux/麒麟部署说明、服务配置示例、烟测脚本。 - `server/etc/*.example.yaml`：配置结构示例，不提交真实凭据。 建议发布流程： - 开发环境：SQLite 内存库用于测试，PostgreSQL 作为事务数据目标数据库；时序库可先通过适配层和本地实例验证。 - 验收环境：使用 PostgreSQL、选定时序数据库、可控样例设备或现场授权设备，部署到 Linux/麒麟系统。 - 每次交付附带版本说明、迁移脚本、验收矩阵、演示脚本和截图/录像证据。 ## 外部依赖 - 现场设备清单、IP 段、账号权限和协议开放情况。 - H3C/华三设备型号、SNMP OID、Trap 字典、Syslog 格式和账号权限。 - 是否允许 SNMP、Syslog、Trap、Agent、数据库连接和 URL/API 探测。 - 医院短信平台、邮件服务、站内消息要求和第三方平台接入方式。 - 是否需要对接现有 ITSM、短信平台、统一身份认证或日志审计平台；老运维平台首期不迁移不集成，仅保留后续数据迁移可能性。 - 现场网络隔离、代理部署和安全审查要求。 - Linux 与麒麟系统版本、CPU 架构、服务管理方式、数据库部署边界和国产化合规要求。 - 选定时序数据库在 Linux/麒麟环境下的部署、授权、运维、备份和恢复要求。 - 真实验收样例：至少一个业务系统、一个网络设备、一个主机、一个数据库或 URL/API。 ## 待确认问题 1. 验收是否允许使用模拟 Trap、模拟 Syslog 和可控 URL/API 故障？如果允许，需要明确哪些场景可模拟、哪些必须来自现场设备。 2. H3C/华三首批接入设备的型号、SNMP 版本、Trap/Syslog 格式、账号权限和网络连通性是什么？ 3. 短信平台和邮件服务的接入方式、测试账号、发送限制和验收口径是什么？ 4. Linux 与麒麟验收环境的系统版本、CPU 架构、服务管理方式和网络安全限制是什么？ 5. 时序数据库已决策采用 TDengine 开源版；现场仍需确认 AGPL 合规、Linux/麒麟目标版本、部署形态、备份恢复和是否需要企业版支持。 6. 3D 机房外包前端需要 OPS 提供哪些接口字段、刷新频率、权限控制和告警状态编码？ 7. 数据中心、机柜、设备现有数据何时可获得？如果短期拿不到，是否接受使用样例数据完成接口和验收演示？ ## 下一步任务 下一步不要直接开发。先组织一次 60-90 分钟现场确认会，拿这份蓝图逐项确认第 0 阶段的输入。 会前准备一张确认表，至少包含： - 首批资源样例：主机、网络设备、数据库、虚拟化、URL/API。 - 每类资源的接入方式、账号、网络连通性和负责人。 - H3C/华三设备的 SNMP、Trap、Syslog 接入样例。 - 第 1 阶段必须打通的平台站内消息、短信、邮件渠道。 - Linux/麒麟验收部署环境和时序数据库选型。 - 外包 3D 机房前端需要的后端接口清单。 - 一条验收故障演示脚本：故障如何触发、谁接收、谁确认、谁派单、谁关闭、怎么出报表。 - 每个 OPS 编号归属到第 1 阶段、第 2 阶段或第 3 阶段。 会议结论必须形成 `docs/首期验收矩阵.md` 和 `TODOS.md`，否则后续开发会回到范围不清。 ## 关键观察 - 你坚持 “A 与 B 都很重要”，这是正确压力。资源覆盖和告警闭环不能互相牺牲，但必须分清底座和主线。 - 你选择“时间未定，先做完整蓝图”，说明当前目标不是快速样机，而是要先把平台结构讲清楚。这个选择要求文档必须分期，否则完整蓝图会变成全量承诺。 - 你最终选择“事件生命周期主轴平台，并把分层底座作为内部原则”，这是本次最关键决策。它保留长期扩展能力，同时不丢掉验收闭环。 ## /autoplan 审查记录 ### 输入概况 - 计划文件：`docs/integrated-ops-platform-blueprint-design.md` - 基准分支：`main` - 界面范围：包含首页、综合监控、告警中心、工单、大屏、报表、权限等应用界面。 - 开发体验范围：包含 REST API、部署、配置示例、迁移脚本、开发测试命令和工程初始化。 - 外部审查声部：本轮未启用。后续如 Codex CLI 因权限被拒绝，需要按用户要求先申请权限再执行。 - 高优先级仓库问题：Git remote URL 含明文凭据。报告中不复述凭据；后续用户已明确要求忽略该项，不作为当前交付阻塞。 - 高优先级仓库问题：`.gitignore` 忽略 `docs/`，会导致需求、蓝图和验收矩阵默认不进版本控制。 - 前提检查：通过。用户已确认事件生命周期主轴，并明确选择“方案 A，方案 C 作为方案 A 的内部架构原则”。 ### CEO 视角审查 #### 0A. 前提挑战 | 前提 | 结论 | 原因 | | --- | --- | --- | | 双主线：资源监控覆盖 + 告警事件闭环 | 通过 | 用户明确指出 A 与 B 都重要；蓝图把资源监控作为底座、告警闭环作为主线，方向正确。 | | 事件生命周期是业务主轴 | 通过 | 招标清单按菜单组织，但验收价值来自故障从发现到关闭的证据链。 | | 第 1 阶段从关键样例开始而非全厂商覆盖 | 有风险但可接受 | 这是唯一可落地方式，但需要验收矩阵明确“不等于全量厂商适配”。 | | 工单、知识库、报表、大屏围绕事件链路 | 通过 | 能避免展示层空转。 | | 第 0 阶段现场确认优先 | 通过 | 当前最大未知是现场设备、协议、账号、通知渠道和是否允许模拟故障。 | #### 0B. 现有资产复用 | 子问题 | 现有资产 | 复用决策 | | --- | --- | --- | | 后端分层、配置、DB、Redis、JWT、路由 | `templates/server_sample/` | 作为初始化来源，实际代码必须落到 `server/`。 | | 前端 Vue 3、Arco、Vite、Pinia、i18n 风格 | `templates/front_sample/standard` | 作为初始化来源，实际代码必须落到 `web/`。 | | 需求和 OPS 编号 | `docs/integrated-ops-platform-requirements.md` | 作为需求源，不直接等同开发范围。 | | 验收矩阵 | 缺失 | 必须新增 `docs/首期验收矩阵.md`。 | | 交付待办 | 缺失 | 已新增 `TODOS.md`。 | #### 0C. 目标状态 ```text 当前状态 需求清单完整，但仓库只有文档和模板，尚无实际交付工程。 运维现状假设为多工具、手工台账、人工派单。 | v 当前计划 用事件生命周期组织平台：资源上下文 -> 原始信号 -> 告警 -> 事件 -> 工单 -> 知识/报表/大屏。 用分层能力底座保证后续多协议、多厂商、多资源扩展。 | v 12 个月理想状态 医院关键业务系统、资源、告警、工单、资产、拓扑、报表形成统一运维事实库。 告警质量可度量，规则可优化，自动化处置有审批、回滚和审计。 ``` #### 0C 补充：替代方案对比 | 方案 | 完整度 | 工作量 | 风险 | 结论 | | --- | --- | --- | --- | --- | | 最小可行：只做告警闭环 + 少量资源样例 | 7/10 | 中 | 中 | 太窄，无法满足用户强调的资源覆盖主线。 | | 事件生命周期 + 分层底座 | 10/10 | 大 | 中 | 采用。与用户选择一致。 | | 完整模块矩阵 | 7/10 | 很大 | 高 | 只保留为需求映射，不作为工程主结构。 | #### 审查项 1-11 | 审查项 | 结果 | | --- | --- | | 架构 | 方向正确，但实现前需要补 ER 模型、状态机和部署顺序。 | | 错误与救援 | 当前计划列出了失败概念，但缺完整救援登记表；每类失败都需要重试、降级、用户提示、日志和审计。 | | 安全 | 计划之外发现 P0：Git 远程地址含明文凭据；计划内还需定义凭据存储、数据权限和策略变更审计。 | | 数据流与交互 | 采集、告警、通知、派单、报表、大屏都需要明确空值、空列表、错误、部分成功的处理方式。 | | 代码质量 | 当前尚无业务代码，主要风险是把模板命令和部署说明不加区分地复制进实际交付；后续需要明确本地开发使用 Windows PowerShell，验收部署面向 Linux/麒麟。 | | 测试 | 已有测试意图，但缺覆盖矩阵；工程测试计划产物已生成。 | | 性能 | 需要补 p99 目标、背压、索引、分页、告警风暴处理和报表范围限制。 | | 可观测性 | 概念较强，但平台自监控不足：采集失败、队列积压、通知失败、规则命中率都要有指标。 | | 部署 | 已有交付形态，但缺本地初始化、Linux/麒麟部署、迁移回滚和烟测脚本。 | | 长期演进 | 第 1/2/3 阶段路线合理；主要技术债风险是第 1 阶段跳过 ER 和状态定义导致模型反复变动。 | | 设计与体验 | 界面范围真实，但需要页面层级、状态表、响应式和无障碍细节。 | #### 错误与救援登记表 | 路径 | 可能问题 | 救援状态 | 救援动作 | 用户可见表现 | | --- | --- | --- | --- | --- | | 采集任务执行 | 设备不可达、凭据错误、协议超时 | 已规划但需细化 | 重试、标记采集失败、生成平台内部告警 | 资源详情显示采集失败原因和最近成功时间 | | Trap/Syslog 接收 | 格式未知、OID 字典缺失、规则不匹配 | 已规划但需细化 | 入原始事件池，标记未解析，允许补规则重放 | 告警中心显示未解析事件数量 | | 告警规则执行 | 阈值错误、规则过宽、重复触发 | 已规划但需细化 | 规则校验、去重、抑制、规则命中审计 | 策略页显示命中和降噪效果 | | 通知发送 | 站内消息、短信、邮件失败 | 缺口 | 按渠道重试，记录失败原因，允许人工补发 | 通知历史显示失败和重试状态 | | 自动派单 | 无匹配处理人、权限不足、重复派单 | 缺口 | 回退待分派队列，阻止重复工单 | 告警详情显示派单失败和建议动作 | | 报表生成 | 数据量过大、时间范围无数据、导出失败 | 缺口 | 限制范围、异步生成、失败可重试 | 报表页显示进度、空态或失败原因 | #### 失败模式登记表 | 路径 | 失败模式 | 救援状态 | 是否测试 | 用户是否可见 | 是否记录日志 | | --- | --- | --- | --- | --- | --- | | 采集任务 | 代理离线 | 部分覆盖 | 必须测试 | 是 | 必须记录 | | 告警治理 | 告警风暴导致通知轰炸 | 部分覆盖 | 必须测试 | 是 | 必须记录 | | 通知 | 第三方渠道不可用 | 缺口 | 必须测试 | 是 | 必须记录 | | 工单 | 并发关闭同一工单 | 缺口 | 必须测试 | 是 | 必须记录 | | 权限 | 越权查看其他科室资源 | 缺口 | 必须测试 | 拒绝访问 | 必须记录 | | 报表 | 大范围查询拖慢数据库 | 缺口 | 必须测试 | 是 | 必须记录 | #### CEO 审查小结 ```text +====================================================================+ | CEO 计划审查小结 | +====================================================================+ | 审查模式 | 选择性扩展 | | 系统审计 | 文档完整，工程目录缺失，Git 远程凭据风险 | | 步骤 0 | 保留事件生命周期主轴，吸收分层底座 | | 第 1 项（架构） | 发现 3 个问题 | | 第 2 项（错误） | 映射 6 条错误路径，存在 4 个缺口 | | 第 3 项（安全） | 发现 2 个问题，其中 1 个高严重度 | | 第 4 项（数据/体验） | 映射 6 个边界场景，5 个尚未处理 | | 第 5 项（质量） | 发现 1 个问题 | | 第 6 项（测试） | 已生成覆盖图，存在 8 个缺口 | | 第 7 项（性能） | 发现 4 个问题 | | 第 8 项（可观测） | 发现 5 个缺口 | | 第 9 项（部署） | 标记 4 个风险 | | 第 10 项（未来演进） | 可逆性 4/5，技术债 3 项 | | 第 11 项（设计） | 发现 5 个问题 | +--------------------------------------------------------------------+ | 非范围项 | 已写入 | | 已有资产 | 已写入 | | 目标状态差距 | 已写入 | | 错误/救援登记表 | 6 条路径，4 个关键缺口 | | 失败模式 | 共 6 项，4 个关键缺口 | | TODOS.md 更新 | 已写入 9 项 | | 范围提案 | 无需用户额外挑战 | | 外部声部 | 本轮未启用 | | 完整性选择 | 9/9 项选择完整方案 | | 已产出图示 | 架构、数据流、状态、回滚 | | 未决决策 | 0 | +====================================================================+ ``` ### 设计视角审查 #### 设计评分 | 维度 | 分数 | 发现 | 自动决策 | | --- | --- | --- | --- | | 信息架构 | 6/10 | 页面清单清楚，但每页首要/次要/三级信息未定义。 | 实现前补信息架构表。 | | 交互状态 | 4/10 | 缺加载、空态、错误、成功、部分成功、无权限状态表。 | 写入 P0 待办。 | | 用户旅程 | 6/10 | 端到端故障故事存在，但一线值班、专项管理员、负责人视角未拆。 | 补用户旅程故事板。 | | 模板化风险 | 7/10 | 蓝图偏功能性，风险较低；但大屏/首页容易做成模板化卡片堆叠。 | 要求密集、可扫描的运维界面，避免装饰性卡片堆叠。 | | 设计系统一致性 | 5/10 | 无 `DESIGN.md`，只能依赖 Arco 模板风格。 | 等 `web/` 初始化后再补设计系统文档。 | | 响应式与无障碍 | 3/10 | 不做独立移动端，但仍需定义移动端适配、键盘、屏幕阅读器、颜色对比。 | 增加 P0 UI 状态、响应式和无障碍规格。 | | 未决设计决策 | 5/10 | 告警中心、工单、拓扑、大屏的布局和状态细节待定。 | 保留为设计任务，不阻塞蓝图批准。 | #### 页面结构草图 ```text 运维入口 ├─ 首页总览 │ ├─ 待处理告警 │ ├─ 资源健康 │ ├─ 告警趋势 │ └─ 快捷入口 ├─ 综合监控 │ ├─ 资源列表 │ └─ 资源详情 -> 指标趋势 / 采集状态 / 关联告警 ├─ 告警中心 │ ├─ 实时告警 │ ├─ 事件归并 │ ├─ 策略与通知 │ └─ 历史与导出 ├─ 工单管理 ├─ 业务系统视图 ├─ 拓扑/IPAM/资产 ├─ 报表与大屏 └─ 权限与系统管理 ``` #### 必需交互状态表 | 功能 | 加载 | 空态 | 错误 | 成功 | 部分成功 | 无权限 | | --- | --- | --- | --- | --- | --- | --- | | 首页总览 | 骨架屏 | 引导接入资源 | 数据源失败提示 | 展示核心指标 | 部分组件降级 | 隐藏无权限模块 | | 综合监控 | 表格加载 | 引导新增/导入 | 采集失败摘要 | 资源健康展示 | 部分指标缺失 | 数据权限提示 | | 告警中心 | 告警流加载 | 无待处理告警 | 规则/查询失败 | 可确认/派单 | 部分渠道失败 | 操作按钮禁用 | | 工单管理 | 列表加载 | 无工单 | 流转失败 | 状态更新 | 通知失败但工单保留 | 无权转交/关闭 | | 报表大屏 | 图表加载 | 无统计数据 | 生成失败 | 可查看/导出 | 部分组件无数据 | 不显示敏感数据 | #### 设计审查小结 ```text +====================================================================+ | 设计计划审查小结 | +====================================================================+ | 系统审计 | 无 DESIGN.md，界面范围已确认 | | 步骤 0 | 初始评分 5/10 | | 第 1 轮（信息架构） | 6/10 -> 8/10，已补层级草图 | | 第 2 轮（状态） | 4/10 -> 7/10，已补状态表 | | 第 3 轮（旅程） | 6/10 -> 7/10，仍需拆分用户角色 | | 第 4 轮（模板化） | 7/10 -> 8/10 | | 第 5 轮（设计系统） | 5/10 -> 5/10，等待 web/DESIGN.md | | 第 6 轮（响应式） | 3/10 -> 5/10，仍需具体规格 | | 第 7 轮（决策） | 4 项已解决，3 项延后 | +--------------------------------------------------------------------+ | 总体设计评分 | 5/10 -> 7/10 | +====================================================================+ ``` ### 工程视角审查 #### 架构图 ```text +----------------------+ | web/ Vue 界面 | +----------+-----------+ | v +----------------------+ | server/ REST API | | 认证 / RBAC / 审计 | +----+----------+------+ | | +--------------+ +----------------+ v v +-------------+ +----------------+ +-------------+ | 资源台账 |<---->| 事件治理 |-->| 流程闭环 | | 资源模型 | | 原始/告警/事件 | | 工单/知识库 | +------+------+ +-------+--------+ +------+------+ | | | v v v +-------------+ +----------------+ +-------------+ | 采集器 | | 通知渠道 | | 报表 | | H3C/SNMP | | 站内/短信/邮件 | | 大屏 | +------+------+ +-------+--------+ +------+------+ | | | v v v 外部设备 外部通知渠道 PostgreSQL + 时序库 ``` #### 状态机 ```text 告警 触发中 -> 已确认 -> 已恢复 -> 已忽略 -> 已失效 非法：已恢复 -> 触发中，除非有新的原始事件 事件 待处理 -> 已分派 -> 处理中 -> 已解决 -> 已关闭 -> 已挂起 -> 处理中 非法：已关闭 -> 处理中 工单 已创建 -> 已接单 -> 已关闭 -> 已转交 -> 已接单 -> 已挂起 -> 已重启 -> 已接单 -> 已撤回 非法：已关闭 -> 已转交 ``` #### 测试覆盖图 ```text 代码路径 / 数据流 测试要求 [+] 资源纳管 接口集成测试 + API 测试 ├─ 正常：创建资源并绑定类型 必须覆盖 ├─ 空态：暂无资源 必须覆盖 └─ 错误：重复身份 / 非法 IP 必须覆盖 [+] 采集任务执行 单元测试 + 集成测试 ├─ 正常：指标样本入库 必须覆盖 ├─ 错误：超时 / 凭据失败 必须覆盖 └─ 部分成功：部分指标缺失 必须覆盖 [+] 原始事件 -> 告警 -> 事件 单元测试 + 集成测试 ├─ 去重 / 压缩 / 抑制 必须覆盖 ├─ 抖动 / 告警风暴 必须覆盖 └─ 恢复 必须覆盖 [+] 通知路由 集成测试 ├─ 成功 必须覆盖 └─ 第三方失败 / 重试 必须覆盖 [+] 告警 -> 工单流程 端到端测试 ├─ 分派 / 接单 / 转交 / 关闭 必须覆盖 └─ 并发关闭 必须覆盖 [+] 报表和大屏 集成测试 + 端到端测试 ├─ 聚合准确 必须覆盖 ├─ 查询范围无数据 必须覆盖 └─ 大范围查询保护 必须覆盖 ``` 测试计划产物：`C:\Users\27105\.gstack\projects\ops\27105-main-eng-review-test-plan-20260621-152008.md` #### 工程发现 | 领域 | 发现 | 严重度 | 决策 | | --- | --- | --- | --- | | 安全 | Git 远程地址含嵌入式凭据。 | 已记录风险 | 用户已明确要求忽略该项，不作为当前交付阻塞；后续推送、共享仓库或交付前建议重新评估。 | | 仓库整洁 | `.gitignore` 忽略 `docs/`，导致核心交付文档不出现在 Git 状态中。 | P0 | 决定移除忽略规则，或显式强制添加指定文档。 | | 架构 | 数据模型和状态机只是隐含存在，尚不足以指导实现。 | P1 | 编码前补 ER 和状态模型。 | | 测试 | 计划强调测试，但缺具体测试矩阵。 | P1 | 已生成测试计划产物，并写入 TODO。 | | 部署 | 本地开发路径、Linux/麒麟验收部署、迁移回滚和烟测脚本尚未成文。 | P1 | 文档需要区分本地 Windows PowerShell 命令和验收环境 Linux/麒麟部署说明。 | | 性能 | 缺告警风暴处理和报表查询范围限制。 | P1 | 补背压、分页、索引和异步导出。 | #### 并行实施策略 | 线路 | 工作流 | 模块 | 依赖 | | --- | --- | --- | --- | | A | 资源模型 + 指标 | `server/internal/models`、`server/internal/logic/monitoring` | 无 | | B | 前端壳层 + 路由 | `web/src/router`、`web/src/views`、i18n | 无 | | C | 事件/告警引擎 | `server/internal/logic/alerting` | A | | D | 工单/流程 | `server/internal/logic/ticketing` | C | | E | 报表/大屏 | `server/internal/logic/reports`、`web/src/views/dashboard` | A + C | | F | 部署/测试产物 | `deploy/`、docs、CI | A + B 骨架 | 先启动 A 和 B。C 等待 A。D 和 E 等待 C。F 可以在初始服务和前端骨架存在后开始。 ### 开发体验审查 #### 开发者画像 | 字段 | 内容 | | --- | --- | | 角色 | 项目交付工程师，负责从模板初始化实际 `server/`、`web/`、`deploy/` 并完成验收材料。 | | 场景 | 拿到招标需求和蓝图后，需要快速搭出可运行系统、可测试 API、可演示 UI。 | | 可接受等待 | 30-60 分钟内应能跑通后端健康检查和前端开发服务。 | | 期望 | Windows PowerShell 命令、配置示例、迁移命令、测试命令、演示数据准备脚本。 | #### 开发者体验叙述 我打开仓库，`README.md` 只有 `ops`。我能在 `docs/` 找到需求和蓝图，但不知道下一步该初始化 `server/` 还是先写验收矩阵。模板 README 有不少可用信息，但里面混有 Linux/macOS 命令和 systemd 部署示例，和本项目“Windows PowerShell”要求冲突。作为交付工程师，我最需要的是一条清晰路径：复制哪个模板、改哪些服务名、配置哪个 example、执行哪些 PowerShell 命令、如何跑测试、如何准备一条告警闭环演示数据。现在这些都散在模板和蓝图里，还没有形成可复制的入门路径。 #### 开发体验基准 | 工具/流程 | 首次跑通时间 | 关键开发体验选择 | 来源 | | --- | --- | --- | --- | | 当前 OPS 仓库 | >30 分钟 | README 缺少启动路径 | 当前仓库 | | 第 1 阶段目标 | <15 分钟 | 一条 PowerShell 初始化脚本 + 示例配置 + 演示数据 | `/autoplan` 目标 | | 同类内部交付流程 | 5-15 分钟 | 模板复制后即可健康检查 | 参考基准 | #### 开发体验评分 | 维度 | 分数 | 发现 | | --- | --- | --- | | 入门路径 | 3/10 | README 不足，实际工程目录未初始化。 | | API/CLI | 5/10 | 模板有 CLI，但 OPS 命令未定义。 | | 错误信息 | 4/10 | 蓝图要求统一响应，但未定义错误码、原因和修复建议。 | | 文档 | 5/10 | 需求和蓝图强，开发手册缺失。 | | 升级路径 | 3/10 | 版本、迁移、回滚策略未定义。 | | 开发环境 | 4/10 | Windows PowerShell 路径未成文。 | | 社区/生态 | 不适用 | 内部交付项目，不作为核心评分。 | | 开发体验度量 | 4/10 | 尚未定义首次跑通时间、验收脚本运行时间、失败率。 | 开发体验总体评分：4/10。目标：第 1 阶段开发者从获取代码到后端健康检查 + 前端启动 <15 分钟。 #### 开发体验实施清单 - [ ] README 增加“从零开始”的 PowerShell 路径。 - [ ] `server/etc/app.example.yaml` 和本地配置说明。 - [ ] `deploy/` 提供初始化、迁移、演示数据、烟测脚本。 - [ ] 错误响应包含 `code`、`message`、`traceId`、`cause`、`suggestion`。 - [ ] 每个核心 API 提供请求/响应示例。 - [ ] 测试命令和验收命令可复制执行。 ### 决策审计轨迹 | # | 阶段 | 决策 | 分类 | 原则 | 理由 | 被拒绝方案 | | --- | --- | --- | --- | --- | --- | --- | | 1 | 输入 | 使用当前蓝图作为计划文件 | 机械决策 | 倾向行动 | 用户在 office-hours 计划后立即调用 `/autoplan`。 | 等待 D10 再审查 | | 2 | CEO | 保留事件生命周期作为主轴 | 机械决策 | 选择完整性 | 同时保留 A+B，并避免菜单孤岛。 | 模块矩阵作为主架构 | | 3 | CEO | 将分层底座作为内部架构原则 | 机械决策 | 显式优先 | 与用户明确选择一致。 | 单独走底座优先交付 | | 4 | CEO | 为验收矩阵和模型/状态规格增加 TODO | 机械决策 | 限定范围 | 这些事项在当前影响范围内，并能解除实现阻塞。 | 延后所有规划债 | | 5 | 设计 | UI 实现前必须补状态表 | 机械决策 | 选择完整性 | 空态、错误、部分成功、无权限是运维界面的核心状态。 | 让实现者自行推断状态 | | 6 | 工程 | 生成测试计划产物 | 机械决策 | 选择完整性 | 测试必须在代码实现前规划。 | 等实现后再补测试 | | 7 | 工程 | 将含凭据 Git 远程地址标记为 P0 | 机械决策 | 安全 | 远程地址中的凭据虽不属于产品范围，但会危害仓库协作。 | 当作环境细节忽略 | | 8 | 开发体验 | 要求本地 PowerShell 入门路径，并补 Linux/麒麟验收部署说明 | 机械决策 | 显式优先 | 本地开发按项目规则使用 Windows PowerShell；验收部署按会议结论面向 Linux/麒麟。 | 直接复用模板 README | ### 跨阶段主题 **主题：显式运维证据。** CEO、工程、设计和开发体验审查都指向同一个缺口：平台方向已经成立，但每个阶段都需要证据产物。验收矩阵、状态表、测试计划、烟测脚本和演示数据不是文档负担，而是产品可验收性的证明。 **主题：不要让模板痕迹泄漏进交付。** 工程和开发体验审查都指出了这一点。模板有价值，但实际 `server/`、`web/`、`deploy/` 文档必须符合 Windows PowerShell、UTF-8 中文文档、密钥卫生和项目专属服务命名要求。 ### 不在当前范围 - 第 1 阶段不承诺全厂商覆盖，需等现场设备清单确认后再扩展。 - 第 1 阶段不承诺完整拓扑、IPAM、机柜和深度资产套件，这些属于第 2 阶段资源上下文增强。 - AI 规则优化和自动化处置属于第 3 阶段治理与智能化能力。 - 本轮为文本审查，未生成视觉稿；视觉稿应在 `web/` 初始化和界面范围明确后再做。 ## GSTACK 审查报告 | 审查 | 触发 | 目的 | 次数 | 状态 | 发现 | | --- | --- | --- | --- | --- | --- | | CEO 审查 | `/autoplan` | 范围与策略 | 1 | 存在待处理问题 | 方向成立；需要补验收矩阵、模型/状态规格、失败登记表，并修复文档版本管理问题。 | | 设计审查 | `/autoplan` | UI/UX 缺口 | 1 | 存在待处理问题 | 5/10 -> 7/10；缺详细状态、响应式、无障碍和 `DESIGN.md`。 | | 工程审查 | `/autoplan` | 架构与测试 | 1 | 存在待处理问题 | 发现 5 个高价值缺口；测试计划产物已写入；含凭据 Git 远程地址风险已记录，用户已确认不作为当前阻塞项。 | | 开发体验审查 | `/autoplan` | 开发体验缺口 | 1 | 存在待处理问题 | 总体 4/10；缺 README 入门路径、PowerShell 文档和部署文档。 | | 外部审查声部 | `/autoplan` | 独立审查 | 0 | 本轮未启用 | 后续如需运行 Codex CLI 且遇到权限拒绝，应先向用户申请权限。 | - **结论：** 架构方向已批准。编码前必须完成的文档规格已补齐：`docs/首期验收矩阵.md`、第 1 阶段数据模型和状态机、UI 状态覆盖。含凭据 Git 远程地址风险已按用户要求忽略，不作为当前交付阻塞项。 - **Codex CLI：** 本轮未作为独立声部运行；后续如果因权限问题被拒绝，将先向用户申请权限。 - **跨模型审查：** 本轮未运行，仅保留主审查结论。 **审批结论：** - 用户已选择 A：按当前方案批准蓝图方向。后续进入 P1 待办处理与第 1 阶段实施准备；Git 远程凭据风险已按用户要求忽略，不作为当前交付阻塞项。