我从构建生产型数据库中学到的42件事

2022 年 3 月 29 日 CSDN

作者 | mahesh 译者 | 王雪迎

出品 | CSDN（ID：CSDNnews）

2017年，我在耶鲁大学教职期间休假去了Facebook。我创建了一个团队，在Facebook的技术堆栈底部构建一个名为Delos的存储系统（可以将其视为Facebook版的Chubby）。在不到一年的时间里，我们与一个三人团队一起进行研发；随后将团队扩展到30多名工程师，跨越多个子团队。

在我领导团队的四年中（直到2021年春天），我们没有经历过一次严重的停机（没有出现比SEV3更高程度的严重问题）。Delos的设计在两篇学术论文（ OSDI 2020 和 SOSP 2021 ）中得到了充分说明。Delos目前正在Facebook上取代ZooKeeper的所有适用场景。

以下是我作为Delos技术负责人所学到的一些东西。我发表这篇文章的目的在于帮助其他类似角色的人（在大公司领导建立新基础架构的团队），其中大部分可能无法推广到不同的情况。

注：IC是公司用语中的“个人贡献者”，例如不管理他人的人。在当前语境下，IC可以解释为工程师或开发人员。

客户：

[1] 让你的顾客满意，否则本文档的其余部分则无关紧要。

[2] 注意拥有适当的客户数量（最开始只有一个）和适当的客户（其需求允许你构建关键技术）；小心增加客户数量。

[3] 直接与客户ICs进行交互。很多团队内部的冲突可以通过说“我刚才和客户谈过，他们说……”来解决。在构建基础架构时，我们通常不要猜测客户想要什么，我们只要问他们。

[4] 但要意识到，客户可能无法表达他们真正的需求；不要从表面上看需求，而要花时间详细了解他们的用例，阅读他们的代码。

项目管理：

[5] 有一个简单、清晰的任务说明，表达项目存在理由。对于Delos来说，我们将是Facebook的一个可靠基础设施架构。

[6] 反复对任务难度进行社会化评估；决策者可能没有时间、意向、背景或培训来生成这些估计值，并且可能（从字面上）将它们弄错几个数量级。

[7] 将任务分配给ICs很重要；要求自己处于任何决策的关键路径中，因为你通常比管理者更了解问题、代码库和IC的优势。如果你和另一个IC自己解决任务分配问题，大多数管理者都会感到兴奋。

[8] 路线图是一种手段，而不是目的。

[9] 如果你遇到了优秀的或知行合一的管理者，尽可能地理解、支持和包容他们。如果你找不到这样的管理者……嗯，我还不清楚如何是好，如果你知道请告诉我。

[10] 使你的项目健壮，以便于重新组织。一个公司的管理层次结构本质上是脆弱的（毕竟，一棵树是一个单连通图）；与未来可能接手的管理者持续地交流项目。尽一切努力确保管理层震荡不会给ICs带来不公的职业成果。

[11] 跟踪你所在领域的其他项目中类似功能的研发用时，并以此作为任务难度评估的依据（例如，“开发系统Y中的功能X用了三年时间；它不是一个IC的一半工作。”）。

设计：

[12] 在API上要保守，在实现上要自由。

[13] 但在推出新的实现时，要坚持谨慎的流程（跟踪、分阶段推出）。

[14] 在设计API时，为一个实现编写代码；积极规划第二次实施；并希望可以工作于第三次实施。

[15] 将迁移到新实现作为首要考虑因素来设计API；自定义迁移是巨大的时间陷阱，也是不可靠的来源。每个主要API都应该有一个用于切换实现的CLI驱动调用。

[16] 团队设计，个人实现。这将使设计成为瓶颈，但这是值得的：抑制并行设计的冲动。

[17] 对于存储系统，一开始就严重偏向于一致性和持久性，而不是可用性；这些很难测量，如果损坏，也很难修复。由于可用性更容易衡量，因此会有外部压力要求首先对其进行优先处理；推拒。

[18] 在API测试中维护多个实现；比较它们之间的结果。成本是值得的（这将有助于提高正确性，并防止实现细节遗漏）。

[19] 后期绑定到设计：鼓励团队考虑整体设计空间，而无需承诺特定点的解决方案。与一群高智商、固执己见的ICs进行头脑风暴会议是一门值得掌握的艺术。鼓励在绑定到设计的关键路径中使用粗糙原型。

[20] 后期绑定到实现：一旦设计完成，任何IC都应该能够编写代码。

