耶魯大學教授從構建生產資料庫中學到的 42 件事 - maheshba

客戶

• [1] 讓您的客戶滿意；否則本文件的其餘部分無關緊要。
• [2] 小心擁有正確數量的客戶（一開始，只有一個）和正確的客戶（他們的需求允許您構建關鍵技術）；並小心地增加這個數字。
• [3] 直接與客戶 IC 介面。很多團隊內部的衝突可以透過說“我剛剛和客戶談過，他們說……”來解決。在基礎架構中，我們通常不需要推測客戶想要什麼；我們可以問問他們。
• [4] 但要意識到客戶可能不會表達他們真正需要的東西；不要從表面上看需求，而是花時間詳細瞭解他們的用例。閱讀他們的程式碼。

專案管理：

• [5] 有一個簡單明瞭的使命宣言來表達你的存在理由。對於 Delos 而言，它是：我們將成為 FB infra 的可靠基礎。
• [6] 重複社會化任務難度的估計；決策者可能沒有時間、傾向、背景或培訓來生成這些估計值，並且可能會錯誤地（字面意思）出現數量級的錯誤。
• [7] 任務分配給 IC 很關鍵；要求處於任何決策的關鍵路徑中，因為您通常比經理更瞭解問題、程式碼庫和 IC 的優勢。如果您和其他 IC 自行確定任務分配，大多數經理都會感到興奮。
• [8] 路線圖是一種手段，而不是目的。
• [9] 如果你得到了優秀的和/或一致的經理，儘可能地理解、支援和包容。如果你沒有這樣的經理......好吧，我還沒有弄清楚這一點，如果你做到了，請告訴我。
• [10] 使您的專案健壯以適應重組。公司的管理層級本質上是脆弱的（樹畢竟是一個 1-連通圖）；與未來可能接手的經理不斷地交流專案。盡一切努力確保經理流失不會給 IC 帶來不公平的職業結果。
• [11] 跟蹤類似功能在您所在領域的其他專案中花費的時間，並將其用作估計任務難度的證據（例如，“功能 X 在系統 Y 中花費了三年時間；這不是一個 IC 的一半工作。 ”）。

設計：

• [12] 對 API 持保守態度，對實現持開放態度。
• [13] 但堅持圍繞推出新實現（影子、分階段推出）的謹慎過程。
• [14] 在設計 API 時，為一種實現編寫程式碼；積極籌劃二次實施；並希望/祈禱事情將適用於第三次實施。
• [15] 設計 API 時將遷移到新的實現作為首要考慮；自定義遷移是巨大的時間消耗和不可靠性的來源。每個主要 API 都應該有一個單一的 CLI 驅動呼叫來切換實現。
• [16] 團隊設計；作為個人實施。這將使設計成為瓶頸，但這是值得的：推遲並行化設計的衝動。
• [17] 對於儲存系統，一開始就嚴重偏向於一致性和永續性，而不是可用性；這些更難測量，如果損壞則更難修復。因為可用性更容易衡量，所以會有外部壓力優先考慮它；推回。
• [18] 在 API 測試中維護多個實現；比較它們之間的結果。成本是值得的（這將有助於提高正確性，並防止洩漏實現細節）。
• [19] 設計後期繫結：鼓勵團隊考慮整個設計空間，而無需致力於特定的點解決方案。與一群高智商、固執己見的 IC 進行頭腦風暴會議是一門值得掌握的藝術。鼓勵在繫結到設計的關鍵路徑中進行粗略的原型設計。
• [20] 對實現者的後期繫結：一旦設計完成，任何 IC 都應該能夠編寫程式碼。
• [21] 有正確數量的抽象（這很難）。太少了，你最終會得到一個凌亂的巨石；太多了，團隊將被理解每個抽象語義的認知開銷所淹沒。
• [22] 避免使用實時來保證正確性或跨機器比較時鐘，除非您有（並理解）時鐘上的誤差界限。
• [23] 擁有單一的事實來源。在各種型別的狀態之間建立簡單的不變數。
• [24] 營造一種文化，讓 IC 不斷思考完全不同的設計；不要關閉有關假設性替代設計的對話。鼓勵好奇心。
• [25] 瞭解您的 SKU。雲基礎設施很容易忽略硬體；但是對硬體（和硬體趨勢）的理解對於設計至關重要。

