其實今天的很多系統都是 數據密集型 應用系統，也就是 數據量大、複雜、且速度快，

有別 10 幾年前的 計算密集型，CPU 時脈才是系統的瓶頸。

現在的數據密集型應用系統都包含了以下功能：

• 儲存資料 (database)
• 加速讀取昂貴操作的結果 (cache)
• 讓 user 用 keyword 或其他方式檢索資料 (search index)
• 寄送訊息到另一個 process，用非同步的方式做某些事 (streaming processing)
• 定期的處理大量已累積的資料 (batch processing)

數據工程師的工作就是選擇合適的工具把上面這些搭建起來。

數據系統

至於什麼是合適的工具呢？現今我們常用的工具並沒有一個非常明確的 分類，

例如你可以用 Elasticsearch 做你的 database，也可以用 Redis 做你的 message queue，

雖然我們直覺都不會這樣幹啦！但只要用的合理，符合等會講的 Reliable, Scalable, Maintainable 原則，又何嘗不可。

下圖為組合多種組件的數據系統架構圖：

個人認為這些是現在數據系統的基本架構，這裡可以有很多討論的細節，每一個區塊都能獨立成一個系統架構，但基本概念是一致的，有應用程式就有 DB，想要 Request 回覆更快就用 cache，數據工程師現在更需要有能力成為一個數據系統的架構師。

當你在建立數據系統時，我們必須確保 3 個主要原則：

Reliable (可靠的)

​ 系統應該只完成我們預期它會完成的事，就算發生錯誤也是如此。

Scalable (可擴充的)

​ 系統能支持未來成長的流量。

Maintainable (可維護的)

​ 系統能同時讓開發工程師或維運工程師正常使用，不會因為某些原因造成某方的生產力下降。

接下來的篇幅會針對這 3 個主要原則詳細說明。

Reliable (可靠的)

對系統來說，工作正確 是預期能完成下述幾項：

• 正確執行 user 預期的函式
• 能容忍 user 的小錯誤和軟體層級上能預想到的錯誤
• 對需求端的 use case 能有效率的執行，並產生可預期的資料
• user 有經過授權才能做事

莫非定律（Murphy's Law）：「凡是可能出錯的事就一定會出錯」

能應對錯誤的系統稱為 falut-toerant (容錯)，這裡要跟 failure 做區隔，我稱它為 系統掛點，

這種掛點是會讓你半夜需要爬起來處理的嚴重系統問題，

沒有能完美應對所有錯誤情況的系統， 所以合理的是想像出各種可能會發生的錯誤而提前應對，進而避免累積的錯誤導致系統掛點。

在 ETtoday 我們在測試系統時，也常用手動 kill process 的方式來觀察系統是否可靠，觀察 Servicce 是否會重啟或者Leader 有無被正常的選出來等等。

硬體錯誤

當你都在用雲端時，這件事對你是無感的，什麼硬碟壞軌、記憶體故障等等都不甘你的事。

但公司是私有雲時，這件事對軟體的可靠程度就很重要了，在建置系統時，最有效避免此錯誤的方式就是 redundant (冗餘) ，像硬碟的 RAID 設定就是如此，root 硬碟掛掉時，機器還是能正常運作，最棒的是準備 redundant 的機器，確保系統在修復期間是 zero downtime，服務不中斷。

軟體錯誤

上一點提到的硬體錯誤是屬於弱關連，一顆硬碟故障了不會造成另一顆硬碟也故障，

但軟體層面的錯誤關連性就比硬體錯誤強了，舉例來說：

• 某些不好的 input 會導致多個軟體掛掉，像 Leap second issues - June 30, 2012 會導致 Linux Kernal 發生 3 個可能的 issue。
• 某些執行中的 process 可能共用了系統資源，如 CPU, memory, 頻寬等等。
• A 軟體變慢導致同台機器的 B 軟體也變慢或回覆非預期的結果。
• 瀑布流系統掛點，一個小的錯誤可能會造成另一個軟體的錯誤，最終演變成災難。

避免方式就是把測試寫好、獨立執行資源、進程隔離、軟體掛掉自行重啟等等，另外也要做好機器與軟體的監控。

人為錯誤

事在人為，錯誤亦同。

好的系統應該要組合下述幾項：

• 盡可能的降低錯誤的機率。
• 有與生產環境相同的沙箱環境做測試、實驗。
• 能通過完整的測試，包含單元測試、整合測試、人工測試。
• 系統能簡單且快速從人為錯誤中恢復；例如能透過 DevOps 快速 rollback 前一版本、逐步釋出 (rollout) 新版本程式、有工具能重新計算舊的資料。
• 設置詳細且簡單的監控機制，諸如 performance 指標、錯誤率指標等等，監控機制能讓工程師們能及早因應系統錯誤做出反應。

系統沒有符合 Reliable 後面的東西都甭談了，有時候我們會因為成本或時間考量而犧牲一定的可靠性，

工程師需要培養 你在危機時刻依然會遵循的紀律原則，在這個情況下，恪遵紀律原則是避免陷入危機的最好途徑。

Scalble (可擴充的), Maintainable (可維護的) 就明天在談啦！