从招聘信息中寻找自身差距

背景

今天看到同事在朋友圈中转发某气象行业公司的招聘信息。 我在几年前稍微关注过这家公司招聘的岗位，所以就看了下这篇公众号文章。 发现其中一个岗位的职责几乎等同于我现在所负责的工作，令我感到很意外。

在我的认知中，数值天气预报模式业务系统运维是极其小众的岗位。 除非和我们单位一样需要实时运行大量的业务系统，否则不会设立单独的岗位负责在应用层面上的维护。 记得最后一次持续关注招聘信息是在两年前，当时还没有找到完全对应上的职位。 所以我看的岗位大体上都和 C++/Qt 或者 Python 相关。 没想到现在都能看到涵盖在本部门职责中的招聘岗位，可能最近一段时间气象领域公司的业务扩展比较快，都需要专职人员来负责数值模式系统的开发和维护。

虽然我认为部门在数值预报业务系统运维领域处于国内领先水平（谜一样的自信，刚被与 NCEP NCO 做对比并惨败），但招聘信息往往能给出业界对该岗位的期待，非常适合用来对比并寻找自身的差距。

下面就简要对比下岗位职责和任职资格，引用部分来自招聘信息。

岗位职责

1.熟悉公司后台模式预报任务及各环节流程；

基本要求，只有熟悉业务才能进行业务开发。 不过，单位的业务由部门的多人开发，并与多个部门关联，环节较多。 可能我只对自己负责建设的业务系统比较熟悉，而对其他同事负责的系统不够了解。

最近的部门讨论已确定后续加强对业务系统的内部培训，让大家对各个系统都有所了解。 我觉得这是一个很好的开始，加强分享有助于增进了解，新想法往往就诞生于思想碰撞中。

2.协助项目经理完成项目实施的各个环节，包括：

• 搭建新项目的大气模式业务化预报任务
• 解决项目预报任务过程中所遇的技术问题
• 维护Linux后台大气模式运行脚本
• 模式业务运行系统的搭建和维护
• 气象数据的管理

我对该公司不够了解，从“项目经理”和“项目实施”看，很可能是以工程项目的形式为第三方搭建业务系统。 职责整理下可以分成两个部分：模式业务系统搭建和维护；数据管理。均在部门的职责范围内。

不过，第二项 “解决。。。技术问题” 如果涉及到数值模式系统本身的技术问题，就远远超出我目前的工作范围。 在业务系统建设方面，我目前承担类似胶水的角色，负责搭建业务流程，将其他同事开发的程序整合到一起，而不负责开发实际的程序。 当然，这也意味着我所从事的工作不属于单位的核心任务，很难在单位的拼图中成为不可或缺的一块，更缺乏获得广泛共识的成果。 就连信息中心的高性能计算室都在持续研究并行计算技术，所以我更应该仔细思考下在现有框架下自己的定位，拿出有影响力的工作业绩。

3.负责在项目营运过程中监控预报任务，发现因数据下载延迟及其它突发性故障时能及时处理；

业务运行监控是我们部门最重要的工作职责。 数据下载延迟是业务系统故障的重要来源之一，另外还有诸如数据分发异常、高性能计算机异常等等。 部门在这方面积累了足够丰富的经验，能够在复杂的环境中保障业务系统稳定运行。

4.从模式输出数据中读取整理客户需求数据。

如果仅仅需要对数据进行诸如要素抽取、区域裁剪等简单操作，那么用现有的开源命令行工具（如 wgrib2）就可以很容易实现。 但是想要根据用户的需求在模式输出要素的基础上生成新的产品，就涉及到模式后处理。

模式后处理是一项专业性很强的任务，在单位中由单独的部门负责，另外也有专门的团队从事数值预报模式数据释用方面的研究。 对于像我这样的业务系统运维人员来说，从数据处理方面切入到模式系统核心体系是最可能有效的途径。 毕竟数据处理涉及的专业领域知识远远小于模式系统本身。 实际上，最近关于某产品时效性的讨论中，领导提到我们部门应该着手开发并行转码程序。 虽然因为种种原因目前尚未开展，但至少说明在数据处理方面，我们部门有进一步发展的机会。

另外，数据处理，乃至延伸的模式后处理是提供产品服务的关键技术。 在气象局范围内，就有多个单位的多个团队在对模式输出产品进行再加工。 即将组建的气象大数据中心更能体现数据在气象领域的重要性。 之前我过于担心在数据方面投入太多会导致未知的冲突。 不过在无法明确未来改革方向的情况下，进行数据处理方面的研究总会有所帮助。 不能将自己限制在某个固定的范围内，但也要处理好涉猎太广而带来的不专精的问题。

