2021 年终总结

上次写年终总结已经是 3 年前（2019 年）了，2020 年因为实在没什么好写的就没写，这次总结更像是工作 5 年（实际 4.5 年）的总结。我的思想在去年发生了非常大的变化，需要记录一下。

工作

这两年工作上最大的变化是我从 20 年 12 月开始当 leader 了，算我在内有 4 个人，我是年龄最大的（1995 年），但只当到了 21 年 7 月我就主动退出了，一是因为我 leader 当的不好，为了对其他人的职业发展负责，我需要退出；二是我确实还没到当 leader 的阶段，工作没几年、代码还没写明白就当 leader 去了，技术能力不够，软实力也不够，即使只有 4 个人我当的也特别辛苦，几乎没有成长。

这两年工作上做的事情值得一说也就 async-commit 和 hackathon 项目了，其他没有特别有意思的，hackathon 会在后面单独说一下。

工作另一个逃不过的话题就是职业发展了，看起来我现在和某些厂校招后端 SSP 差不多的水平，也是我大学室友一半的水平，不过他是今年博士毕业搞深度学习的，不算是 apples-to-apples 的比较。如果是前几年的我心理可能还会有些不忿，但现在的我不会了，我“躺平”了。

可持续发展

“躺平”这个词最近特别火，我也“躺平”了，但我更喜欢称它为“可持续发展”。即使我现在还算年轻且只有一个人都感觉时间不够用，很难想像其他成家的同事时间会有多么窘迫。人生既长又短暂，长的是会工作几十年，没必要在现在这个阶段为工作倾尽所有，总是追求局部最优解容易过拟合，慢一点没什么不好；短的是过一年长一岁，有些事情只有在这个年龄才适合做，过了这个村就没这个店了，而且说不定哪天就挂掉了，更不能全投到工作上了，所以我“躺平”了。“躺平”带了的另一个变化就是脾气变“差”了，因为无欲则刚，过去我不会对看着不爽的事情发声，现在不同了，该喷就喷。

招聘

过去一年我也参与了不少候选人的面试，面试非常非常重要，但对面试官的培训几乎没有，只能靠自己摸索，发现了很多问题：

• 我很难在短短一两小时内正确的评价一个人的水平。不管是从我当面试官考察候选人的角度，还是假如说我是候选人想要展示自己的角度，如何做高质量的面试我还处于探索的过程中。
• 面试是双向的，太多的面试只是单项选择了。
  • 从招聘的角度看，面试是在选择今后一起工作的队友，如果可以的话，我非常希望能让组内所有人都参与面试，不是说每个人都面一次，可以每面有多个人参与，因为进来是和所有人合作的，需要所有人达成共识想要和这个人一起工作。
  • 从候选人的角度看，面试官代表着公司，如果他的水平不够或不专业，优秀的候选人很可能不会来。候选人一方也需要对面试官进行面试，从他的问题、回答看出他的水平，考虑你以后想不想和他一起工作，需要准备好的问题来确认工作内容、组的成员。如果可以的话，我作为候选人会希望能够和所有人都交流一下，因为我以后会和他们一起工作，我愿不愿意也非常重要。

招聘有个前提，要搞清楚为什么要招人而不是为了招人而招人，这很可能得不偿失。当资源有限时更有可能做更正确的事情，而且招人的 bar 一定要高，宁缺毋滥。

尊重专业

专业的事要由专业的人来做。我当 leader 就是个反面例子，而且没有任何考察和培训我就上去了。另外一个例子就是不要外行指导内行，尤其是空降之前搞其他领域的 leader 或者让某个领域资深的人去做另一个领域资深的人才能做的事情，不要以为高 P 或者在一个领域成功的人到了另一个领域一样能轻松成功。如果要招 leader 强烈建议让所有组员参与面试，因为他/她将会影响整个组的发展。

Hackathon

今年是我第一次参加 hackathon，过去对这个比赛不怎么感兴趣，因为只有两天时间我做不出什么有意思的东西，但这次时间跨度很久（但我觉得这不好，只给两天时间做东西会有意思得多，因为创意第一而不是工作量），就想要验证下我在组内分享的想法，所以拉上 sticnarf 一起搞了。从结果来看，受了点打击，让我“看淡一切”的心再次起了波澜。

这次 hackathon 我们有些可以做得更好的地方，一是开工太晚，快要截止报名了才决定要搞；二是没想到 io_uring 有那么多的坑，我们在 io_uring、内核和文件系统的问题上折腾了好久；三是我答辩没做好，本以为我会在晚饭后才答辩，所以下午也一直在调性能，结果没准备好就上去了。但这次 hackathon 收获也不小，知道了绝对不要在 hackathon 上搞这种类型的东西（帅鹏决赛日上午还对我说搞这个东西评委看不懂阿，艹，我再也不参加 hackathon 了），也对 TiKV 和云盘有了更深刻的理解。我一直以为我很了解 TiKV 了，平时的性能诊断/调优也手到擒来，但这次发现了未知的性能瓶颈，我们花了两天也没有找到。这其实也暴露出一个问题，我们在 hackathon 上做的各种 benchmark 其实是我在 2020 年就想要做的，但一直没时间和资源去做，如果那时候就有条件让我做类似的、充满不确定性的事情，说不定 TiKV 的性能会更好。

