NWP业务系统监控平台设计思考
目录
本文介绍笔者在今年上半年对 NWP 业务系统监控平台相关工作的一些思考，介绍当前现状，并给出一种未来发展的计划方案。
声明：本文仅代表笔者个人观点，文章中引用的相关材料仅用于探讨和交流，不能作为最终事实依据。 关于 NWP 业务系统的相关信息，请以官方发布的信息及经过同行评议的论文为准。 如有任何疑问，建议查阅权威资料或咨询相关领域的专家。
现状
NWP 业务系统监控平台包括两个部分，下图给出了两个部分的示意图
图 NWP 业务系统监控平台现状
业务集成与控制
功能
- 运行流程构建
- 实时运行
- 运行监控（ecFlow 界面）
- 故障处理
业务运行监控
功能
- 运行监视（Web）
- 故障告警（微信）
- 运行信息展示
- 运维管理（故障记录、更新记录、值班管理）
存在问题
研发到业务（R2O）
- 每个系统单独建立 ecFlow 流程，系统之间缺乏代码/组件共享
- 研发和业务运行流程不一致 (shell vs ecFlow)，显著增加业务部署成本
- 系统建设在业务运行账户中直接进行，过于依赖开发人员的经验，缺少自动集成、自动部署功能
业务到研发（O2R）
- 监控网站仅面向运维需求开发，缺乏为模式研发人员提供业务运行信息
- 故障分类过于简单，没有与系统更新相关联，缺少事务跟踪管理功能
监控
- HPC 登录节点运行 ecFlow ，业务监控严重依赖超算，不方便同时监控多个超算上的业务系统
- 网站前后端紧密耦合，依赖单一供应商的技术，存在供应链风险
- 运行信息种类过少，需要在系统运行时生成更多运行信息，详细记录系统运行流程信息
计划
下图展示了 NWP 业务系统监控平台未来发展的一种方案，形成 4 种相互关联的服务：
- 集成部署服务
- 工作流调度服务
- 运行监控服务
- 事务追踪管理服务
图 NWP 业务系统监控平台发展的一种方案
不同角度的功能特点
R2O
- 版本库 + 集成部署服务
O2R
- 版本库 + 事务追踪管理服务
- 业务运行网站服务
监控
- 工作流调度服务
- 运行监控服务
- 业务运行网站服务
