近来技术同事遇到一个线上问题，客户突然反馈数据通过我们的服务器上传总是出现超时的情况，而数据超时是会影响他们挣钱的，所以技术同事抓紧排查处理，但查来查去却并没有查出具体的原因，为此经过请示后，他们重启了服务器，其实我还协调了研发同事配合排查，在我的印象中，该系统出现数据延迟并非孤例！不成想，设备重启后客户反馈大部分数据上传恢复正常，只有个别显示无数据或延迟，并说这种情况不一定和我们的设备有关系，所以研发介入也没起到什么实质性的作用。
技术同事肯定大大的松了一口气，我想；然而，设备接下来接二连三的宕机他们肯定没有预料到，具体情况是这样的：
- 21号早上客户发现数据上传失败，技术同事定位当时重启的设备不通直接协调客户重启设备恢复上传，具体原因我觉得他们没有深入排查，当天也未有相关反馈。
- 22号早上客户再次发现数据上传失败，一位资深的技术同事提起了警惕，协调客户现场接显示器查看宕机设备，发现没有任何输出画面，遂直接硬重启设备，重启后业务恢复；这次故障发生了一插曲，据现场反馈，设备第一次重启数据恢复上传后很快上传再次终止，现场不得以对设备进行了第二次重启，关于设备的再次宕机，这里不排除有其他原因造成吧，比如现场失误等，总之，现在为止该设备已经进行了四次硬重启了。
22号问题再次出现后，我失去了耐心开始入场和技术同事一起沟通、排查问题原因，经过讨论、排查、分析，大家统一怀疑是设备内存耗尽引起系统内核恐慌，最终导致宕机，所以需要对系统的内存占用进行监听并生成日志方便后续分析，为此技术同事在系统中部署了监控了监控系统内存、cpu、socke连接的脚本。
- 果不其然，23号早上再次出现数据上传失败，客户也开始着急，直接打电话给我要求派人去现场，我将自己的分析对客户解释了一番，并承诺很快得出结论，客户接受了我的解释；然后我协调现场人员去机房观察设备，就像中医的望、闻、问、切一样，仔细的分析了一遍宕机的设备才让其重启，然后我从技术同事手里获取到了监控脚本产生的日志，确认了设备宕机是内存耗尽引起的。设备重启后恢复后我和技术同事沟通，让其协调现场将数据上传任务迁移到其他系统，待我分析日志得出最终结论。
经过分析监控脚本的日志，确认了两个问题： a. 数据上传业务连接数很大，并且连接一直不释放； b. 系统业务量巨大，收到数据包时往下一个环节发送时造成了大量的堵包，而这个堵包最终造成了内存耗尽，系统崩溃；
- 23号将数据上传业务迁移走之后，24号该系统未出现宕机的情况，结合昨天的分析基本可以确定问题的原因为宕机系统性能不足或优化不够，当然和数据上传业务不释放连接也存在一定的关系。客户还问能否通过升级内存解决，我告知客户升级内存一定程度上可以延迟宕机的发生，但是堵包的情况不会有太大的缓解，最终可能还会出现延迟的情况。所以最终和客户确定的是，后续一点一点的将业务往回迁，测试系统最终能承受多大的量。
至此，关于该问题的排查总算告一段落。