记一次差点翻车的上线经历——论团队内外精准协调的重要性

原本轻车熟路的上线，第二次整到了深夜十二点才搞完，花费的时间是上次顺利上线测试的两倍。虽说测试的例程比上次多了一倍，但依旧不构成主要原因。这次上线中，碰到了一些之前未遇到的问题，如团队内外协作、业务掌握情况、CICD自动化等等。和以往一样，文字结合思考，自省改进，让自己更加清醒。

总体来看，在此通过Jenkins/RLM BMC上线的关键因素有以下两个

1. CICD流程：涉及线上，需要五个以上团队的审批，申请流程以及相关处理脚本经过近半年的打磨已趋近成熟，这一关几乎没有问题。
2. Manual Post Validation：通过专门Support Team登录到生产环境服务器，进行系列手工验证操作，主要为数据处理程序的驱动及结果验证；是上线当日变数最大、花费时间最多的地方。

主要问题概述如下：

1. 本次系临时上线，没有提前约好Support Team具体时间、具体支持者。当天下午五点半，远在国外的Support Guy才到位。
2. 自己作为一个架构支持，却对具体业务的理解不到位，进而对数据验证没有清晰的目标航向，准备的还是不够。
3. Autosys因为不适当的配置于上周六On Ice了，大量的数据积压导致了数据ETL的缓慢，或许也是文末所述的问题的导火索。
4. 最后也是最重要的一点，Manual 操作太多，应该和CICD Validation一样撰写好例程启动和具体验证脚本。经过严格测试理论上可避免上线时的手工操作，减少资源损耗。嗯，下次上线必须要整出来的东西！

解决方案

1. 充分发挥主观能动性，提前和领导们沟通好具体的Support Team细节，预防出现资源紧张时找不到人的情况。即使在领导们协商一致的情况下，因为自己没有进一步确认好具体支持者。而上线这天，团队要向上一级领导Demo项目、Support Team需要全力支持另一个更加重要的项目上线。中午开始联系Support Team成员时居然找了五个人都处于Busy状态，最后还是由双方老大出面才确认了具体支持者。远程跨团队合作就是这么困难，不具体到人，邮件写的再确定也是模糊的。
2. 团队里，不仅仅要关注自己要做什么，也要关注别人在做什么。要不然在关键场景中，其他人不在的时候，就两眼抓黑了。
3. 以后在上线前一天停止Autosys作业以防止资源竞争及缓存配置过期问题（https://blog.csdn.net/qq_34901049/article/details/113446410），保证上线当日的项目按预定的例程测试进行，生产环境测试通过的情况下再次开启。
4. 进一步完善上线自动化脚本工具，消除不必要的Manual Process。要知道，手工操作意味着出错概率的大大增加。

一个特殊的问题
本地ETL程序跑着跑着出现了主进程持有配置数据丢失的假象，怀疑是因为主进程持有的配置数据在异常紧张的资源环境下，进行内外存置换的过程中丢失了。
但这种错误概率有多大呢？不过值得怀疑的是，最后一个正常处理的日志数据A约为5GB、4千万行级别，实际处理时间大概十分钟。在串行处理的情况下，A的处理完毕提示邮件距上一个日志文件处理相差了半个小时。这中间消失的20分钟去哪里了？为什么之后的日志数据就没有继续处理了？为什么在重启进程之后依旧出现了进程未持有配置数据的假象？
上述场景就像是，一个程序跑着跑着，她持有的配置数据就丢失了，关键还没有任何异常报错。这里不像Java一样有OOM、NPE之类的贴心提示。查询全量日志也没发现可疑线索；一点都不怕Bug，怕的是看起来没有任何异常的程序中出现这种隐形Bug，而且还没有任何有效提示。
其实是很怀疑服务器资源问题的。通过top、free、df等系列命令检查之后发现三百多G内存的服务器，可用内存仅有两三个G，但这也不至于让程序持有数据丢失。况且还有两百G的缓存数据可以置换呢！LRU置换下也轮不到把我程序给整了吧？就算是出现了内存置换，那不也还有虚拟内存的存在吗！当然，大胆假设，小心求证。另一方面，在提交集群任务时出现了BlockManager的内存溢出警告。
总之，因为在生产环境，无法做场景复现，以上种种推测也没有确凿的指向问题症结所在。接下来就看下周一Autosys启动后，进一步观察线上情况了。

后记：上述特殊问题系程序Bug