為今天構建。為明天規劃。為失敗規劃。
另有 28 種語言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 5 個模組，共 7 個，屬於 Data Architect 課程的第一章像資料架構師一樣思考。每個模組都可以單獨閱讀。 上一篇：架構是權衡的藝術 · 下一篇：瞭解你的工具：九個問題
**本模組回答的問題：**如何在滿足今天需求的同時，為增長和失敗做好規劃？
架構中最容易犯的錯誤之一，是隻為擺在眼前的需求做設計。我們有一個專案、一份待辦清單和一些需求。我們構建出滿足它們的東西。它能用，我們宣佈勝利。六個月後，業務變了，或者資料增長了，或者另一個業務部門也想用它，或者我們收購了一家公司，或者有新系統需要整合，或者出了一個沒人預料到的故障。
這些都不該讓架構師感到意外。我們無法預測會發生的一切，但我們可以在設計時就知道總會發生些什麼。這就是為什麼我用三個視角來審視架構：
為今天構建。 為明天規劃。 為失敗規劃。
三個缺一不可。
為今天構建
Section titled “為今天構建 ”架構從我們實際面對的問題開始。這聽起來理所當然，但架構師可能犯一個與短視相反的錯誤：過度架構。萬一我們收購十二家公司、有十億客戶、擴充套件到 40 個國家、每個系統都需要即時整合呢？也許吧。但這些是真實的可能性，還是我們在憑空製造問題？架構不是構建我們能想像到的最複雜的系統，而是構建合適的系統。
所以從今天開始：業務需要什麼，實際的資料量、使用者數和事務量，資料多久變一次、要多快流轉，誰需要存取，資料從哪裡來、到哪裡去。最重要的是：**為什麼？**這些答案給了我們可以落到設計上的具體東西。
尋找隱含的需求
Section titled “尋找隱含的需求 ”別人交給你的需求，不一定是你的全部需求。幾乎總存在隱含的需求。
業務方說：「我們需要把客戶資料放進 Salesforce。」好的。那麼就得有人擁有這些資料，並決定它必須多新。我們需要知道源系統宕機時會怎樣，同步失敗時我們怎麼發現，Salesforce 和源系統不一致時以哪邊為準。我們需要一個保留期限、一個存取模型、一個關於敏感欄位的決定，以及一種糾正壞資料的方法。
這些都不在使用者故事裡，但它們仍然都是架構。成為架構師的很大一部分，就是學會識別那些還沒被問出來的問題。
瞭解你的數字
Section titled “瞭解你的數字 ”我一直督促架構師去量化。不要告訴我資料很多，告訴我有多少。一萬、一千萬、一億、十億？這是截然不同的架構。不要告訴我整合執行得很頻繁：每小時一次、每分鐘一次，還是每秒一千次？不要告訴我我們增長得很快。有多快？
在沒有更好的數字時，我的基準是每年增長 30%。這不是預測，而是一種倒逼手段。如果有人告訴我今天有 1,000 萬條記錄，我不希望討論停在 1,000 萬。按每年 30% 計算，明年大約 1,300 萬，後年 1,700 萬，再下一年大約 2,200 萬。現在我們來談設計。如果業務方告訴我 30% 太離譜，很好：給我真實的數字。重點是讓增長成為架構討論的一部分。
我把這叫作 Steve 的「零的個數」（Steve’s Number of Zeros）。多一個零就可能徹底改變你的架構。一萬、十萬、一百萬、一千萬、一億：功能沒變，需求也許也沒變，但架構可能會變。
還記得模組 1 裡的預約嗎？我們給它配上真實的數字。超過 1,200 個網點，每個網點每天 100 個預約，每週營業六天，一年大約 305 天。第一年就超過 3,600 萬個預約。每次到店產生兩條記錄，所以超過 7,300 萬條記錄。再保留五年曆史，每年增長 30%，就超過 6.5 億條記錄了。同樣的功能，同樣的需求。多了幾個零，就是截然不同的架構。
為明天規劃
Section titled “為明天規劃 ”理解了今天，我就會往前看：哪些東西有合理的可能會改變？資料量是其中一部分，但明天不只是更多，也可能意味著不同：更多的產品、業務部門和國家；不同的隱私要求；新的渠道和整合；一次合併或收購；新的主資料策略或分析平台；一個消費原本只為人類設計的資訊的 AI 代理程式。
這就是為什麼我如此在意架構能否通過新增而不是不斷修改來成長。如果業務增加了一個產品，模型能容納嗎？如果另一個系統需要這些資料，我們能幹淨地開放出去嗎？如果資料量猛增，我們有路可走嗎？如果業務結構變了，我們會不會不得不把資料模型拆掉重來？我們不是要完美地預測未來，而是要避免把自己逼進死角。
不要今天就構建明天
Section titled “不要今天就構建明天 ”這裡需要平衡。為明天規劃，不等於今天就構建明天的系統。如果我們現在有 10 萬條記錄，五年後可能有 1 億條，這並不意味著現在就要構建 1 億條記錄的架構。那可能帶來我們暫時還不需要的成本和複雜度。
我想得到回答的問題是：今天的架構能否演進成明天的架構？如果我們能從簡單開始，同時有一條清晰的前進路線，這往往比提前好幾年支付複雜度成本要好。危險不在於從小處起步，而在於起步的地方無路可走。
為失敗規劃
Section titled “為失敗規劃 ”現在說說沒人喜歡談的部分：東西會出故障。我從沒設計過這樣一個系統：每個元件永遠可用，每個整合都成功，每個使用者都輸入完美的資料，每個外部系統的行為都和文件寫的一模一樣。所以不要去設計那樣的系統。
問一問什麼可能出故障，再問一問出故障時會發生什麼。一個整合超時。一個 API 拒絕了請求。一次夜間載入處理 80 萬條記錄，其中 20 萬條失敗。一個源系統宕機。一個使用者輸入了無效資料。一個外部識別符號出現了兩次。一個上游系統改了某個值的格式卻沒改欄位名。一個流程在一個系統裡成功，在另一個系統裡失敗。這些不是罕見的邊緣情況，這就是生產環境的樣子。
部分成功仍然是你需要弄清楚的失敗
Section titled “部分成功仍然是你需要弄清楚的失敗 ”部分失敗在資料架構中尤其危險。想像一下搬運一百萬條記錄，流程報告說已經完成。很好。但到達的是一百萬條，還是 999,997 條？少了的是哪三條？也許有 20 萬條失敗了，有些被建立了兩次，或者全部到達了但有些欄位轉換失敗。
「作業已完成」不等於資料是正確的。資料架構師會考慮對賬：我們怎麼知道本該發生什麼、實際發生了什麼，以及兩者的差異？我們又該怎麼處理？
系統變複雜時，我是這樣做的。記錄從 A 到 B，從左到右。然後 B 回傳一些東西：對它收到並儲存的每一條記錄發一個確認。現在 A 就可以把發出去的和收到確認的進行比較。如果每條記錄都有確認，這次執行就成功了。如果缺了任何確認，那就是沒成功，不管作業狀態怎麼說，而且我們確切知道要去追哪些記錄：重試它們，轉給人處理，或者發出告警。
優雅地失敗
Section titled “優雅地失敗 ”出故障時，我想知道系統接下來做什麼：會不會重試，是不是自動重試；同一筆事務被處理兩次會怎樣；失敗的記錄去了哪裡，好的記錄能否繞過壞記錄繼續流動；誰會收到告警，帶著什麼資訊，他們如何重放這次失敗；使用者如何得知出了問題。
最重要的是：**我們能否在不讓問題變得更糟的情況下恢復？**一個會製造重複資料的重試策略，算不上什麼恢復策略。好的架構假定會失敗，並給我們留一條回來的路。
監控重要的東西
Section titled “監控重要的東西 ”沒有監控的失敗規劃算不上真正的規劃。如果一個整合在凌晨 2 點失敗，直到三天後客戶打來電話才有人發現，那我們並沒有運維架構。我們只有希望。
決定哪些東西需要可觀測：流程運行了嗎，花了多長時間，處理了多少條記錄，多少成功、多少失敗？資料量是否突然和平常不一樣？積壓是否在增長，錯誤是否在增加？架構並不在部署成功時結束。明天得有人運維這個系統，而這也是設計的一部分。
朝三個方向思考
Section titled “朝三個方向思考 ”在本課程的其餘部分裡，持續運用這三個視角。設計資料模型時：今天能用嗎，明天能成長嗎，資料錯誤或不完整時會怎樣？設計整合時：它能搬運今天的資料嗎，能應對明天的資料量和系統嗎，一端宕機時會怎樣？面對大數據量時：今天有多少，數字往哪裡走，一次大型操作只部分成功時我們如何恢復？
技術每章都在變，問題不變。
架構存在於時間之中
Section titled “架構存在於時間之中 ”開發人員有時可以看著一項需求問：「這能用嗎？」架構師必須問得更多：它今天能用嗎，明天還能用嗎，當它完全不能用時會怎樣？這三個問題把我們從實現帶進了系統的整個生命。
你不會預測到每一項未來的需求，也不會阻止每一次失敗。那不是目標。目標是構建一個與我們今天所知相稱的東西，給明天留出路，並在現實不配合時有一個計劃。
**為今天構建。為明天規劃。為失敗規劃。**我們會一次又一次地使用這三個視角。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 真實的資料量和增長是多少，哪些數字會改變設計。
- 業務方還沒說出口的隱含需求有哪些。
- 今天的設計如何演進成明天的設計，而不是今天就構建明天的系統。
- 出故障時會發生什麼：恢復、對賬和監控。