译者序

近读到了分布式系统研究者 Mahesh Balakrishnan 的一篇博客《42 things I learned from building a production database》。同样做基础架构，看完大佬总结的经验后拍案叫绝，其中有几条简直是真知灼见，故翻译了全文。原文应该叫《我从建立生产级数据库中学到的42件事》，但其实适用于各种基础架构，故稍作修改以博眼球。

Mahesh Balakrishnan 是 Facebook Delos 项目的负责人。Delos 对标 ZooKeeper，关于 Delos 更多详细细节其团队已经发了两篇 paper，感兴趣的同学可以自行搜索。

译注：IC = Individual Contributor，即独立贡献者，Facebook 开发团队的一个术语，指那些不是经理、不是 team leader、不是任何领导职位的编码人员，可以理解为一线开发人员。

以下为正文：

对客户（用户）

（1）让你的客户开心；否则这篇文章的其余部分都无关紧要。

（2）要注意拥有正确数量的客户（刚开始时，就一个）和合适的客户（他允许你构建关键技术）；并小心地增加这个数字。

（3）直接与客户对接。很多团队内部冲突可以通过一句“我刚才和客户谈过，他们说......”来解决。在做基础架构时，我们往往不需要猜测客户的需求，我们可以直接问他们。

（4）但要意识到客户可能无法表达他们真正需要的东西；不要只看到需求的表面价值，而要花时间详细地理解他们的用例。阅读他们的代码。

项目管理

（5）要有一个简单明了的使命宣言来表达你存在的理由。Delos 的宣言是：我们将成为 FB infra 的可靠基础。

（6）反复进行任务难度的评估；决策者可能没有时间、倾向、上下文或培训来进行评估，而且可能会把它们弄错（简直是）几个数量级。

（7）对 IC 的任务分配很关键; 要求自己处于任何决策的关键路径上，因为你通常比经理更了解问题、代码库和 IC 们的优势。如果你和其他 IC 自己解决任务分配问题，大多数经理都会很高兴。

（8）Road-map 是一种手段，而不是目的。

（9）如果你有好的和/或一致的经理，要尽可能地理解、支持和包容。如果你没有这样的经理人......好吧，我还没有想明白这个问题，如果你想明白了，请告诉我。

（10）使你的项目对组织架构调整有足够的鲁棒性，一个公司的管理层级本质上是脆弱的（毕竟，树是一个单连接的图）；不断地与未来可能接手这个项目的经理进行交流。不惜一切代价，确保经理人的变动不会给 IC 们带来不公平的职业结果。

通常来说，公司组织架构调整是非常频繁的，经常一年就会调整一次，确保经理人的变动不会带来不公平的职业结果，这点其实很难（我也很想知道怎么做到）。

