架構與業務一同成長

我在中國幾家規模最大的網際網路公司工作時，經常在會議上聽到一些宏大的說法：「這項技術的最佳實務」、「最優架構」，以及「下一代基礎設施平台」。

當時，雲端服務正逐漸普及，但我任職的公司仍自行打造大部分基礎設施。它們設有專責的基礎設施部門，由龐大的團隊開發和維護內部系統。

想像一下，每家大型網際網路公司裡都有一個小型 AWS。

其中一些系統解決了真正的問題。另一些則造成了負擔，在打造它們的人離開後，依然持續了很長一段時間。

員工來來去去。內部政治、績效考核與升遷條件都影響著技術決策。打造一個框架可以帶來肯定與影響力，但多年後維護它，得到的關注卻少得多。

在一家公司裡，我所屬部門的一位主管曾把我叫到一旁，說我的架構太著重於服務業務。他解釋，在自己的技術平台中，他刻意將不同團隊的業務功能與底層基礎設施耦合在一起。這讓各個部分更難拆開，也讓那些團隊更加依賴他。

他所描述的是一項刻意的設計選擇。這些相依關係鞏固了他的地位，卻將它們所造成的複雜性留給公司承擔。

那次談話一直留在我的記憶中。我懷疑即使在那個部門裡，這也不是孤例，更不用說整個產業了。

為了維護某個人的地位而打造的架構，可能會讓業務更難轉向。當公司需要拆分一項服務、替換一個元件，或停止使用某個平台時，那些刻意建立的相依關係就會成為障礙。

這是我對熱衷打造內部框架抱持疑問的原因之一。

一個部門可能會開發自己的框架，即使已經有成熟且廣泛使用的開源替代方案。我們憑什麼期待自己的版本會更好？更重要的是，我們憑什麼期待它能長期保持優勢？

即使內部版本在推出時占有優勢，維持這項優勢也需要持續投入。被廣泛採用的開源專案，會在許多公司與真實情境中接受檢驗。活躍的社群可以找出錯誤、貢獻修正、改善文件，並使軟體適應新的需求。

與此同時，最初的內部開發者可能離開。接手的人需要學習這個系統，理解那些從未妥善記錄的決策。其他團隊也會逐漸建立對它的依賴。到了最後，升級或替換它可能涉及大量工作與風險。

最初的技術成就，可能演變成技術債。

我見過太多不必要的框架被打造、採用，之後卻缺乏充分的維護。「開源方案不符合我們的需求」是耳熟能詳的解釋。有時確實如此。有時透過設定、小幅擴充，或向上游專案貢獻，就能解決問題。

在決定投入內部替代方案之前，我們應該能回答三個問題：哪一項限制正在阻礙業務？自己的方案會帶來什麼實質優勢？原團隊離開後，公司是否還能持續承擔這份責任？

也有一些時候，自行開發技術是必要的。

新的商業模式、真正全新的技術產品，或獨特的運作環境，可能需要現有工具無法提供的能力。在這些情況下，強迫業務配合現成工具，可能會阻礙公司的發展。開發缺少的能力，可能是成長不可或缺的一環。

拒絕做這項工作，可能與打造不必要的東西一樣有害。

要分辨兩者，需要判斷力，也需要對自己誠實。我們必須區分業務真正需要的能力，與自己想要擁有的平台。而且，隨著業務與可用工具改變，我們也必須重新審視這項判斷。

這讓我想到一個更廣泛的問題：什麼才是好的架構？

我不認為存在一套所有公司都應遵循的標準架構。我們今天研究的架構，是人們因應特定業務、限制與工具而逐步發展出來的。在採用他們的答案之前，我們應該先理解那些條件。

早期的 YouTube 是我經常回想的例子。它的基礎設施仍有不完善之處，一支小型工程團隊隨著服務成長，不斷排除瓶頸。當架構仍在演進時，業務就已經產生了價值。它不需要先為未來每一個問題備妥完整答案，才能成功。

在自己的職涯中，我逐漸形成了一個簡單的信念：好的架構能與業務一同演進。

這並不代表我們應該停止閱讀論文，或停止向其他工程師學習。他們的經驗能幫助我們做出更好的決策。但研究別人的架構，並不能免除我們理解自身業務的責任。

只要一個六十分的方案能支撐今天的業務，並為明天的改善保留空間，我就樂於接受。比起一個耗時過長才能建成，或變更成本過高的所謂完美架構，我會選擇前者。

剩下的四十分，可能日後會變得必要。其中有些部分也許永遠都不重要。隨著業務發展，我們可能發現，從一開始就是以錯誤的需求來衡量完美。

實際運作的系統，能讓我們從真實情況中學習。我們可以看出使用者在哪裡遇到困難、成本在哪裡增加，以及哪些限制真正阻礙了業務。這些經驗有助於判斷下一筆投資該放在哪裡。

演進的能力不只是新增功能，也包括升級相依套件、移除不必要的元件、替換內部系統，或將一項職責交由外部服務承擔。

有時候，暫時性的系統就夠了。如果它能支撐今天的業務，而日後替換它的成本也可以負擔，那它可能已經盡到自己的職責。並不是每個系統都必須永遠存在。

如今，雲端平台與成熟的開源專案提供了許多企業過去必須自行打造的能力。這改變了架構的成本效益計算。

對販售基礎設施的公司來說，開發更好的基礎設施，可能就是業務本身。對另一家公司而言，同樣的投入則必須以它所促成的業務成果來證明其價值。

這筆帳從開發開始之前就要算起，並持續貫穿系統的一生。它涵蓋建置與測試、使用團隊的培訓、整合、維護、除錯、升級，以及最終的遷移或退役。伺服器費用的節省只是其中一部分。我們也必須考慮，這些人如果投入其他工作，本來能達成哪些成果。

在最佳化一個流程之前，我們應該先問：業務究竟還需不需要這個流程？

每一家大型公司，現在都還需要龐大的基礎設施部門嗎？我不這麼認為。部門的規模應該取決於業務需求、外部可取得的能力，以及公司能夠持續承擔的責任。

架構會演進，無法事先完整規劃。我們可以擬定未來三年、五年，甚至十年的計畫，但架構應該為因應業務變化保留空間。

當有人宣稱自己的架構能滿足未來十年的一切需求時，他其實就是在宣稱自己能預測未來。而如果你真能預測未來十年，肯定有比設計軟體架構更值得運用這份天賦的事。