聰明的程式設計師容易做出錯誤的戰略決策 - earthly

安排工作問題
一家中等規模的SaaS公司的一個小型開發者團隊有一個問題。他們擁有幾個服務，做一些資料載入和轉換。
由於一個新客戶（客戶A）產生的資料量是大多數客戶的好幾倍，所以這些服務的負荷增加了。

他們設法控制住了這個問題，但第二個問題出現了。
他們增加了資料處理的吞吐量，但事實證明，他們損害了資料的公平性。結果，其他一些客戶經常在等待或得到陳舊的結果。
客戶A堵塞了工作佇列，把其他客戶等待堵塞中“餓死”了。
這個問題就像一個作業系統的排程問題，當前只是發生在微服務、分散式系統的背景下。

而這正在造成最糟糕的問題：人的問題：
無視存在某個特殊服務情況下，某個高管現在要求每天對其進行更新。
事實證明，這項服務是使用Postgres表和Kafka主題來進行排程的。
有很多變數需要調整，以獲得吞吐量和公平性的正確組合。
排程是很難的。
因此，有人呼籲：誰可以幫助這個系統？公司裡其他做類似工作的開發人員對Kafka並不熟悉。最好的辦法是讓瞭解這個系統的人去改進它。

因此，團隊在公平性和吞吐量之間找到了一個折中的辦法：
為了防止進一步的事件發生，Tim被要求調查公司一百多個服務中的排隊和工作進度是如何處理的。

Tim是一個非常高階的技術負責人，他很擅長他的工作。
向他提出的問題是：我們如何確保這種情況不會再次發生？如果我們繼續發生這種情況，我們就會失去高知名度的客戶，以及一些有股東價值的東西。我們需要一個比這更好的解決方案。
因此，Tim研究了所有現有的服務，並開始繪製事情的地圖。
結果發現，在所有的服務中，排隊和正在進行的工作都以各種可能的方式處理。
他很難對所有事情有一個真正的全域性觀，但看起來大多數服務各自使用SQS、資料庫表或Kafka中某個技術實現排隊。
 

一個解決方案
所以Tim提出了一個解決方案：建立一個共享庫，你可以用它來滿足你所有的佇列和訊息處理需求。
共享庫背後是由Kafka的支援，每個人都將遷移到kafka上面。
這個解決方案的好處是，所有的東西都會一樣工作。
如果一個從事某項服務的團隊解決了一些工作匱乏的問題，其他人也可以使用這個解決方案，因為它是一個共享的庫。
如果一個領域出了問題，其他團隊的人也可以伸出援手，因為它在任何地方都是同一個解決方案。

但結果根本不是這樣。
 

事情是如何失敗的
在以前的世界裡，每一個處理資料的服務都有一些不同的做法，這使得系統作為一個整體很難從一個自上而下的角度來理解。
Tim很難理解所有的事情是如何運作的，而且這些不同的子系統中的一些問題，在規模上只會變得更糟。

他的假設是，透過將事情標準化，許多這些不相關的小問題，包括最初的公平問題，都可以一次解決。
但是，這個假設被證明是錯誤的。
標準化是一個相當大的努力，它解決了一些問題，但總的來說，它使事情運作得不那麼好。
 
 

像看一個國家一樣看問題
從國家角度看問題：某些改善人類狀況的計劃是如何失敗的？
這涉及到一件事：中央計劃的、自上而下的改善世界的策略是如何失敗的。
它涵蓋了很多集中化的標準化努力，它們都有很多共同點，聽起來很像這種'統一佇列'的努力。

我最喜歡的例子是關於樹木的。
 

科學造林
在19世紀，在歐洲，森林是重要的基本收入。一棵樹可以是木材，一棵樹可以是木柴，一個國家擁有的每一英畝森林都是有價值的。但有多大價值呢？

森林的問題是，它們包含隨機的樹木，這是難以辨認的。
你無法在高層次上了解你有哪些樹木。你可以把它做成地圖，但這很難，而且地圖會非常複雜。

有許多不同型別的樹，它們都可能對不同的事情有用。
事實證明，現實是一團糟。

所以解決方案是科學造林。讓我們製作一張簡化的森林地圖，其中只有最好的樹木型別，並以理想的數量間隔開來，我們將使整個森林符合這一要求。