（11）追踪类似的功能在你所在领域的其他项目中花费了多长时间，并以此作为任务难度评估的依据(例如，“功能 X 在系统 Y 中花了 3 年时间；这不是一个 IC 的一半工作”）。

设计

（12）对 API 要保守，对实现要宽松(Be conservative on APIs and liberal with implementations)。

（13）但要坚持谨慎地推出新的实现（灰度、分阶段推出）。

（14）设计 API 时，写代码完成个实现(implementation)；积极计划第二个实现；并希望/祈祷事情将在第三个实现中发挥作用。（When designing APIs, write code for one implementation; plan actively for the second implementation; and hope/pray that things will work for a third implementation.）

（15）设计 API 时，首要考虑向新实现的迁移；自定义迁移会造成巨大的时间消耗且不可靠。每个主要的 API 都应该有一个单一的 CLI 驱动的调用来切换实现。

（16）作为一个团队去设计；作为个人实现(Design as a team; implement as individuals)。这将使设计成为瓶颈，但这是值得的：抵制并行化设计的冲动。

（17）对于存储系统，在开始时就要重点关注一致性和持久性，而不是可用性；一致性和持久性更难衡量，如果出问题也更难修复。由于可用性更容易衡量，所以会有外部压力要求优先考虑它；推到后面去。

（18）在测试中维护 API 的多个实现；比较它们之间的结果。这样做的代价是值得的（这将有助于正确性，也可以防止实现细节的泄露）。

（19）对设计进行后期绑定（Late-bind）：鼓励团队思考整个设计空间，而不是承诺使用某个特定的解决方案。与一群高智商）有主见的 IC 们一起开头脑风暴会议是一门值得掌握的艺术。鼓励在设计的关键路径上进行粗略的原型设计。

（20）对实现者进行后期绑定：一旦设计完成，任何 IC 都应该能够编写代码。

（21）拥有适当数量的抽象（这很难）。太少了，你会得到一个混乱的单体；太多了，团队会被理解每个抽象的语义的认知开销所淹没。

（22）避免使用实时性来保证正确性或在机器间比较时钟，除非你有（并理解）时钟的错误界限。

（23）有一个单一的真理来源。在各种类型的状态之间建立简单的不变量。

（24）创造一种文化，让 IC 不断地思考完全不同的设计；不要停止关于假设性替代设计的对话。鼓励好奇心。

（25）了解你的 SKU。云计算使人们很容易忽视硬件；但对硬件（和硬件趋势）的理解对设计来说至关重要。

Code Review

（26）在一个具有快速评审周期的透明代码库中，除非你把关，否则 API 会泄露实现细节。

（27）鼓励 IC 对 diffs 进行批判性的思考，并创造一个人们可以自由表达的环境。作为 diffs 作者，你对指出 diffs 问题的人的反应应该是感激，而不是沮丧。

（28）对于关键组件，考虑非正式的规则，例如要求两个接受（即两个 LGTM）或甚至是某个子集的 IC 的一致接受。

（29）对于关键组件，落地时间不是衡量其重要性的标准：抵制衡量这一标准和优化它的冲动。创造一种让 IC 可以接受 diffs 不能快速落地的文化（创造性的工作——书籍）论文等等——由于高质量 review 的成本，通常需要漫长的 review 周期；为什么代码应该有所不同？）

（30）有时候，你只有在一个 IC 写出了一个候选的设计方案后才意识到这个设计是正确的。要抵制说“哦，好吧，让我们先落地，然后再修复它”的冲动；你这样做对 IC 和项目都没有帮助。创造一种文化，让 IC 感觉到如果这不是正确的解决方案，就可以丢弃代码（以身作则）。

策略

（31）以某种节奏问自己：为什么这个团队/项目会存在？如果它不存在，会发生什么（哪个其他团队/系统会填补这个空白）？该团队是如何为公司增加价值的，以及它如何在未来继续这样做？

（32）跟踪公司内你所在领域的每个其他主要项目：你应该能够比他们自己的 IC 更好地解释他们的技术设计。抓住任何机会去与其他类似项目的负责人辩论项目范围：你应该能够阐明你的项目如何适合更大的生态系统。团队间的竞争是健康和必要的。与这些项目中的 IC 交朋友：他们比公司里的其他人更了解你的技术挑战。

（33）不要在原始性能或效率上与其他团队竞争；这将升级为一场军备竞赛，两个团队都会浪费时间为工作负载优化他们的系统，产生苹果与橘子的比较，等等。在基本设计特性上进行竞争。

（34）如果客观上有人在你的使用场景有更好的系统，并想接手它，那就去找别的事做吧。

可观测性

（35）测量是一种手段，而不是目的。

（36）你应该能够在你的客户之前发现你的服务中的问题。

（37）在尽可能的情况下，可观察性应该在 API 之上，并在实现(implementations)之外。这可以确保你可以切换实现并比较性能，而不会在测量代码中引入错误。它还可以简化实现；并降低新实现的门槛。

（38）任何不容易测量的东西（例如，一致性）往往被遗忘；要特别注意那些难以测量的属性。

（39）尽可能将关键的检查（例如一致性）推到部署本身；尽量减少对外部服务的检查（否则你现在有两件事要跟踪，而不是一件）。

研究

（40）追踪你所在领域的研究成果。很快你就会和你的 IC 有一个速记，可以实现超快的沟通。"如果我们尝试项目 X 中的那个东西呢？并将其与项目 Y 中的技术相结合？"。

（41）尝试新事物。在可行的解决方案内，偏向于新的东西。抵制逐字逐句地复制设计的冲动。每一个重要的系统在某些时候都只是某人头脑中的一个半生不熟的想法。

（42）写论文。为那些对你正在做的事情没有任何背景的听众写作，将迫使你检查和澄清你的假设。论文可以使你更容易雇用到的人才，也更容易让他们上岗。研究生应该能够向你解释你的设计（并发现错误！）。当被要求做讲座时，尽量答应。它们很有趣，而且你可以认识新的人。