这是三年前伦敦一个技术大会上的一场非常独特的分享，没想到一场技术大会上能有这么幽默的另类架构师，作者以反讽的形式举出了 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
Go 项目做的比较大(主要说代码多，参与人多)之后，可能会遇到类似下面这样的问题：
* 程序老是半夜崩，崩了以后就重启了，我也醒不来，现场早就丢了，不知道怎么定位
* 这压测开压之后，随机出问题，可能两小时，也可能五小时以后才出问题，这我蹲点蹲出痔疮都不一定能等到崩溃的那个时间点啊
* 有些级联失败，最后留下现场并不能帮助我们准确地判断问题的根因，我们需要出问题时第一时间的现场
Go 内置的 pprof 虽然是问题定位的神器，但是没有办法让你恰好在出问题的那个时间点，把相应的现场保存下来进行分析。特别是一些随机出现的内存泄露、CPU
抖动，等你发现有泄露的时候，可能程序已经 OOM 被 kill
填坑。。
https://github.com/cch123/golang-notes/blob/master/context.md
ascii 图太多，blog 上没法看。就这样
