ops/docs/integrated-ops-platform-blueprint-design.md

一体化运维平台完整蓝图与分期落地方案

生成来源：/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 告警最佳实践强调：告警应面向一线响应人，必须可理解、可行动；基础设施信号适合辅助诊断，不应全部作为高优先级打扰；需要分组、抑制抖动和定期复盘。参考：https://grafana.com/docs/grafana/latest/alerting/guides/best-practices/
• ServiceNow ITOM 强调跨监控工具聚合事件、服务映射、去重、关联和突出可行动告警。参考：https://www.servicenow.com/products/it-operations-management.html
• Atlassian 事故管理强调可重复的记录、诊断、解决和活动留痕。参考：https://www.atlassian.com/incident-management
• PagerDuty Event Orchestration 把动态路由、事件规则和事件编排作为告警治理核心能力。参考：https://support.pagerduty.com/main/docs/event-orchestration
• TDengine TSDB 官方文档说明其面向物联网、工业互联网、金融、IT 运维等时序场景，提供 SQL、连接器、集群、流式计算和数据订阅能力。参考：https://docs.taosdata.com/
• Apache IoTDB 官方介绍其定位为工业物联网时序数据库，支持边云协同、多协议兼容、高压缩比、高吞吐读写和 Grafana 等生态集成。参考：https://iotdb.apache.org/
• openGemini 官方介绍其聚焦可观测性海量数据存储与分析，支持指标、日志、链路数据存储，具备分布式集群、高基数和压缩能力。参考：https://opengemini.org/

结论：招标需求应按事件生命周期重组，而不是按菜单平铺；指标和采集样本需要单独进行国产/国内生态时序数据库选型，避免 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. 目标状态

当前状态
  需求清单完整，但仓库只有文档和模板，尚无实际交付工程。
  运维现状假设为多工具、手工台账、人工派单。
        |
        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 审查小结

+====================================================================+
|                    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	告警中心、工单、拓扑、大屏的布局和状态细节待定。	保留为设计任务，不阻塞蓝图批准。

页面结构草图

运维入口
  ├─ 首页总览
  │   ├─ 待处理告警
  │   ├─ 资源健康
  │   ├─ 告警趋势
  │   └─ 快捷入口
  ├─ 综合监控
  │   ├─ 资源列表
  │   └─ 资源详情 -> 指标趋势 / 采集状态 / 关联告警
  ├─ 告警中心
  │   ├─ 实时告警
  │   ├─ 事件归并
  │   ├─ 策略与通知
  │   └─ 历史与导出
  ├─ 工单管理
  ├─ 业务系统视图
  ├─ 拓扑/IPAM/资产
  ├─ 报表与大屏
  └─ 权限与系统管理

必需交互状态表

功能	加载	空态	错误	成功	部分成功	无权限
首页总览	骨架屏	引导接入资源	数据源失败提示	展示核心指标	部分组件降级	隐藏无权限模块
综合监控	表格加载	引导新增/导入	采集失败摘要	资源健康展示	部分指标缺失	数据权限提示
告警中心	告警流加载	无待处理告警	规则/查询失败	可确认/派单	部分渠道失败	操作按钮禁用
工单管理	列表加载	无工单	流转失败	状态更新	通知失败但工单保留	无权转交/关闭
报表大屏	图表加载	无统计数据	生成失败	可查看/导出	部分组件无数据	不显示敏感数据

设计审查小结

+====================================================================+
|                    设计计划审查小结                                |
+====================================================================+
| 系统审计             | 无 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                                 |
+====================================================================+

工程视角审查

架构图

                 +----------------------+
                 |    web/ Vue 界面     |
                 +----------+-----------+
                            |
                            v
                 +----------------------+
                 | server/ REST API     |
                 | 认证 / RBAC / 审计   |
                 +----+----------+------+
                      |          |
       +--------------+          +----------------+
       v                                      v
+-------------+      +----------------+   +-------------+
| 资源台账    |<---->| 事件治理       |-->| 流程闭环    |
| 资源模型    |      | 原始/告警/事件 |   | 工单/知识库 |
+------+------+      +-------+--------+   +------+------+
       |                     |                   |
       v                     v                   v
+-------------+      +----------------+   +-------------+
| 采集器      |      | 通知渠道       |   | 报表        |
| H3C/SNMP    |      | 站内/短信/邮件 |   | 大屏        |
+------+------+      +-------+--------+   +------+------+
       |                     |                   |
       v                     v                   v
   外部设备              外部通知渠道        PostgreSQL + 时序库

状态机

告警
  触发中 -> 已确认 -> 已恢复
         -> 已忽略
         -> 已失效
  非法：已恢复 -> 触发中，除非有新的原始事件

事件
  待处理 -> 已分派 -> 处理中 -> 已解决 -> 已关闭
         -> 已挂起 -> 处理中
  非法：已关闭 -> 处理中

工单
  已创建 -> 已接单 -> 已关闭
          -> 已转交 -> 已接单
          -> 已挂起 -> 已重启 -> 已接单
          -> 已撤回
  非法：已关闭 -> 已转交

测试覆盖图

代码路径 / 数据流                                  测试要求
[+] 资源纳管                                      接口集成测试 + 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 远程凭据风险已按用户要求忽略，不作为当前交付阻塞项。