去年10月17日公司出了个事故，“幸好有我“，力挽狂澜。我觉得还是把具体内容脱敏，记录一下吧，免得将来忘了。
早晨test环境某个自研产品组件build成功，但是运行时错误日志里一堆“Broker hostname updated”等等，仿佛孔乙己说的话，让人听不懂。我刚开始没把这个当回事，请Kafka管理员去检查，几个小时都没查出原因来。
到了午后，各自研组件纷纷开始更新Live环境的版本，发布的都是前几天在Test环境已经测试定稿的版本，居然也出现了类似的问题。更狠的是，回滚居然也无效！
最终查实，有不少自研产品的build脚本里，使用wget下载master版本的librdkafka然后编译使用。而librdkafka恰在前一天（10月16日）被提交了很多修改。当时紧急解决的方法是使用librdkafka的上一个被明确标记了tag的v1.2.1版本代替master版本。
事后复盘处理过程，觉得当时的处理过程也有问题：所谓回滚其实并非直接使用旧版本编译出来的docker image，而是重新build了旧版本，而且编译时指定的是branch名字，而不是精确的commit id，这样的问题是无论外部代码（master版本的librdkafka）还是自研代码（注意branch有可能move forward哦），都不一定是原来的版本，这个行为其实并不能称作回滚，而是带有主观回滚意向的一次重新构建。
在这种情况下，讨论自研代码和外部库的质量，都是缺乏讨论基础的。这种讨论应该基于确定的版本。
说实话，我以前对于传说中的“Google把自研代码、外部库和工具链”全都纳入版本化管理，是有点嗤之以鼻的。当时我觉得这种做法，在处理多个自研软件的外部依赖相互冲突时，会带来额外的行政成本，在国内企业的KPI风格下，会导致相互推诿。经过这次力挽狂澜之后，觉得相互推诿其实是KPI至上主义导致的，而不是把所有代码都管起来导致的；不过是否真的要管这么大范围，尚有待商榷。