我最近阅读了分布式系统研究员MaheshBalakrishnan《42 things I learned from building a production database》的一篇博文。一样的基础架构，看了大佬们总结的经验，不知所措，有的还真有见地，于是翻译了全文。MaheshBalakrishnan是FacebookDelos项目的负责人。Delos正在针对ZooKeeper进行基准测试。有关Delos的更多详细信息，其团队已发表了两篇论文。感兴趣的同学可以自行搜索。IC=IndividualContributor，即独立贡献者，是Facebook开发团队的一个术语，指的是不担任经理、团队领导或任何领导职位的编码员，可以理解为一线开发人员。对于客户（用户）1）让你的客户开心，否则这篇文章的其余部分是无关紧要的。2)注意拥有合适数量的客户（一开始，只有一个）和合适的客户（允许您构建关键技术的客户），并谨慎增加该数量。3)直接与客户联系。很多团队内部的冲突都可以用“我刚和客户谈过，他们说……”这句话来解决。在做基础设施的时候，我们往往不需要去猜测客户需要什么，直接问他们就可以了。4)但意识到客户可能无法表达他们真正需要的东西。不要只是从表面上看需求，花时间详细了解他们的用例，阅读他们的代码。项目管理5)有一个简单明了的使命宣言来表达你存在的理由，Delos的宣言是：我们将成为FBinfra的可靠基础。6)反复评估任务的难度。决策者可能没有时间、兴趣、背景或培训来进行评估，并且可能会（字面上）错误地按数量级计算。7）给IC分配任务很关键。要求自己处于任何决策的关键路径上，因为您通常比经理更了解问题、代码库和IC的优势。如果您和其他IC自己解决分配问题，大多数经理都会很高兴。8)路线图是手段，不是目的。9)如果你有好的或一贯的经理，尽可能理解、支持和包容。如果您没有这样的经理……好吧，我还没有弄清楚，如果您有，请告诉我。10)使你的项目足够健壮以适应组织调整。一个公司的管理层级本来就是脆弱的（毕竟树是单连通图），所以要不断地和未来可能接手这个项目的管理者沟通，不惜一切代价，确保管理者的变动不影响IC他们导致不公平的专业结果。一般来说，公司的组织架构调整非常频繁，经常是一年一次，要保证管理者的变动不会带来不公平的职业结果，这其实很难（我也想知道怎么做）。11)跟踪你所在领域的其他项目中类似功能花费了多长时间，并将其作为任务难度评估的基础（例如，“系统Y中的功能X花费了3年；这不是IC的一半工作”）.设计12)在API上保守，在实现上自由。13)但坚持谨慎地推出新的实施（灰度、分阶段推出）。14)设计API时，为第一个实现写代码，为第二个积极规划，希望/祈祷第三个能行。（在设计API时，为第一个实现编写代码；为第二个实现积极计划；并希望/祈祷第三个实现能够正常工作。）15）在设计API时，首先考虑迁移到新的实现。自定义迁移可能非常耗时且不可靠。每个主要API都应该有一个CLI驱动的调用来切换实现。16)Designasateam,implementasindividuals（设计为团队；实施为个人）。这将成为设计的瓶颈，但这是值得的：抵制并行化设计的冲动。17)对于存储系统，从一开始就关注一致性和持久性，而不是可用性。一致性和持久性更难衡量，如果出现问题更难修复，并且由于可用性更容易衡量，因此会有外部压力对其进行优先排序；把它推到次要位置。18)在测试中维护API的多个实现，比较它们之间的结果。这样做的代价是值得的（这将有助于正确性并防止泄漏实现细节）。19)后期绑定设计：鼓励团队考虑整个设计空间，而不是致力于特定的解决方案。与一群高智商、固执己见的IC进行头脑风暴会议是一门值得掌握的艺术。鼓励在设计的关键路径上制作粗略的原型。20)实现者的后期绑定：一旦设计完成，任何IC都应该能够编写代码。21)有适量的抽象（这很难）。太少，你会得到一个凌乱的单体；太多了，团队就会被理解每个抽象语义的认知开销所淹没。22)避免使用实时来保证正确性或比较机器之间的时钟，除非你有（并且理解）时钟的误差范围。23)真理只有一个来源。在各种状态之间建立简单的不变量。24)创造一种文化，让IC不断思考截然不同的设计，不要停止关于假设性替代设计的对话，鼓励好奇心。25)了解你的SKU。云计算很容易忽视硬件，但了解硬件（和硬件趋势）对设计至关重要。代码审查26)在具有快速审查周期的透明代码库中，除非您检查，否则API会泄露实现细节。27)鼓励IC批判性地思考差异并创造一个人们可以自由表达自己的环境。作为差异作者，您对指出差异问题的人的回应应该是感激之情，而不是沮丧。28)对于关键组件，考虑非正式规则，例如要求两次接受（即两个LGTM）或什至一致接受某些IC子集。29)对于关键组件，落地时间并不是衡量其重要性的指标，抵制衡量这一点并对其进行优化的冲动。创建一种文化，让IC接受不能快速落地的差异（创造性工作——书籍、论文等——由于高质量审查的成本，通常需要漫长的审查周期；为什么代码应该不同？）30）有时你直到IC编写了候选设计后，才意识到设计是正确的。抵制说“哦，好吧，让我们先着陆，然后再修复”的冲动；这样做对IC或项目没有任何帮助。营造一种文化，让IC认为如果解决方案不正确（以身作则）可以丢弃代码。策略31）有节奏地问自己：这个团队/项目为什么存在？如果它不存在，会发生什么（哪个其他团队/系统将填补空白）？团队如何为公司增值，未来如何继续这样做？32)跟踪公司内你所在领域的每一个其他重大项目，你应该能够比他们自己的IC更好地解释他们的技术设计。抓住任何机会与其他类似项目的负责人讨论项目范围：您应该能够阐明您的项目如何适应更大的生态系统。团队之间的竞争是健康且必要的。与这些项目中的IC交朋友：他们比公司中的任何其他人都更了解您的技术挑战。33)不要在原始性能或效率上与其他团队竞争。这将升级为一场军备竞赛，两个团队将浪费时间优化他们的系统以适应工作负载，生成苹果与橘子的比较等。在基本设计功能上展开竞争。34)如果有人客观上对你的用例有更好的系统并想接管它，那就去找别的事情做。可观察性35)测量是一种手段，而不是目的。36)你应该能够在你的客户之前发现你服务中的问题。37)在可能的情况下，可观察性应该在API之上和实现之外。这确保您可以切换实现并比较性能，而不会在您的测量代码中引入错误。它还简化了实施；并降低新实施的进入门槛。38)任何不容易衡量的东西（例如一致性）往往会被遗忘，特别注意难以衡量的属性。39)尽可能将关键检查（例如一致性）推入部署本身??，尽量减少对外部服务的检查（否则你现在要跟踪两件事而不是一件）。研究40)追踪你所在领域的研究成果。很快您就可以使用IC进行速记，从而实现超快速通信。“如果我们尝试X项目的那个东西会怎么样？并将它与Y项目的技术结合起来？”。41)尝试新事物。在可行的解决方案中，偏爱新事物。抵制逐字复制设计的冲动。每个重要的系统在某个时候都只是某个人头脑中的一个半生不熟的想法。42)写一篇论文。为不了解您的工作背景的读者写作会迫使您检查并澄清您的假设。一篇论文可以让你更容易地聘请优秀人才并让他们投入工作。研究生应该能够向您解释您的设计（并发现错误！）。当被要求做演讲时，试着说是。他们很有趣，你会结识新朋友。
