譯者序

最近讀到了分布式系統研究者 Mahesh Balakrishnan 的一篇博客《42 things I learned from building a production database》。同樣做基礎架構，看完大佬總結的經驗后拍案叫絕，其中有幾條簡直是真知灼見，故翻譯了全文。

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）寫論文。為那些對你正在做的事情沒有任何背景的聽眾寫作，將迫使你檢查和澄清你的假設。論文可以使你更容易雇用到優秀的人才，也更容易讓他們上崗。研究生應該能夠向你解釋你的設計（并發現錯誤！）。當被要求做講座時，盡量答應。它們很有趣，而且你可以認識新的人。

原文：https://maheshba.bitbucket.io/blog/2021/10/19/42Things.html

譯者：多顆糖