Bottom-Up Design

这次 hackathon 点子的核心思想就是 bottom-up design，也就是从各种资源最佳的使用方式出发对 TiKV 做些改造，但在做得过程中我们却没有很好地遵守这一点，而是做着做着才发现云盘有着非常特殊的性质、有些内核和文件系统有着特殊的限制，如果可以重新来过的话，应该会做得更好。

我现在看不太懂 TiKV，每一层互相影响，优化它的性能也太难了。假如让我扬了 TiKV，重新做一个分布式存储，我肯定会 bottom-up 来做。首先纯异步肯定毫无疑问（但竟然发现好多人更关注 parallel log，实际上 thread-per-core 的线程模型才是精髓），然后是搞清楚目标环境盘的最佳使用方式做一个能充分利用 disk 资源的 raft log 引擎，然后找到能充分利用这个引擎的 raft store 模型和状态机，最后再往上堆事务层或者事务直接做到状态机里、网络层等。每增加一层都需要保证能充分利用某个资源，不管是 CPU 还是 disk，每当这一层的资源能够用满后，还需要优化资源的利用效率，比如优化 batch 能力把 IOPS 瓶颈转变为 throughput 瓶颈、降低写放大和一些后台整理操作的开销等。

不只技术上要 bottom-up，做其他事情也要 bottom-up。决定要做某些运动（比如写单测）、制定政策或者确定产品形态，需要 top-down design，而且越 top 越好，不需要想清楚具体怎么做，只要充分想清楚要做成什么样以及为什么要做这个就好，但如何实施需要 bottom-up 的来，换句话说就是，“从群众中来到群众中去”。因为制定目标的人和实施的人不同，两者接收的信息和看事情的角度也不同，如果由制定目标的人来决定如何实施，很有可能走到实施的人已经踩过的坑里，而从实施的人角度看，他们已经踩过了很多坑，更有可能做出正确的方案，而且由自己参与决定如何做会更有 owner 意识。top-down 和 bottom-up 衔接的桥梁就是沟通，而且是双向沟通。

Best Practice

我对 infra 这一领域的感受是，没有理论创新只有最佳实践，这也导致想要成为 infra 领域资深的工程师需要时间和经验的积累，没办法“顿悟”。资深的工程师就是踩过各种坑、清楚各种最佳实践，而做一个产品就是把各种最佳实践拼在一起成为你想要的样子。

“没有理论创新只有最佳实践”的另一层意思是，你要做的事情或多或少肯定有其他人已经做过了，所以做 infra 非常重要的事情就是竞品分析或者学习其他先进的产品，看它们如何做、为什么这么做、踩过哪些坑，最好也能了解它们方案的演进路线，因为了解历史才能更好的创造未来。明白了这点我的心态也好了很多，因为总有“作业”可抄。我去年在技术上最大的收获是学习了 seastar，在我看来这是世界上最牛逼的一波存储工程师做出来的产品，技术领先我们十年，我们在 hackathon 上做的事情只是对它拙劣的模仿。

最佳实践是在不断变化的，发现最佳实践、判断是否属于最佳实践同样需要遵守 bottom-up design，举例来说，LSM-tree 或者说 RocksDB 现在还是好的选择么？NVMe SSD 的随机写性能不输于顺序写，甚至还有 4KiB atomic write 的能力，基于它的特点能设计出更好的存储引擎，这也是我给 KVell 8☆ 的原因，非常好地遵循了 bottom-up design。

通过学习优秀开源产品的最佳实践和遵守 bottom-up design 的原则，即使现在的我也能很快看出来一个方案或产品是否靠谱。

做正确的事

我感觉数据库或者存储这个领域不太适合新人，因为只要做到产品里的东西就是债务，新人（也包括我，我也是新人）很容易做出非最佳实践的设计和实现，把产品的技术负债累得越来越高，导致产品越来越难维护、开发效率和天花板越来越低，最终腐朽，除非有非常资深且对产品有着强烈责任心的人来把握架构、接口和实现，比如 ScyllaDB CTO Avi Kivity。好的产品需要有一个灵魂人物来把握产品的主航道，他/她需要有很强的原则，对产品有着强烈的观点，不轻易动摇，不为某个用户做伤害产品的事情，对错误的事情说不，不能妥协，坚持做正确的事。通过他/她来辐射其他人，其他人再辐射到更多的人来保障产品的可持续发展。

当能力有限时为了做正确的事一定要想清楚几个问题，“为什么要做这个”/“我自己设计方案的话会怎么做”/“我还应该做什么”，不管是别人让你做的还是你自己要做的。code review 也是同样的道理，“如果我来写这个功能我会怎么做”，review 和自己写的代价几乎没有区别，虽然这会非常耗时间但能显著提升产品和代码质量。

苦难本身没有任何意义，苦难就是苦难。难的事情不代表它本身需要那么难，更可能是基础、方向错了，基础要打牢，要在正确的方向、框架上做，而不是在不正确的框架上补，什么都想做很可能什么都做不好，壮士断腕的魄力和决心不是每个人都有的。

一点感慨

生存实在是太难了，非常尊重和敬佩努力生活的人。