(順便說一下，事實證明，"最好 "的樹是挪威雲杉。它生長得很快，看起來像一棵聖誕樹）。

貧窮的生態系統無法支援維持周圍農民村莊的野味和藥材，他們遭受了經濟崩潰。一排排一模一樣的樹木是植物疾病和森林火災的完美溫床。
維持土壤的複雜生態過程也不再起作用，所以一代人之後，
挪威雲杉生長不良，營養不良。

你會認為這將結束一切，但有管理的植樹造林仍然流行。
以一種在圖表上看起來非常統一但在實踐中並不順利的方式進行中央規劃的事情今天仍在繼續。

詹姆斯-C-斯科特將這些自上而下的解決方案稱為legible系統：
它們在高層次上很容易解釋：工作如何在該服務中得到處理？和其他所有的服務一樣。那是森林中的什麼型別的樹？它是一棵挪威雲杉，和其他所有的樹一樣。
但是這種方式與“根據領土建立地圖”的做法相反：它屬於“讓我們拿著我們的地圖，讓領土更像它”。
 
問題在於，這種對標準化的推動的做法有一個偏見：會拋棄了大量本地的、默契的技術，而選擇了一個適合最佳化自上而下控制的系統。
 
為了簡單起見，讓我們假設有一個橫跨道路的柵欄或大門（切斯特頓的柵欄）：
比較現代的改革者高高興興地走過去，說："我不知道這有什麼用；讓我們把它清除掉。“
而更聰明的改革者會很好地回答。"如果你看不到它的用處，我當然不會讓你清除它。走吧，好好想想。然後，當你能回來告訴我你確實看到了它的用途時，我可能會允許你銷燬它。"
標準化忽略了切斯特頓的柵欄：

• 為什麼城市發展到有混合使用區？
• 為什麼這項服務使用簡單的資料庫表進行排隊？
• 為什麼挪威雲杉通常不在這裡生長？

很難不範的錯誤
網格規劃的城市、現代分割槽和大規模的建築專案都重複了科學森林學的錯誤。
而這個錯誤很容易說明：它是試圖讓領土與地圖相匹配，而忘記了地圖（或建築圖）只是一張地圖。
當地的許多情況並沒有反映在地圖上。

我並不是說這是一個愚蠢的錯誤，任何人都不應該犯。犯這個錯誤是很容易的。
如果你想了解幾種服務如何處理正在進行的工作，有許多細節需要吸收。作為人類，我們理解這些東西的方式是在它們上面進行抽象，並將細節分組。（過早抽象是萬惡之源）
所有這些服務的工作方式之間有什麼共同點？你建立起一種理解，然後用這種理解，你試圖提出一個解決方案。

像國家一樣看待問題告訴我們的是：會提問題很重要，你提出的問題可能是試圖提出一個全域性性的解決方案。一個全球性的解決方案，必然要忽略當地的條件。
一張地圖所排除的東西必須比它所包括的東西多。一個在白板上更容易畫出來的解決方案不一定更好。它只是更容易畫而已。

回到排隊的例子，如果Tim進入一個具體團隊，努力解決這個具體問題，然後嵌入另一個團隊，解決另一個具體問題，那麼可能會出現一些共同點。
也可能沒有。也許每種情況都需要一個不同的解決方案。與特定的團隊一起實習，你可以瞭解當地的情況。很多東西並不重要，但有些東西很重要。
  
 

Reddit網友討論 
不要試圖創造一個全域性的解決方案，一個一個地解決區域性問題，也許模式就會出現。
 
舉個例子，在過去十年左右的時間裡，許多投資銀行試圖實現的一件事是在其所有的財務、風險和流動性系統中建立一個統一的資料中心/檢視/倉庫/任何你想用的流行語，也許更多。
這個想法是，對於每個客戶的交易，你應該能夠看到所有的交易細節，包括客戶的細節，風險數字，以及它如何在銀行賬戶中入賬的資訊，所有這些都是一次性的。
你可以得到實時的風險數字來快速管理風險，或者你可以為董事會成員、監管機構和審計部門生成精確的、完全協調的會計報告。

要做到這一點，每個系統在釋出和消費資料時都需要有某種共同的標準：資料的格式標準化，與之相關的後設資料，你要多長時間推送或拉取一次，如果出現異常會怎樣，手動更新會怎樣，版本管理等等。
上面這篇博文認為這是徒勞的，多年來，我也傾向於這種觀點。

可以預見的是，據我所知，沒有一家投資銀行能做到這一點。他們已經成功地建立了新的標準，但問題是隨後就轉化為將業務領域和系統一個個地納入其中。每一個入職都有自己的怪癖和問題。統一的系統最終將所有的資料質量問題、時間問題和系統限制結合起來。劃出一個例外意味著這個例外成為一個新的標準，並以某種方式需要與其他所有目前正在工作的系統一起工作。不難想象，需要O(n)甚至O(nm)的額外變通，這取決於一個團隊可以丟擲多少政治影響力。

當然，統一的系統也會成為一個單點故障。如果你不能監控你的風險，這很糟糕，但想象一下同時失去你的財務報告和客戶監控。

我的前僱主，在我離開的時候，至少有4個這樣的系統在生產，每個都有不同的準備程度。我毫不懷疑，有幾個中層管理人員和企業架構師因此得到了晉升，但由於某些原因，他們似乎從來沒有呆過很久......
 
有些程式設計師本能地自上而下地思考，他們需要學會自下而上地思考。然後是那些本能地自下而上思考的程式設計師，那些需要學會自上而下思考的程式設計師：
透過同時從雙方解決問題，您可以獲得介於整體設計和小規模設計之間的資訊流，從而避免了大約 95% 的路徑，這些路徑會導致您自己陷入困境。
 
我在一家公司工作，該公司大力推動整個公司開發團隊的事物標準化……但他們沒有制定指導方針和廣泛的標準，也沒有讓團隊靈活地在這些指導方針內移動。
不，他們基於（最大的）電子商務平臺制定了嚴格的標準，並迫使每個團隊（無論團隊規模或專案目標）都遵循這些標準，這導致了一些令人敬畏的情況，例如：

• 每個 PR 都必須得到三名非管理團隊成員的批准。我們的一個團隊有兩個人，其中一個是經理。
• 每個員工都會獲得 Office 的 E1 許可證——這被認為是足夠的。E1 不允許儲存電子郵件以附加到工單或開啟 CSV 檔案……這在我的團隊所做的工作中經常出現。
• DBA 標準是一場噩夢，包括不允許超過五個字元的 ID。我們的一些表有六個字元 ID 欄位（大量生成的欄位），或者無法儲存超過一定大小的資料（這使得我們的日誌記錄工作有點困難，因為我們記錄了整個請求）。
• 我最喜歡的是設計團隊堅持表單的大小不應超過四個欄位，如果我們需要更多欄位，我們應該有另一個螢幕，使用者將被髮送到……因為電子商務網站就是這樣工作的。