关于数值预报业务系统运维的讨论会
多闻阙疑，慎言其余，则寡尤；多见阙殆，慎行其余，则寡悔。言寡尤，行寡悔，禄在其中矣。
–《论语》为政篇
今天下午科里值班同事与领导座谈业务系统值班，讨论很热烈，晚上六点才因时间太晚而结束。
我关注的焦点在于减少在业务系统建设和运维方面的工作量，从而将精力投入到其它更容易产出成果的方面，比如研发支撑等。 而解决问题的关键就是这部分工作能否向第三方转移，无论第三方是单位内部其它科室，还是外部公司。
单位内部因为职责划分等问题，从近一两年的多次尝试来看，没有太大可能让其他科室从事业务系统建设和运维工作。 而聘请外部公司虽然需要承担昂贵的用人成本，也需要考虑经费使用的合理性，但仍是目前最可行的解决方案。 今年已着手尝试，实际效果有待后续进一步观察。
过去的一年，尤其是年底阶段对运维工作的思考，让我逐步意识到，长期从事系统运维工作会带来隐性压力，对工作和生活都会产生负面影响。 我对运维工作的整体态度也从使用技术手段提高系统自动化运维水平，变为通过多种方式减少系统建设和运维任务总量。 单纯通过在目前值班人员中间调整任务分工，而不改变任务总量，可能会降低特定时间段内的工作量，但很难改变运维工作带来的隐性压力。 毕竟蛋糕大小没变，无论用什么方法切分，最后每人分到的都一样多。
大家在讨论中提出了多项建议，有三条建议很值得关注，因为半年前就已经提过一次，而我也对此持保留态度：
- 调整值班排班，改为 1 人 1 天 24 小时，休息 2 天
- 引入定量评价机制，参考预报员评分机制，评价值班效果，并与绩效挂钩
- 为防止意外因素，由系统单人负责制改为多人合作建设
我认为，前两点的调整思路是通过强化责任感调动主观能动性，通过外部约束和激励来促使值班人员保障业务系统运行不出错。 我一贯认为这种通过约束行为人提高运维质量的方式不是可持续的，会给本来就承担巨大压力的运维人员带来更大的制度压力。 而且将数值预报业务系统运维工作与预报员相比较也明显不合理。 预报员队伍更加庞大，几乎每年都有新鲜力量加入，也有健全的独立于职称的评价机制。 将预报员评分思想用于仅有 7 人的值班团队，有点儿大材小用，也与部门其他科室的评价机制差别太大。
第三点源于降低业务系统的维护风险，避免因负责人无法工作而导致业务系统无法变更维护。 实际上虽然单人负责制有各种各样的问题，但任何制度的形成都是有原因的。 就拿我个人来说，目前负责 4 个模式的后处理系统 (GRAPES GFS，GRAPES MESO 10KM，GRAPES MESO 3KM，GRAPES MESO 1KM) 以及 1 个模式的全流程 (GRAPES TYM)。 虽然我负责的系统往往比模式预报系统简单，但我还是要提一个问题：
建设业务系统真的有那么困难吗？
我只是觉得可能我们整天忙于业务和科研，而忽略从工程角度完善业务系统。 比如提供完善的说明文档，可以以最快速度将科研系统转为业务系统； 比如制定统一的系统建设规范，共享模块，所有系统都派生自一套模板； 比如通过中试平台让科研和业务使用同一套系统，减少科研到业务的转化成本。
多人建系统确实能解决一部分现有问题，但解决不了核心矛盾，工作效率也不会有质的飞跃。 另外，想到已经负责这么多系统，还要花时间熟悉并建设额外的系统，那还有时间进行其它工作了么？
所以正如我在之前一篇文章中说的：
科研工作它难道不香么？
很遗憾，再一次在会后发现自己说多了。 没有从之前的讨论中吸取经验教训，忘了参加讨论的第一原则：
沉默是金。
或许我应该在这里多写些想法，这样在实际讨论中就不会多说话了。
千言万语汇成一句话：
服从中心和领导安排，做到指哪打哪
