N年前我刚加入一家公司几个月，有一个客户购买了我们的产品上线后金额对不上（1类生产事故），于是经理带着我们几个技术去现场看看是什么原因，路上经理说你们不要有什么心理压力，我不懂技术但是我过去就是帮助你们挨骂的，我好好跪在客户那你们好好安心解决问题。

问题大概就是客户代码在一段事务中，但是提交到后端我们的服务上后前对不上了，客户认为我们产品事务有问题。

到了现场客户不让下载他们代码，只能人肉趴在他们指定的机器上用眼睛看问题在哪里，看了三天大家非常沮丧地回来了，自然产品被下线，客户直接用MySQL了，但是三天后一个振奋人心的消息传过来了：金额还是对不上 ……

于是我们再度派出技术人员帮他们看为什么（这次客户配合度高了很多），最后有个同事提了一嘴tcpdump抓个包看看，到底应用代码有没有set autocommit=0, 半个小时后传来喜讯用户代码发出的就是autocommit=1,说明用户代码的事务配置没生效。

最后查出来配置文件中有中文注释，而生产环境机器不支持中文出现了乱码，导致事务没有生效！

事情还没完，当我听到这个结果后恨不得实际抽自己，tcpdump咱也会用，怎么当时就没想到呢！于是后来我天天看tcpdump、分析网络包，有段时间最开心的是在酒店看书了。一个月后写了几篇文章放在公司内网，再然后公司内部各个团队开始拿着各种问题找过来，我的case也越来越多，然后我把这些命令和技巧都整理到了我的博客，不过你们也不会有好习惯去看 https://t.co/ZEB3sWDsTG 随缘吧

有一次产品调用是这样的 1->2->3->4->5->6 产品5是我们的，1说性能上不去，rt太大，扯了两天皮，然后说5有问题，于是我到5上抓了个包，明确告诉他们5的rt是多少，压力还没有到5这里来，另外按照我抓包结果的rt分析，5的能力是20万，现在还不到1万，瓶颈在1-5之间，后来我上1/2/3/4用 netstat 分别看下网络状态发现1-2之间网络到了瓶颈（2回包给1的时候大量的包no ack）,不要怀疑netstat真有这么强大，只是你不会看而已。如图 2上的9108服务端口给1发回结果的时候1那边迟迟不给ack。其实这个case用好工具只是很小的一点，关键的是我能抓包分析出rt，然后从rt推断出系统的能力（别说全链路监控之类的，有时候还得拼刺刀），进而快速定位到瓶颈

现在我们的产品文档必备一份tcpdump、tshark（wireshark命令行版本）救急命令箱，有时候让客户复制粘贴执行后给我们某个结果，好多问题不再是问题了

点击图片查看原图