临近放假前一天，客户现场出问题，研发内部却在互相找毛病。

(资料图片)

大致经过

昨天是公司春节前最后一天上班。一个客户上午一上班就反馈，说服务器崩溃了。于是技术服务、测试、运维、研发轮番上阵，但一直没有找到问题。

项目背景

这个客户之前很早就买了设备并安装调试完成，但因为疫情原因，并没有上线使用。近期临近春节业务增多，系统投入使用前服务器进行了升级，暴露出了这个问题。

排查过程

上午客户刚反馈时，在运维和研发看客户问题的同时，测试就搭建好环境尝试复现客户现场问题，但到下午两边都没有什么进展。服务器和终端研发都认为自己近期改动不会导致这个问题，希望对方去排查，也可能是因为第二天就放假了，不想加班。所以一直没有实质性的进展。

临近下班时，运维发现现场日志中一种不带屏的终端设备，发送mqtt注册有点频繁，于是服务器研发就断定这种终端类设备存在问题，需要终端修改。于是终端类设备研发开始降低注册频率尝试解决该问题。

这种终端设备现场大概有小400台，在没有注册成功的情况下，几乎每秒会注册一次。

虽然这个注册频率是不正常的，但以客户服务器的硬件配置，这么一点并发是绝对不可能出现问题的。

我们有一种嵌入式微服务器，大概可以支持500台以内的这种终端的正常使用。所以，我建议他们继续同步排查服务器是否存在问题，因为时间有限，不能等着注册问题解决，万一还是解决不了现场的问题，到时候就没办法不加班了。

最终结果

于是，服务器研发同步继续排查，最终在晚上9点多终于找到了问题，原来是服务器最近新增的一个功能还没有提测，但打包到了客户定制升级包中。于是研发先远程客户现场这个功能停用，清理相关数据，保证现场可以继续使用。然后安排今天修改和测试，然后发新版本给客户升级。

经验总结

现在总结一下这个项目的问题，年后在公司内做相应的改进。

首先，研发没有做好代码的分支管理。如果做好了分支管理，不至于将非该项目的代码打包进行客户定制版本。我之前在公司有发布git代码分支管理规范，服务器端代码我没有权限，所以将这部分检查权限交给了服务器研发经理，但显然没有安要去执行。下一步找到研发中心负责人，沟通专人检查代码分支管理是否符合规范。

其次，服务器持续集成没有做好。导致合并了相关代码但没有通知到测试。我虽然在公司推进持续集成，但仅限于终端类设备，服务器由于在另外一个城市开发，暂时还没有加入持续集成工具链。年后和运维一起在公司各个研发中心推广并应用持续集成工具链，减少类似低级错误的发生。

然后，测试还不够全面。服务器压力测试和性能测试做的还不够，一方面做好接口的压力测和性能测试；另一方面加大无人测试间的设备量，保证能尽早发现类似问题。

最后，加强服务器日志监测和分析，类似的频繁请求的操作能第一时间发现，并提交研发修改。

#头条创作挑战赛##程序员#

本文文件服务器硬件配置（文件服务器的配置）到此分享完毕，希望对大家有所帮助。