我的 Rust binary search PR 导致 Polkadot 线上事故的缘由
知名公链波卡 (Polkadot) 5 月 24 号某个节点发生了一次比较大的线上事故(Out Of Memory),做梦也没想到是因为我上次优化 Rust 标准库 binary search 导致的。
我上次的 PR 跑了将近一周时间的 crater 测试,也没有发现对线上 5 万多个 crate 有什么大影响。Rust 1.52 发布之后,没想到依然有人中招了,而且还是价值几十亿美金的项目。
@brson 特意发了 issue 说到这件事,但是 Rust 社区的人都认为这件事跟我这个 PR 没有关系,因为 binary search 碰到多个重复的元素的时候确实是返回任意一个,文档上也说得很清楚了(所以这种情况下不会保证两个版本返回的位置一致,这也是 Polkadot 出现线上事故的原因)。不管怎样,这件事给我的触动还是蛮大的。软件开发是复杂的,其本质原因在于现实生活就是复杂的。软件工程师只能尽可能规避发生这种情况的风险,但是没有办法做到万无一失吧。就像这位工程师说的我这是中了 Hyrum 定律(Google 一个叫 Hyrum 的工程师提的定律,可以理解为 API 领域的墨菲定律)。
-
Polkadot 的事故后复盘:https://polkadot.network/a-polkadot-postmortem-24-05-2021/
-
@brson 的 issue: https://github.com/rust-lang/rust/issues/85773
-
关于 PR 的文章:https://zhuanlan.zhihu.com/p/371460665
-
Hyrum 定律:https://www.hyrumslaw.com/
-- From 日报小组 Folyd
社区学习交流平台订阅:
评论区
写评论Rust社区还是激进啊(不含贬义 Java那边发生过一次类似的事情,不过讨论结果是不修复,bug变特性了,就没合并进去,就下面那个事 https://zhuanlan.zhihu.com/p/81363965 这样倒是不会break了,但是相当于JDK本身扛了文档外的雷,总归是个隐患