2019年个人总结
又到了每年一度的年度总结大会。在新年伊始，总会回顾过去一年的人生经历，并为接下来的一年制定雄心勃勃的计划。
去年是与众不同的一年，迎来了女儿的诞生，我也面临从角色到生活的各种挑战，经历了很多事情，也看到了自己的不足。 以后也将变得与之前完全不同，我的未来计划里面增加了另一个小生命。 看着女儿逐渐的长大，我也不能再逃避现实，忽视规划了，我的一举一动都可能会影响到女儿未来的成长。
生活
虽然这部分放到了最前面，但每次都是最后才写，导致每次写得都不是很多。
这次我也简要地写下，后面有时间再慢慢总结。
自从女儿出生，我的生活有了翻天覆地的变化。对我来说，转变角色往往需要很长的时间。 再加上7月份搬到单位的公寓，生活方式有了一些变化，可能直到现在我也没有完全适应。 无论是作息时间安排，还是生活中的各种事项，我都需要去适应，调整心态，尽量给家人以正能量。 不清楚这样的调整会有什么样的效果，但我必须尽全力去面对新的生活，去承担自己的职责。
住在单位附近最好的一点就是能多陪女儿，而我在这点上好像做得不够好。 今年我一定要时刻牢记自己最重要的职责：陪女儿一同成长。
FLAG
FLAG就是用来打脸的，看来去年也是如此。
FLAG at 2019.12
个人工作总结
我们单位的工作总结在去年12月中旬就已经结束了，我将个人工作总结的内容简要介绍下。
业务系统集成
数值预报业务系统集成是我最核心的工作任务之一。
业务系统建设
下面张图展示了2019年下半年Metcode投入应用以来与业务系统更新相关的代码提交数。 可以看到除了十月份我去参加培训以外，几乎每周都会对业务系统进行改动。 这对于我们已成立十年的业务中心来说，显得过于频繁。 当然，业务系统更新也和硬件环境的变动有关，去年我们继续将业务系统从IBM切换到PI-曙光，也将二级存储加入到业务流程中。 外部依赖环境的变化是系统更新的重要因素。
2019年下半年Metcode投入应用以来与业务系统集成相关的代码提交日历
我去年参与维护的主要业务系统主要是配合其他科室完成相关系统的建设、更新和部署，包括：
- 建设：GRAPES TYM，MUVOS
- 更新：GRAPES GFS POST
- 部署：MESO 3km POST，GRAPES TYM POST
正如我去年在几篇文章中描述的，这项任务正是目前我工作的困境所在。
现有的业务系统建设任务基本属于重复性劳动，很难在职称晋升中体现为工作业绩。 尽管从入职以来就一直听说ECMWF在构建对象化的业务系统流程，但始终没有看到具体的示例，也没有看到开展此类研究的动力和收益。 所以，即便我不能否认业务系统集成方面还有很多可以深入研究的内容，尤其是在最近看了ECMWF REPWORK 19的一些报告后，但我依然无法确定在这方面投入时间是否能带来想要的收益。当然这就会陷入一个死循环，无法摆脱重复劳动的陷阱，又不愿意迈出试探的一步。
我目前主要负责与数值模式本身关系不大的产品制作系统，与数值模式的业务系统没有太多的相似性，受众面更小。 即便我们单位准备开展这方面的研究，也不适合由我来推进，所以今年在业务系统集成方面的任务还是延续去年，按照部门的安排完成我负责的工作。
运行效率
业务系统建设不只是流程和脚本的编写，我们在很多时候需要寻找运行效率和维护成本的平衡点。
以后处理系统中一个常见的任务来说明。后处理系统需要检测数据文件是否完整。 当前业务系统中有两种检测数据完整性的方法：单任务逐时效检测和多任务同时检测。
单任务逐时效检测
多任务同时检测
这两种方式各有利弊。我开发了一个并行程序，综合这两种方式的优点，实现单个任务并发检测多个数据文件的功能。
程序源代码请访问 nwpc-oepr/nwpc-data-client。
这项工作已在《NWPC业务系统笔记：并行检查数据》博文中介绍。
分发速度
我们科一直关注我们系统提供服务的能力，因为用户发现产品缺失后会直接联系我们科的值班同事。 但产品分发速度可能并不是我们整个处室关注的重点，我在过去的报告中也很少能看到有同事介绍这方面的工作。
去年GRAPES TYM升级业务评审时，预报司的领导说不要因为优化太小而不做，整个业务系统的分发速度正是来自每个任务节省出来的1-2分钟。 所以我今年也关注如何从流程方面提高产品分发速度，这也是目前来说我们科在提高产品分发速度方面唯一能做的事情。
去年拆分了GRAPES GFS产品制作任务，将能同时做的产品尽量同时做，并且对产品进行分级，保障核心产品尽早分发。
拆分GRIB2制作任务，将产品分为不同级别，使用不同的limit限制
拆分GRIB2上传任务
另外还和台风科的同事一道优化GRAPES TYM产品制作流程，逐时效生成产品。
GRAPES TYM逐时效生成产品
去年也为所有的后处理系统增加向二级存储实时传输GRIB2数据的任务。 这项工作花费大量的功夫，仅仅是因为向二级存储传输数据的方式不稳定，总在不同的方法之间来回尝试。 这也能从一个方面说明，为什么我们单位的数据服务能力一直没有改进。没有硬件资源，数据服务又从何说起呢。
业务技术研发
我在业务技术研发方面的工作目标是提供方便使用的业务系统建设和维护工具，提高我们的工作效率。
我将业务技术研发分成四个阶段：
业务技术研发的四个阶段
我今年主要从事以下四个方面的研究。
HPC监控
slurm命令行客户端
2018年基于Python实现了slurm命令行客户端slclient，但PI-曙光上的Python程序第一次运行耗时太长。
去年使用GO语言重新实现该工具，解决Python版启动速度慢和部署困难的问题。 PI-曙光系统的共享文件系统一直有未经确认的IO问题，Python程序执行时载入大量的包文件，第一次运行的启动时间会显著增加，而GO编译的程序是二进制文件，只需要读取一个文件即可。 另外二进制文件也容易多版本并存，Python命令行工具想要同时保存多个版本不太容易。 所以后面的一些工作也可以看到，去年我将部分PI上使用的命令行工具从Python移植到Golang。
slclient查询提交到队列中的作业
程序源代码请访问 nwpc-oepr/slurm-client-go。
ecFlow监控
配合业务运行维护，对ecFlow进行二次开发，一直是我关注的重点。去年也对ecFlow监控工具进行全面的升级。
C++客户端：ecflow-client-cpp
2018年配合HPC迁移，开发了Python版本的ecFlow获取程序，并在Linux服务器上的Docker容器中部署。但远程访问ecFlow服务获取状态会有很大的延迟，与ecFlow服务的通讯没有压缩，任务节点数增多会显著影响API访问的耗时。去年将该程序部署在PI上，这样就面临与slclient一样的问题，更新和部署很不方便。
既然ecFlow的Python API是对C++接口的绑定，我也使用该C++ API实现ecFlow状态获取的客户端，方便部署。
原有的gRPC接口与监控平台应用绑定，无法向其他应用提供服务。因此在C++客户端中，我开发了新的gRPC接口，通用型更强，方便其他工具获取ecFlow的状态。
应用：提供系统状态查询和节点信息查询。
ecflow-cpp-client的grpc服务
这项工作已在《ecFlow学习笔记04：使用C++ API》博文中介绍。
程序源代码请访问 nwpc-oepr/ecflow-cpp-client。
系统检查工具：ecflow_checker
ecflow_checker 按照时间段检查ecFlow各个节点的状态是否正常。 使用ecFlow c++ 客户端项目的gRPC服务获取节点状态和节点变量的值。
评估：目前需要手动配置各个检查项的时间段。
ecflow_checker
检查项目，以符号表示检查结果
- 正常：✔
- 异常：✗
- 尚未到时间：━
程序源代码请访问 nwpc-oepr/ecflow-checker。
GOLANG客户端：ecflow-client-go
上面的ecflow_checker使用GOLANG开发，从gRPC服务获取ecFlow状态。 需要gRPC服务保持一直可用，增加了整个工具的复杂程度和部署难度。
去年我还尝试了将ecFlow的客户端集成到GOLANG中，创建了ecflow-client-go项目。
该项目对ecflow-client-cpp的C++接口进行简化，使用SWIG创建C++与GOLANG的接口，方便使用GOLANG开发监控程序。
试运行：目前仅实现系统状态查询功能。
这项工作已在《ecFlow学习笔记：使用SWIG创建golang客户端》博文中介绍。
程序源代码请访问 nwpc-oepr/ecflow-client-go。
运行状态监控工具：ecflow_watchman
上述GOLANG客户端被用于开发全新的ecFlow运行状态监控工具：ecflow_watchman。
2019年之前，获取ecflow服务的状态需要每个应用都运行采集程序。 这样的问题在于如果同时访问ecFlow服务的应用比较多，会给ecFlow服务带来繁重的压力。 即便这样的压力不会对正常使用产生太大的影响，但为了保持ecFlow的稳定，还是建议尽量少使用API获取系统状态。
2019年我全新设计了一套运行状态监控工具，引入redis数据库。 后台运行的程序会定时获取ecFlow系统的运行状态，保存到redis数据库中。 其他应用只需要定时从redis数据库读取系统状态即可，无需单独构建采集程序读取ecFlow服务状态。
该程序还使用协程基础，实现单一程序并发监听多个ecFlow服务。
应用：向其它应用提供准实时数据（1分钟间隔）
ecflow_watchman的架构
这项工作已在《ecflow学习笔记：节点状态监控工具》博文中介绍。
程序源代码请访问 nwpc-oepr/ecflow-watchman。
警告
经过长时间的测试，发现该程序由严重的内存泄漏问题，源自SWIG创建的GO与C++的接口。
详细分析及目前的解决方案请阅读《ecflow学习笔记：节点状态监控工具V2》。
监控平台
去年还在监控平台方面持续进行开发。
微信报警
去年对业务系统微信报警平台进行了升级。 因为该平台的云虚拟机是我个人租用的，所以我比较关心如何才能降低云虚拟机的预算。
去年首先将整个项目拆分为4个子项目，方便后续的维护和部署。
同时使用Serverless存储代替数据库MongoDB数据库，显著降低对云虚拟机性能的需求。
2018年需要在云虚拟机上运行MongoDB数据库，即便租用816元每年的虚拟机，也会有服务器卡死的现象发生。 2019年使用LeanCloud替换MongoDB，租用一个成本更低的虚拟机（510元每年）也能完全满足需求。
更新了ecFlow的数据获取方式，从ecflow-watchman提供的redis数据库中读取业务系统最新的状态，解决scheduler因为延时太长而卡住的问题。
未来预计我后续只关注与数据相关的运维核心技术，前端应用将由工程项目提供支持。 前端界面无论是Web形式还是桌面软件都不是我们科擅长的，交由第三方公司来做最合适不过。 但后台技术，尤其是与数据相关的核心算法与技术，还是应该由我们自己来掌握。 即便我们开发的应用可能有各种各样的问题，但我们至少能紧跟需求，也能容易控制整个项目的开发。
我认为我们不能将自己定位成一个设计者，把具体实现都交给公司来完成，这样对我个人的成长没有任何益处。 脱离代码是一件很有风险的事情，如果不能站到很高的位置，就只能绑定与当前的工作环境绑定，丧失了在职场中的灵活性。 再加上我个人比较喜欢编程，所以只当需求方的工程类项目对我没有任何用处，我也就没有必要参与其中。
气象中心消息库：nmc-message-client
之前我构建监控平台都是以一个观察者的身份从外部监视业务系统。 今年气象中心建立的综合运维监控平台，我为该平台的消息库开发命令行客户端，添加到业务系统的脚本中。
试运行：发送“GFS的GRIB2产品成功生成”的消息。
项目源代码请访问nwpc-oper/nmc-message-client。
NWPC消息库：nwpc-message-client
既然上述方式行得通，我觉得我们应该构建自己的消息库。 根据实际的需要，发布业务系统的各类运行信息。 采用消息中间件技术，支持多个应用同时订阅不同类型的消息。
评估：发送“GFS的GRIB2产品完成上传”，支持加工流水线项目。
计划2020年逐步集成到所有业务系统中。
nwpc-message-client的架构
项目源代码请访问nwpc-oper/nwpc-message-client。
数据工具
数据工具之前并不是我关注的重点，从去年开始维护后处理系统以来，发现我们在某种程度上缺乏合适的数据工具，所以对开发数据工具也就有了一些兴趣。
我们使用的数据工具大多是国际上气象业务中心开源的，例如wgrib2和eccodes。 我一直都是开源的坚定拥护者，但入职这么多年来，无论是我们中心还是整个气象局，似乎都没有开源的迹象。 虽然我放到Github上的项目没有人关注，但这正好说明我做的项目没有吸引力，我应该好好研究下如何才能提高项目的价值 也可能是我做的项目应用受限制，其他地方无法使用，我应该好好思考如何才能开发更通用的项目。
我在年终总结的时候尝试宣传开源思想，可能没有什么效果。 我个人不负责任地猜测，大家不是担心开源会泄漏国家机密，就是担心开源会被他人抄袭成果。 对于第一点，如果项目的代码库包含敏感信息，就说明项目本身就有问题，敏感信息就不应该出现在代码库中。 第二点就在于对个人成果的看法，我个人觉得抄袭之类的事情无法避免，只要我们一直保持更新升级速度，就不用担心跟在我们后面的抄袭者会占用我们的成果。 如果依赖闭源项目想要达到“他人免进”的效果，只会让自己越来越懈怠，很有可能被弯道超车。
这点上就不能不提一下气象信息中心，作为领域内唯一指定的信息化负责单位，我在网上却从来没有找过与之相关的开源项目。这与世界上主流气象业务中心在信息化领域的风格不太一致。 不过，令我欣喜的是，今年终于看到气象中心的技术研发室开始将内部使用的工具在Github上开源，更坚定了我将工作项目全都开源的信念。
数据访问：nwpc-data-client
2018年使用Python开发了业务数据的访问工具，根据路径列表，查找业务系统生成的数据产品。
2019年使用GO语言重写该工具，方便部署和多版本共存。
同时，使用gRPC技术实现远程获取二级存储上数据文件的功能，今年会和同事一道评估该技术是否能适合我们正在搭建的数据平台。
应用：集成到部分产品后处理系统中
评估：远程获取二级存储上的文件
使用gRPC远程下载二级存储上的数据文件
项目源代码请访问nwpc-oper/nwpc-data-client。
数据处理：nwpc-codes-cpp
2019年本来想学习NetCDF和HDF两种数据格式，结果只复习了一边GRIB2格式。 将之前写的GRIB2样例文件分析重新整理为一系列文章，参看《GRIB学习笔记：样例文件分析 - 概要》。
作为对学习GRIB2数据格式的总结，开发了nwpc-codes-cpp，解码GRAPES模式的GRIB2数据。 仅支持GRAPES模式数据使用到的少量模板，整个项目相比ecCodes而言功能很有限，但结构更清晰。
该项目使用C++17实现，支持Windows和Linux。测试开发环境：
- Windows下使用Visual Studio 2019编译
- PI-曙光上使用GNU 9.2.0编译
运行时需要读取ecCodes的definition文件。
jpeg编解码函数来自ecCodes，但ecCodes相关代码来自openjpeg社区。
编码参数bitsPerValue等计算参考wgrib2源码。
构建：提供类似ecCodes的命令行工具
项目源代码请访问perillaroc/nwpc-codes-cpp。
实现细节可以参考去年写的部分文章：
CIMISS访问接口：nuwe-cimiss-python
去年信息中心释放了2.0版本的MUSIC接口，使用protobuf实现序列化。
我开始对MUSIC接口感兴趣，基于MUSIC接口Python SDK 2.0版开发了nuwe-cimiss-python项目。
使用Python 3重写代码，提供常用功能（部分功能目前能获取的账号没有权限），使用相似的API接口。 替换不常用的库，支持Windows和Linux操作系统。
项目源代码请访问perillaroc/nuwe-cimiss-python。
详细介绍请阅读《改造CIMISS MUSIC接口的Python SDK》。
科研项目
科研项目方面，2018年在数值预报中心青年基金《基于分布式调度的绘图技术研究》的支持下，开发了分布式绘图调度系统 ploto。 2019年继续开发该系统，更新了任务的执行机制，并将该系统应用到重点研发专项《地球系统模式公共软件平台研发》中。 支持项目组开发的数据平台，并集成地球模式诊断工具dongli/esmdiag。
ploto集成esmdiag的架构
工程项目
工程项目方面，在海洋工程一期《全球台风数值预报子系统》项目的支持下继续开发模式试验分析工具。
2019年重新编写了整个软件，设计了全新的界面，并采用插件体系结构重新搭建程序框架。
支持本地数据，包括GRIB2数据和台风产品。也通过SFTP协议支持访问远程服务器上的GRIB2数据。
移植2018版本的大部分可视化功能。支持多窗口显示；支持多张交互操作，包括投影切换，绘制剖面图、廓线图等；2019年还新增对台风图形的绘制。
另外该工程项目还开发了台风可视化Web显示系统。
培训
2019年10月8日到11月2日，参加了大气科学基础知识培训班面授学习，获得优秀学员。 学习的心得体会请阅读《大气科学基础知识培训班结业》。
2019年还参与了单位的新员工培训，介绍高性能计算机环境和UNIX命令。 高性能计算机环境的介绍内容已整理为一系列文章，请参看《NWPC高性能计算机环境介绍》。
未来计划
简单介绍一下在年终总结的时候写的未来计划，现在看有些内容值得商榷。
业务系统建设
研究业务系统的模块化
去年年底，领导让我们关注ECMWF REPWORK 19研讨会。 看了部分报告后，我在年底做计划时提到要研究模块化。 不过，最近半个月来的观察和分析，我在怀疑是否有做这项工作的必要。 前面也分析过，我主要负责产品后处理系统的建设，与模式本身关系不大。 再加上这方面的工作在中试平台中已经开展，我就更没有必要在这方面投入精力。 另外，整个部门也没有这方面的计划，所以这项计划就废弃掉吧。
业务技术研发
应用NWPC消息库
这项工作是今年的主要方向之一。尽管大家都在做类似的系统，我觉得我还是可以做一些适合我们业务系统的工具库。 工作会上主任提到我们应该关注其他部门在做什么，尽量避免重复。 但我所面向的数值预报业务系统有一些具体的需求，如果由我们自己开发，后续的更新和维护就会比较顺畅。 另外，我觉得重复造轮子并不可怕，不怕同行竞争，就怕没有一颗迎难而上的心。
科研项目
地球系统模式公共软件平台研发项目
研究使用工作流执行诊断绘图任务。这项工作已经在开展。
集成地球模式诊断包：ESMValGroup/ESMValTool。 这项工作之前让公司在研究，但没有经费支持很难有显著的进展，没有进展又不会给经费支持，不知道公司有没有看清楚这一点。 还是我多投入些精力研究下吧。
工程项目
专注通用的底层软件库和工具研发
工程项目方面之前的文章中也提到了想要退出桌面版交互诊断软件的开发，不过现在看来退出不一定是一件容易的事情。 今年我会从另一个角度开展研究，原来的方向得想想如何保留之前的开发成果，继续展开新的工作。
学习
前面FLAG里提到过，2019年学习了GO语言，并正在学习机器学习。 参加气象基础知识培训班很有用，今年也应该找找自己能参加什么样的培训。
编程 v2019
2019年的代码提交数由显著的增长，但即便我已经非常在意刷GitHub提交天数，依然无法坚持一整年的事件。 在5月到7月份、10月中下旬都有连续的空闲天数。想要坚持一件事情，需要付出难以想象的努力。
2020年要继续加油，在保证数量的同时，要更加关注代码的质量。 另外，个人业余时间做的项目要更加用心，很多半途而废的项目是不是考虑下重新捡起来。 很多时候，工作项目并不能算作个人成绩。
perillaroc@github v2019
未来
花了好几天写这篇文章，说了那么多工作上的事情，但今年最重要的就是陪女儿一块成长。
你好，2020年。
