日常排查问题技巧小结

「焦虑、烦躁解决不了任何问题，只会让问题变得更加难严重」。工作越久，对于工作的厌倦情绪就变的越重。甚至会开始思考是不是应该走哪条看起来鲜花盛开的路。但是这个世界上从来就没有一种叫做「后悔」的药，与其在懊悔的情绪中，反复自我折磨，不如那把在走的路变的鲜花盛开吧。

由于笔者所在的公司，业务大多都是有状态的，为这保证有状态的任务在遇到

仍能尽最大可能为客户提供稳定的服务。公司设计一套完整的恢复系统 --- 即在发生上述故障场景的时候，在不同的机房为客户重新拉起相同的任务。

注：以上迁移并非无损，以「录制」业务为例，上述迁移发生的时候，任务会有 90s 左右的录制内容丢失。

问题：在新版本迭代的过程中，测试小姐姐反馈，任务总是会中途退出？

注：这个问题的原因真的是一个非常机缘巧合的场景导致的，但是真的值得记录一下，以防下次再犯。

思路一：服务是通过 C++ 实现的，若是任务崩溃，应该会留下 dump 的文件，但是神奇的事件是根据测试提供的崩溃记录，笔者并未发现任何 dump 的文件。

验证：排查了多个 case 后，发现均无 dump 或 crash 产生的文件，此思路不对。

注：喜欢写代码、喜欢查问题，大概就是因为喜欢这种大胆怀疑，小心求证的过程

思路二：Linux系统中可以对程序设置资源限制，例如CPU时间、内存使用等。当程序超出了这些限制，操作系统可能会强制终止该程序。

验证：

通过 /var/log/messages 文件查看 kill 记录：
shell 复制代码
```
cat /var/log/messages | grep "killed"
```
通过 /var/log/syslog 文件查看 kill 记录：
shell 复制代码
```
cat /var/log/syslog | grep "killed"
```
通过 dmesg 命令
```
dmesg | grep "kill"
```

综上所查，系统没有强杀过测试的进程

「When you have eliminated the impossibles , whatever remains , however improbable , must be the truth。」

思路三：迁移服务出现 bug，在误拉任务

验证：排查了迁移服务的日志，以及被迁移服务监控的任务，发现是在任务被退出后，迁移服务才启动了拉起的流程，所以迁移服务没有问题。

思路四：部署服务的平台出现了问题，在强杀任务。

验证：与平台侧同事反馈后，他们表示，最近在上新功能，为了防止失联的资源浪费，他们会根据策略识别已发布的服务是否需要回收资源，进而强杀任务。

注：平台是指公司内部的 k8s 平台，强杀任务回收资源，是指他们会根据 pod 启动的空闲程度，强杀 pod 回收资源，进而影响了我们服务的测试进度

(⊙o⊙)...，怎么说的一切都显得很合理，但是一切好像又都不是很合理，所以后面跟平台侧提建议，让他们的测试功能跟业务的测试功能区别开，这样可以规避掉类似的乌龙事件。

要振作起来呀，用知识武装自己，嗯，就加油吧！

什么是弱者和愚蠢的人？

  也就是说，你对他好，他就会把生活所有的不幸都怪到你身上，他却不知道，自己之所以被不公平对待，恰恰是因为她没有能力，自己软弱无能。

当你的希望不再寄托于别人身上的时候，你的力量就会回归于自己自身。你的心就会突然静下来，你能够清晰的看到别人和自己的分界线。你会知道别人帮不了自己，我必须要靠我自己才能够爬出这个泥泞。你的心神一旦达到自己身上，你会发现你越来越美，你越来越有魅力。