最近读到了分布式系统研究者 Mahesh Balakrishnan 的一篇博客《42 things I learned from building a production database》。同样从事基础架构工作，看完大佬总结的经验后，真是拍案叫绝。其中有几条见解深刻，堪称真知灼见，所以我把全文翻译了过来，与大家分享。
Mahesh Balakrishnan 是 Facebook Delos 项目的负责人。Delos 是一个对标 ZooKeeper 的项目，其团队已经发表了两篇详细论文，感兴趣的同学可以自行搜索。
译注：IC = Individual Contributor，即独立贡献者，这是 Facebook 开发团队的一个术语，指那些不是经理、不是团队领导、不担任任何管理职位的编码人员，可以理解为一线开发者。
以下为正文：
对客户（用户）
（1）让你的客户开心；否则，这篇文章的其余部分都无关紧要。
（2）要注意拥有正确数量的客户（刚开始时，一个就好）和合适的客户（他允许你构建关键技术）；并小心地增加这个数字。
（3）直接与客户对接。很多团队内部冲突可以通过一句“我刚才和客户谈过，他们说......”来解决。在做基础架构时，我们往往不需要猜测客户的需求，我们可以直接问他们。
（4）但要意识到客户可能无法准确表达他们真正需要的东西；不要只看需求的表面价值，而要花时间深入理解他们的用例。去阅读他们的代码。
项目管理
（5）要有一个简单明了的使命宣言来表达你存在的理由。Delos 的宣言是：我们将成为 Facebook 基础设施的可靠基石。
（6）反复进行任务难度的评估；决策者可能没有时间、倾向、上下文或能力来进行准确评估，而且可能会把它们搞错好几个数量级。
（7）对 IC（独立贡献者）的任务分配至关重要。要求自己处于任何决策的关键路径上，因为你通常比经理更了解问题、代码库和 IC 们的优势。如果你和其他 IC 能自己解决任务分配问题，大多数经理都会很高兴。
（8）路线图是一种手段，而不是目的。
（9）如果你拥有优秀和/或靠谱的经理，要尽可能地理解、支持和包容他。如果你没有这样的经理……好吧，我还没完全想明白这个问题，如果你想明白了，请告诉我。
（10）让你的项目对组织架构调整有足够的鲁棒性。一个公司的管理层级本质上是脆弱的（毕竟，树是一个单点连接的图）；要不断地与未来可能接手这个项目的经理进行交流。不惜一切代价，确保经理的变动不会给 IC 们带来不公平的职业结果。
通常来说，公司组织架构调整非常频繁，经常一年就会调整一次。确保经理的变动不带来不公平的职业结果，这点其实很难做到（我也很想知道具体方法）。
（11）追踪你所在领域的其他项目中，类似的功能花了多长时间，并以此作为任务难度评估的依据（例如，“功能 X 在系统 Y 中花了 3 年时间；这可不是一个 IC 半个月就能搞定的工作”）。
设计
（12）对 API 要保守，对实现要灵活（Be conservative on APIs and liberal with implementations）。
（13）但要坚持谨慎地推出新的实现（灰度、分阶段推出）。
（14）设计 API 时，写代码完成第一个实现；积极规划第二个实现；然后希望/祈祷事情能在第三个实现中顺利运作。
（15）设计 API 时，首要考虑向新实现的迁移方案；自定义迁移会造成巨大的时间消耗且不可靠。每个主要的 API 都应该有一个单一的 CLI 驱动的调用来切换实现。
（16）团队协作进行设计；个人独立完成实现。这会让设计成为瓶颈，但值得这样做：要抵制并行化设计的冲动。
（17）对于存储系统，在开始时就要重点关注一致性和持久性，而不是可用性。一致性和持久性更难衡量，如果出问题也更难修复。由于可用性更容易被感知和衡量，所以会有外部压力要求优先考虑它；把它往后放一放。
（18）在测试中维护 API 的多个实现；比较它们之间的结果。这样做的代价是值得的（这将有助于确保正确性，也可以防止实现细节泄露给外部）。
（19）对设计进行“后期绑定”（Late-bind）：鼓励团队思考整个设计空间，而不是过早承诺使用某个特定的解决方案。与一群高智商、有主见的 IC 们一起开头脑风暴会议是一门值得掌握的艺术。鼓励在设计的关键路径上进行粗略的原型设计。
（20）对实现者进行“后期绑定”：一旦设计完成，任何 IC 都应该能够编写代码。
（21）拥有适当数量的抽象（这很难）。太少了，你会得到一个混乱的单体；太多了，团队会被理解每个抽象语义的认知开销所淹没。
（22）避免依赖实时性来保证正确性或在机器间比较时钟，除非你拥有（并深刻理解）时钟的误差界限。
（23）建立单一的真相来源。在各种类型的状态之间建立简单的不变量。
（24）创造一种文化，让 IC 们持续思考完全不同的设计方案；不要停止关于假设性替代设计的对话。鼓励好奇心。
（25）了解你的硬件规格。云计算让人们很容易忽视硬件；但对硬件（和硬件发展趋势）的理解对设计来说至关重要。这些关于后端与架构的知识，是构建稳定系统的基石。
代码审查
（26）在一个具有快速评审周期的透明代码库中，除非你严格把关，否则 API 会泄露实现细节。
（27）鼓励 IC 对代码变更（diffs）进行批判性思考，并创造一个人们可以自由表达意见的环境。作为变更的作者，你对指出问题的人的反应应该是感激，而不是沮丧。
（28）对于关键组件，考虑引入非正式规则，例如要求两个“批准”（即两个 LGTM），甚至是要求某个子集的 IC 一致同意。
（29）对于关键组件，代码合入时间不是衡量其重要性的标准：抵制衡量这一指标并优化它的冲动。创造一种文化，让 IC 们可以接受关键变更不能快速合入的事实（创造性的工作——书籍、论文等等——由于高质量评审的成本，通常需要漫长的周期；为什么代码就应该不同呢？）。
（30）有时候，你只有在一个 IC 写出了候选的设计方案后，才意识到这个设计是正确的。要抵制说“哦，好吧，让我们先合入，然后再修复它”的冲动；你这样做对 IC 和项目都没有帮助。创造一种文化，让 IC 们感觉到如果这不是正确的解决方案，就可以丢弃代码（以身作则）。
策略
（31）定期问自己：为什么这个团队/项目会存在？如果它不存在，会发生什么（哪个其他团队/系统会填补这个空白）？该团队是如何为公司增加价值的，以及它如何在未来继续这样做？
（32）跟踪公司内你所在领域的其他每个主要项目：你应该能够比他们自己的 IC 更好地解释他们的技术设计。抓住任何机会与其他类似项目的负责人辩论项目范围：你应该能够阐明你的项目如何适应更大的生态系统。团队间的竞争是健康和必要的。与这些项目中的 IC 交朋友：他们比公司里的其他人更了解你面临的技术挑战。
（33）不要在原始性能或效率上与其他团队竞争；这会升级为一场军备竞赛，两个团队都会浪费时间为特定工作负载优化系统，产生苹果与橘子的无效比较，等等。应该在基本设计特性上进行竞争。
（34）如果客观上有人在你面对的使用场景中拥有更好的系统，并且想接手它，那就去找别的事情做吧。
可观测性
（35）测量是一种手段，而不是目的。
（36）你应该能够在你的客户之前发现你的服务中的问题。
（37）在尽可能的情况下，可观测性应该构建在 API 之上，并与具体实现分离。这可以确保你在切换实现和比较性能时，不会在测量代码中引入错误。它还能简化实现，并降低新实现的门槛。这不仅是运维/DevOps的最佳实践，也是确保系统长期稳定和可维护的关键。
（38）任何不容易测量的东西（例如，一致性）往往被遗忘；要特别注意那些难以测量的属性。
（39）尽可能将关键的检查（例如一致性检查）内嵌到部署流程本身；尽量减少对外部检查服务的依赖（否则你现在有两件事要跟踪，而不是一件）。
研究
（40）追踪你所在领域的研究成果。很快你就会和你的 IC 们形成一种高效的速记沟通方式。“如果我们试试项目 X 中的那个东西呢？再和项目 Y 里的技术结合一下？”
（41）尝试新事物。在可行的解决方案中，偏向于尝试新的思路。抵制逐字逐句复制现有设计的冲动。每一个重要的系统在某个时刻，都只是某个人头脑中的一个半生不熟的想法。
（42）写论文。为那些对你正在做的事情没有任何背景的听众写作，将迫使你检查和澄清你的假设。论文可以使你更容易雇用到优秀的人才，也更容易让他们快速上手。研究生应该能够向你解释你的设计（并发现其中的错误！）。当被邀请做技术讲座时，尽量答应。它们很有趣，而且你可以认识新朋友。
来源：多颗糖
原文链接：https://maheshba.bitbucket.io/blog/2021/10/19/42Things.html
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢！
希望这些来自一线实战的经验，能对你构建和维护复杂的基础架构系统有所启发。如果你想与更多同行交流这些心得，可以到 云栈社区 分享你的看法。
发表于 14 小时前
|
查看: 3|
回复: 0
