diff --git a/src/feedback/site-reliability-workbook/nalsd.md b/src/feedback/site-reliability-workbook/nalsd.md index 046c1517..571e8191 100644 --- a/src/feedback/site-reliability-workbook/nalsd.md +++ b/src/feedback/site-reliability-workbook/nalsd.md @@ -4,7 +4,8 @@ tags: SRE-workbook # 非抽象大型系統設計 -非抽象大型系統設計的目的在於讓開發者設計系統架構時，有個依據建立穩健而又高擴充的系統。 +非抽象大型系統設計（Non Abstract Large System Design, NALSD）的目的在於讓開發者設計系統架構時， +有個依據建立穩健而又高擴充的系統。 本文先透過定義問題，收集需求並反覆審視、循序改善架構的設計，最終得到一個可靠的系統設計解方。 目標是讓開發者能設計出一個在初期便擁有高穩健性且同時擁有未來調整的環境， @@ -19,10 +20,10 @@ tags: SRE-workbook 思考系統的擴充性和可能的瓶頸，並專注在這些點上。 在接下來的練習中，每一次設計的迭代，都可以反覆問自己這四個問題： -- 這個設計可能嗎？假設不去管資源議題，這個設計可以滿足需求嗎？ -- 有沒有更好的方法？可以讓他更快、更輕便、更有效率嗎？ -- 這方法可以在有限的設備數量、時間和金錢內達成嗎？ -- 這個架構允許降能嗎？當某組建壞掉會發生什麼事？當資料中心壞掉會發生什麼事？ +- **這個設計可能嗎？**假設不去管資源議題，這個設計可以滿足需求嗎？ +- **有沒有更好的方法？**可以讓他更快、更輕便、更有效率嗎？ +- **這方法可以在有限的設備數量、時間和金錢內達成嗎？** +- **這個架構允許降能嗎？**當某組建壞掉會發生什麼事？當資料中心壞掉會發生什麼事？ !!! success "練習的目的" 所有的系統最終都要實際跑在真實的資料中心和真實的設備上， @@ -30,15 +31,10 @@ tags: SRE-workbook 聽起來很瑣碎，但是不去練習和規劃，當我們實際上線時，可能會付出更慘痛的代價。 練習中的假設和推估會比最終實際結果重要。 - 早期的假設會很大程度影響最終的成果，但是在非抽象大型系統設計中， + 早期的假設會很大程度影響最終的成果，但是在 NALSD 中， 我們並不是要練習出完美的假設，而是在多個**不完美但是合理的假設**中導出一個更好被詮釋的結果 -## 練習一：AdWords - -AdWords 是 Google 一項產品，用來在使用者透過 Google 搜尋時，推出純文字的廣告。 -這次練習，是要設計出一個系統，可以觀測並回報正確的 *click-through rate* -（CTR，*使用者點擊廣告次數* 除以 *廣告推播數*）。 -搜尋系統的日誌會紀錄每次搜尋有放哪些廣告，而廣告被點擊的紀錄則是放在廣告系統的日誌中。 +## 練習流程 開始前，先簡述一下流程。 我們將使用反覆迭代的方式去設計系統，每次迭代都會定義出相關的設計並找出它的優勢和弱點。 @@ -57,3 +53,30 @@ AdWords 是 Google 一項產品，用來在使用者透過 Google 搜尋時， 雖然這裡列出順序，但實際練習時這些問題可能是反覆詰問的。 例如在初始階段，我們可能就會先考慮它的可擴充性。 如果這個設計在後面的問題無法得到好的回答，我們就會修正或替換某個組件，接著重頭開始。 + +## 練習：AdWords + +AdWords 是 Google 一項產品，用來在使用者透過 Google 搜尋時，推出純文字的廣告。 +這次練習，是要設計出一個系統，可以觀測並回報正確的 *click-through rate* +（CTR，*使用者點擊廣告次數* 除以 *廣告推播數*）。 +搜尋系統的日誌會紀錄每次搜尋有放哪些廣告，而廣告被點擊的紀錄則是放在廣告系統的日誌中。 + +### 定義需求的 SLO + +### 評估需求的資源 + +### 設計可行架構 + +### 延伸架構去滿足 SLO + +## 總結 + +NALSD 是一個設計系統時反覆迭代的過程，首先把架構拆成對應的邏輯元件，並想像其置入線上環境的資源需求。 +在這之中 SLO 的訂定變得尤為重要，因為 SLO 會驅動架構設計的進化，並在設計過程中不會迷航。 + +之所以說反覆迭代，就是在設計過程中每一次結束都要反覆問自己還能更好嗎？ +讓設計者除了能依據 SLO 這個準繩之外，還能透過前一次的架構或前幾次的架構，最終產出更好的架構。 + +根據 Google 的經驗，**把抽象的需求轉化成實際的資源**， +例如 CPU、記憶體、Network throughput 等等， +對於架構最終的穩定性非常重要。