[21] 有适当数量的抽象（这很难）。太少了，你会得到一个难以处理的整体；太多了，团队将被理解每个抽象语义的认知开销所压倒。

[22]避免使用实时来保证正确性，或在机器之间比较时钟，除非你存在（并理解）时钟上的误差范围。

[23] 只有一个事实来源。在不同类型的状态之间建立简单的不变量。

[24] 创造一种文化，让IC不断考虑截然不同的设计；不要停止关于假定设计被替代的对话。鼓励好奇心。

[25] 了解你的SKU。云基础设施使得忽略硬件变得容易；但对硬件（以及硬件趋势）的理解对设计至关重要。

代码审查：

[26] 在一个具有快速审查周期的透明代码库中，API将透露实现细节，除非你将其关闭。

[27] 鼓励ICs批判性地思考不同观点，并创造一个人们可以自由表达观点的环境。作为一个持不同观点者，对于对问题提出不同意见的人，你的回应应该是感激，而不是沮丧。

[28] 对于关键组件，考虑非正式规则，例如需要两个认可甚至来自某些IC子集的一致认可。

[29] 对于关键组件，解决差异的时间并不是一个重要的度量标准：顶住冲动以考量该差异并对其进行优化。创造一种文化，使IC可以接受差异，而不是快速终结它（创造性的努力——书籍、论文等——通常因为高质量的审查成本而涉及长时间的审查周期；为什么代码应该不同？）。

[30] 有时，只有在IC将候选设计编写成差异设计后，你才能意识到某件事情的正确设计。克服冲动，不要说“哦，好吧，让我们先放下它，以后再解决它”；这样做既不能帮助IC也不能帮助项目。创建一种文化，让IC觉得如果代码不是正确的解决方案，就可以轻松地扔掉它（通过示例引导）。

策略：

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

[32] 跟踪公司内你所在领域的所有其他重大项目：你应该能够比这些设计的ICs更好地说明他们的技术设计。抓住任何机会与其他类似项目的负责人讨论范围：你应该能够清楚地说明你的项目如何适应更大的选项生态系统。团队间的竞争是健康和必要的。在这些项目中与ICs交朋友：他们比公司中的任何人都更了解你的技术挑战。

[33] 不要与其他团队就原始业绩或绩效进行竞争；这将升级为一场军备竞赛，在这场竞赛中，两个团队都会浪费时间优化他们的系统以获得目标工作量，生成苹果对桔子的比较，等等。在基本设计特质上展开竞争。

[34] 如果有人客观上对你的使用场景有一个更好的系统，并且希望采用它，那么就去找其他的事情来做。

可观测性：

[35] 测量是一种手段，而不是目的。

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

[37] 在力所能及的情况下，可观测性应该在API之上，并在实现之外。这确保了你可以切换实现并比较性能，而不会在测量代码中引入错误。它还使实现整洁；并降低新实现的门槛。

[38] 任何不易衡量的东西（如一致性）往往被遗忘；特别注意难以测量的属性。

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

调研：

[40] 跟踪你所在领域的研究。很快你就会对你的ICs有一个速记，可以实现超快的通信：“如果我们试一下projectX上的东西呢？并将它与projectY中的技术结合起来会怎么样？”。

[41] 尝试新事物。在可行解决方案的范围内偏向新颖性。与逐字复制设计的冲动作斗争。每一个主要系统在某个时候都只是某人头脑中的一个半生不熟的想法。

[42] 写论文。为一个对你所做的事情没有任何背景的读者写作会迫使你检查并澄清你的假设。论文使雇佣优秀人才和加入他们变得更容易。研究生应该能够向你解释你的设计（并找到错误！）。当被要求演讲时，试着说“是”。他们很有趣，你可以结识新朋友。

参考链接：

https://maheshba.bitbucket.io/blog/2021/10/19/42Things.html?continueFlag=c645eb56deb5defaca5e9b73e57333a8

END

  
  
    
   
   
     
    
    
      
     
     
       
      
      
        
       
       
         — 推荐阅读 —
      
      
        
     
     
       
    
    
      
   
   
     
  
  
    
   
   
     
    
    
      ☞俄罗斯 Android 系统受限，或将转用 HarmonyOS！
   
   
     
   
   
     
    
    
      ☞想成为金融科技超新星吗，FinTech精英训练营等你来！
   
   
     
   
   
     
    
    
      ☞GitHub 多次宕机的罪魁祸首竟是 MySQL？