大数据时代，数据才是最有价值的资源，掌握围绕数据的各项技术才能具备核心竞争力。

任职资格

1、大气科学、物理学、计算机或自动化相关专业，硕士及以上学历；

这一点与职位要求有所冲突。职位要求有 5-10 年工作经验，博士及以上学历。 这是很高的标准，至少在我们单位从事数值预报业务系统维护的同事中，没有人符合这项要求。

可能需要去读个在职博士🤣

2、掌握中尺度大气数值模拟的相关知识，长期从事数值天气预报系统维护与优化工作；

我们部门除了去年刚入职的新同事，至少都有 5 年以上的数值预报业务系统运维经验。

但其实我自己对模式系统本身的了解还远远不够，对气象相关知识也了解不多。 虽然最近两年我尽可能找时间去参加中心组织的新员工培训，但因为工作任务原因错过几个重要的课程。 我应该在平时也加强对专业领域知识的学习，而不能仅仅对 IT 相关领域知识感兴趣。

3、熟悉 Linux 系统的安装和调试，能够独立排除各种软件故障；

单位不负责维护 HPC 的硬件和软件环境，只使用 HPC 上由管理员安装的应用软件。 所以我还欠缺系统级维护的经验。 虽然安装过一两台 Linux 工作站，但仅仅用于日常开发，不作为承担业务系统的平台。

在可以预见的未来，部门依然不会负责基础设施的维护，所以我更倾向于在业务系统中使用容器技术，将应用系统和实际的硬件环境隔离。 当前的 HPC 尚不支持这种方式，期望明年投入应用的下一代 HPC 能向我们开放类似功能。

4、具有良好编程能力，尤其是 Fortran 和在 Linux 环境下的 shell script 编程；

单位的业务系统流程全部使用 Shell 脚本编程。 不过在入职以来，我一直没有学习 Fortran 语言，而且未来在没有明确需求的情况下也不打算学习。 尽管 Fortran 是单位当仁不让的编程语言一哥，我还是认为没有必要将精力投入到受众面比较小的语言中。 从目前趋势看，C++ 也逐渐进入数值预报模式领域，还不如多写写 C++ 程序。

不过编程语言不应该成为程序员的瓶颈，快速学习一门新语言是必备的能力。

5、熟悉 Python 语言，熟练掌握一种 Python web 开发框架（Tornado 、Django、Flask 或其他框架）, 理解 HTTP 协议；

现在的 Python 正如十年前的 Java，总能看到各种培训广告。 今年明显感觉到单位使用 Python 的同事越来越多。 我也一直在使用 Python 开发运维工具，包括已经在业务系统中应用的监控平台等。 可惜我仅仅简单使用过 Flask 框架，对 Django 和 Tornado 完全不了解。 后续应该花点儿时间用一用其他的 Python 框架。

6、熟悉地理信息技术者优先；

我还没有系统学习过地理信息系统的相关知识，GIS 技术是数据可视化等任务的核心，后续应该加强这方面的学习。

7、熟悉 MySQL 数据库的应用；

只要和数据打交道，就离不开数据库。 但我使用的 MySQL 数据库中数据量很多小，没有数据库优化的经验。 后续应该学习下在保存大量数据时，如何优化数据库的性能。

8、具有 WRF，MM5 等气象模式实施经验者优先；

当我们将自身的能力与某个仅在本单位使用的技术绑定，就会埋下隐患。 如果有一天因为某种原因无法在本单位工作，积累一身的技术很可能就失去用武之地，面对市场上激烈的竞争就会显得无能为力。 所以，我极力推荐使用开源项目搭建业务系统相关组件，并将工作中独立完成的绝大部分项目进行开源，未开源的工作主要涉及业务系统的等级保护等原因。

而且，我觉得部门的工作完全适合任何数值预报模式系统，甚至其他几个部门的工作也类似。 如果将工作仅局限在单位自有的模式系统中，就失去了将工作成果进行推广的机会。 只有用的人多了，才会各种需求，才会有持续前进的动力。

年初本来计划今年尝试运行下 WRF 模式，可直到现在也没有动手。下半年应该努力了。

9、为人正直，心态积极，具有良好的沟通能力和学习能力；表达清晰，有良好的技术讲解能力；吃苦耐劳、团队协作意识强。

通用模板，基本要求。

感想

对比下来发现，自己在很多地方还有待提高。 当内部动力不够的时候，就要从外部寻找激励。 所以，没事看看招聘信息还是很有必要的。

参考

招聘信息原文就不放了，网上一搜就有。