要有做事情的魄力和专注

thoughts
目录

当我们在一个领域中工作足够长时间后，总能看到一些当前的不足与前进的方向。 区别在于是否有魄力做出改变，是否有信心去坚持改变。

面临的挑战

最近看到国家气象信息中心同事的《ECMWF访问工作总结》，深有感触。

同事原计划主要研究模式支撑系统，并学习HPC在业务支撑和精细化资源管理和调度方面的工作，即信息中心高性能计算室主要从事的工作。 但因为某些原因调到负责业务系统集成、构建、运行维护的部门，也就是数值预报中心系统业务室的工作。

同事在一年的访问交流中

负责将数据分析平台SPLUCK应用到ECMWF现有的实时数值预报业务中， 通过对数值预报业务运行状态的抓取，对业务模式的运行数据进行挖掘，分析业务历史和实时运行状态， 实现对业务运行故障的报警和预警，特别针对模式运行关键模块延迟等异常情况， 最终可为用户提预测供预报产品可获取的时间。

第一阶段工作主要是熟悉Splunk，并分析Web访问日志。 因为我们部门不提供Web服务，所以这部分工作我几乎没有涉及。

第二阶段的工作才是我关注的重点，工作目标包括：

  1. 实现近实时的对业务模式运行状态的可视化展示并可以按需求对历史运行状态进行分析；
  2. 从简单的文本信息中挖掘有价值的模型帮助他们更好的了解业务模式运行的状态，改善模式流程并协助模式流程开发过程中的测试工作；
  3. 实现对业务模式特别是关键模块的实时监控，对于异常情况给出预警和报警以及异常的定位和详细信息；
  4. 预测模式预报产品的生产时间，如果产生延迟，可以预估产品可能的交付时间。
  5. 开发的相关Dashboards和分析结果将应用在ECMWF新数据中心的业务运行监控和展示以及他们业务运行报告和KPI评估中。

上面的工作目标与数值预报业务系统运行维护息息相关，都是我们科室正在做或者想要做的事情。

无论是国际领先的ECMWF，还是信息化水平较低的我们，大家面临的挑战都是一样的。 但区别就在于，看到问题后是否有魄力去解决，是否有毅力去坚持解决。 很遗憾，我在这方面尚有欠缺。

工作对比

上面的工作可以分为以下几点。

历史运行状态分析

从后文的介绍推测历史运行状态分析可能使用归档的ecFlow日志。

我在2015-2016年度国家气象中心青年基金课题《数值预报业务系统运行状态分析》中有过类似的研究。 相关成果可以参考2017年在第34届中国气象学会年会 “S20 气象数据：深度应用和标准化”分会场汇报的《基于SMS的数值预报运行日志分析系统》。

遗憾的是我当时没有选用成熟的数据可视化工具（例如ECMWF使用的Splunk），而是自己用AngularJS编写简易的网站。 我并没有专注JavaScript编程，导致该项目的可视化网站后续没有更新。

另外，我们的业务系统直到现在也没有对SMS或ecFlow的日志进行定期归档，该项目收集日志的方法过于繁琐，实时运行一段时间后就放弃了。

但该项目的数据处理和分析方法已被我继承到目前还在开发维护的项目中。

为了展示业务系统全天的运行状态，我开发了业务系统运行时间线，如下图所示。

2019年7月22日数值预报业务系统运行时间线

开发的项目包括：

前三个项目正处于重构当中，希望今年我能提供一套方便使用的工具。

实时状态监控

近实时的业务模式运行状态展示，对于异常情况给出预警和报警，这两项工作我已开展研究，成果已应用在业务系统中。 相关论文《数值预报业务系统移动监控平台的设计与实现》已发表在《气象科技》2018年第5期。

开发的项目包括：

对于异常的定位和详细信息，我们正在借助工程项目进行开发，今年会有一些初步的成果。

产品生成时间预测

产品的时效性一直不是我们关注的重点，我们更多关注产品是否生成。 不过最近中央气象台专门申请了运维的公众号，会通报各种资料的到达情况，其中包括我们负责维护的三个模式。 所以通过历史数据分析产品生成时间，乃至更进一步通过当前状态预测产品生成时间都应该成为我们研究的方向。

时间序列预测是一个很有意思的课题，今年争取找时间能了解一下。

程序日志挖掘

虽然我们存储了所有程序的运行日志，但还没有对日志进行过分析。 在这一方面上，我们明显落后于行业和时代。 今年会尝试进行简单的数据分析，看看能否对业务运行维护提供支持。

可视化展示

在可视化Dashboard展示方面，我们还欠缺很多。 我们没有要求统一使用 Splunk 类似的工具，所以我做大部分工具都是自己搭建简易的web页面来进行数据展示，浪费精力，效果也不好。

唯一涉及 Dashboad 的项目就是使用 Grafana 显示 Prometheus 中保存的HPC监控数据，如下图所示：

CMA-PI资源监控，使用Grafana实现

开发的项目包括：

未来方向

有对比就会有前进的动力。既然国际领先的ECMWF都在从事类似的工作，我们也应该将精力更多地投入其中。 虽然可能有一些未知的限制，自己的想法也可能会走入死胡同，但我坚信我们为提高工作效率而自己开发工具还是很有必要的。 因为只有最终的用户才知道什么样的工具是最需要的。

可以看到，同事在ECMWF工作任务中几乎每一项，我们科室都已经有过研究或者准备开展。 但区别在于，同事用一年的时间就已完成上述的任务，而我入职到现在7年时间却仍有很大的差距。

我还是缺乏做事情的魄力和专注。 我几乎每隔一段时间就换一个兴趣点，本来就不充裕的精力被不同方向的项目分散，导致每个工具都没有达到方便使用的程度。 另外，对于业务系统体系变更的谨慎也导致很多工作不愿意开展。

不过，去年我做的一些工作让我意识到其实可以对业务系统进行破坏性地更新，因为我们本身就负责维护业务系统。 同事的经验值得我们好好学习，期待正常上班后能学习交流下。

声明

本文引用的内容截取自气象局内网公示的《ECMWF访问工作总结》，经过一定的修改，原文请访问国家气象信息中心内网主页获取。