本文内容是 2013 年 Google 对 packetdrill 的论文翻译。 网络协议测试很麻烦，线上的网络问题往往都是偶发的，难以捕捉。 packetdrill 是一个跨平台的脚本工具，可以用来测试整个 TCP/UDP/IP 网络栈实现的正确性和性能，从系统调用一直到硬件网络接口，从 IPv4 到 IPv6。 该工具对 Google 工程师研发 Linux TCP 中的 Early Retransmit，Fast Open，Loss

之前在这篇 无人值守(一) [http://xargin.com/autodumper-for-go/] 简单介绍了我们针对线上抖动问题定位的工具的设计思路，思路很简单，技术含量很低，是个人都可以想得到，但是它确实帮我们查到了很多很难定位的问题。 在本篇里，我们重点讲一讲这个工具在生产环境帮我们发现了哪些问题。 OOM 类问题 RPC decode 未做防御性编程，导致 OOM 应用侧的编解码可能是非官方实现(如 node 之类的无官方 SDK 的项目)，在一些私有协议 decode 工程中会读诸如 list len 之类的字段，

这是三年前伦敦一个技术大会上的一场非常独特的分享，没想到一场技术大会上能有这么幽默的另类架构师，作者以反讽的形式举出了 10 个微服务环境下对系统搞破坏的 tips。我看了很多遍，其中的案例其实日常研发中大部分也都遇到过了，之前也总结过各式各样的吐槽，比如之前写的《中台的末路》《微服务的灾难》《MQ 正在变成臭水沟》等等。希望日后自己也能做类似风格的演讲。 下面是演讲的内容： 开场白，先是免责声明，让人对号入座就不好了： 然后是听众收益： 老板想要搞事情，让公司系统更现代化，你不想这么干，得找点理由反驳他；或者你想破坏你们现在的系统；学习从实践中总结的血淋淋教训；具体案例做过了匿名化处理，让罪犯可以稍微心安理得一些。 老板从网上学到了新词汇，比如工业4.0(哪个营销号说德国人不讲工业4.

在 Go 的 runtime 里有一些创建了就没法回收的东西。 之前在 这篇 [http://xargin.com/cpu-idle-cannot-recover-after-peak-load/] 里讲过 allgs 没法回收的问题。 除了 allgs 之外，当前 Go 创建的线程也是没法退出的，比如这个来自 xiaorui.cc 的例子，我简单做了个修改，能从网页看到线程： package main /* #include #include #include void output(

TLDR; 使用 https://github.com/cch123/supermonkey 可以 patch 任意导出/非导出函数。 Update: 目前在 Linux 直接运行 go test 生成的二进制文件没有符号表，所以如果在 test 中使用需要先用 go test -c 生成带符号表的二进制文件，然后再运行，略麻烦。 目前在 Go 语言里写测试还是比较麻烦的。 除了传统的 test double