程式碼審查：

• [26] 在具有快速審查週期的透明程式碼庫中，API 將洩漏實現細節，除非您保持警惕。
• [27] 鼓勵 IC 對差異進行批判性思考，並創造一個人們可以自由表達疑慮的環境。作為差異作者，您對指出差異問題的人的回應應該是感激，而不是沮喪。
• [28] 對於關鍵元件，請考慮非正式規則，例如要求來自某些 IC 子集的兩個接受或什至一致接受。
• [29] 對於關鍵元件，登陸差異的時間不是一個重要的指標：抵制衝動來衡量這個指標並最佳化它。創造一種文化，在這種文化中，IC 沒有問題，差異不會很快落地（創造性的努力——書籍、論文等——由於高質量審查的成本，通常需要很長的審查週期；為什麼程式碼應該不同？）。
• [30] 有時，只有在 IC 將候選設計編寫為差異之後，您才會意識到某些東西的正確設計。剋制說“哦，好吧，讓我們降落然後再修復它”的衝動；你這樣做並沒有幫助 IC 或專案。創造一種文化，如果程式碼不是正確的解決方案（以身作則），IC 可以輕鬆地丟棄程式碼。

戰略：

• [31] 以某種節奏問問自己：團隊/專案為什麼存在？如果它不存在，會發生什麼（哪個團隊/系統會填補空白）？團隊如何為公司增加價值，未來如何繼續這樣做？
• [32] 跟蹤公司內您所在領域的所有其他重大專案：您應該能夠比他們自己的 IC 更好地解釋他們的技術設計。抓住任何機會與其他類似專案的負責人討論範圍：您應該能夠闡明您的專案如何適應更大的選項生態系統。團隊間的競爭是健康的，也是必要的。在這些專案中與 IC 成為朋友：他們比公司中的任何其他人都更瞭解您的技術挑戰。
• [33] 不要在原始表現或效率上與其他團隊競爭；這將升級為軍備競賽，雙方團隊都浪費時間針對點工作負載最佳化他們的系統，生成蘋果與橙子的比較等。在基本設計特徵上展開競爭。
• [34] 如果有人客觀上為您的用例提供了更好的系統並希望採用它，那就去尋找其他事情做。

可觀察性：

• [35] 測量是一種手段，而不是目的。
• [36] 您應該能夠在您的客戶之前發現您的服務中的問題。
• [37] 儘可能地，可觀察性應該在 API 之上並在實現之外。這確保您可以切換實現並比較效能，而不會在測量程式碼中引入錯誤。它還使實現變得整潔；並降低了新實現的門檻。
• [38] 任何不能輕易衡量的東西（例如，一致性）常常被遺忘；特別注意難以衡量的屬性。
• [39] 儘可能將關鍵檢查（例如一致性）推入部署本身​​；儘量減少對外部檢查服務的依賴（否則您現在需要跟蹤兩件事而不是一件）。

研究：

• [40] 跟蹤您所在領域的研究。很快，您的 IC 就會有一個速記，可以實現超快速通訊：“如果我們從 projectX 嘗試那個東西怎麼辦？並將其與 projectY 中的技術結合起來？”。
• [41] 嘗試新事物。在可行解決方案的空間內偏向新穎性。打擊逐字複製設計的衝動。每個主要系統在某個時候都只是某人頭腦中的一個不成熟的想法。
• [42] 寫論文。為一個對你所做的事情沒有任何背景的觀眾寫作將迫使你檢查和澄清你的假設。論文使僱用優秀人才和加入他們變得更容易。研究生應該能夠向你解釋你的設計（並找到錯誤！）。當被要求發表演講時，試著說是。他們很有趣，你可以結識新朋友。