第一章節：學習要點

[at7211]

• 規劃一個 data system 的三要素：Reliability, Scalability, Maintainability

• 典型（typical） 响应时间 → 看中位數才是比較有效的理解用戶的 response time

• 响应时间的高百分位点（也称为 尾部延迟，即 tail latencies）非常重要，因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时是以 99.9 百分位点为准，即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户，也可以说是最有价值的客户 → 尋求最高價值客戶的方式

[kylemocode]

• 設計並構建了軟體系統的工程師是人類，維持系統執行的運維也是人類。即使他們懷有最大的善意，人類也是不可靠的。舉個例子，一項關於大型網際網路服務的研究發現，運維配置錯誤是導致服務中斷的首要原因，而硬體故障（伺服器或網路）僅導致了 10-25% 的服務中斷

• 可維護性由 「可操作性」、「簡單性」、「可演化性」組成，可操作性重點關注在運維，簡單性關注管理系統的複雜度，可演化性則是著重於擁抱系統的變化。

• 用於消除 額外複雜度 的最好工具之一是 抽象（abstraction）。一個好的抽象可以將大量實現細節隱藏在一個乾淨，簡單易懂的外觀下面。一個好的抽象也可以廣泛用於各類不同應用。比起重複造很多輪子，重用抽象不僅更有效率，而且有助於開發高質量的軟體。抽象元件的質量改進將使所有使用它的應用受益。

[nathan-tw]

• 可靠性: 人為的設計偏差容易是錯誤的主因。

设计并构建了软件系统的工程师是人类，维持系统运行的运维也是人类。即使他们怀有最大的善意，人类也是不可靠的。举个例子，一项关于大型互联网服务的研究发现，运维配置错误是导致服务中断的首要原因，而硬件故障（服务器或网络）仅导致了 10-25% 的服务中断

• 可伸縮性: 優秀的系統必須應付流量的變化。

系统今天能可靠运行，并不意味未来也能可靠运行。

• 可維護性: 維運的思維是希望細水長流，但開發的往往不是，這也導致lagacy code的出現。

不幸的是，许多从事软件系统行业的人不喜欢维护所谓的 遗留（legacy） 系统，—— 也许因为涉及修复其他人的错误、和过时的平台打交道，或者系统被迫使用于一些份外工作。每一个遗留系统都以自己的方式让人不爽，所以很难给出一个通用的建议来和它们打交道。

[samwu4166]

• 反直觉的是，在这类容错系统中，通过故意触发来 提高 故障率是有意义的

為了避免 fault 導致 system failure，因此在規劃系統程式的時候要去透過觸發 fault 來達到你設計的【Expected fault】

• 可伸缩性（Scalability） 是用来描述系统应对负载增长能力的术语。但是请注意，这不是贴在系统上的一维标签：说 “X 可伸缩” 或 “Y 不可伸缩” 是没有任何意义的。相反，讨论可伸缩性意味着考虑诸如 “如果系统以特定方式增长，有什么选项可以应对增长？” 和 “如何增加计算资源来处理额外的负载？” 等问题。

討論 Scalable 應該著重在 Problem-solution 的方式

• 对于 Hadoop 这样的批处理系统，通常关心的是 吞吐量（throughput），即每秒可以处理的记录数量，或者在特定规模数据集上运行作业的总时间 3。

在規劃類似 data pipeline 的時候，我們都會去預估這個 Topic 的預期 Throughput 會是多少 (可能 1GB/s)，再搭配這個規劃 HDD 要配置的最小數量

[samwu4166]

• 反直觉的是，在这类容错系统中，通过故意触发来 提高 故障率是有意义的

為了避免 fault 導致 system failure，因此在規劃系統程式的時候要去透過觸發 fault 來達到你設計的【Expected fault】

• 可伸缩性（Scalability） 是用来描述系统应对负载增长能力的术语。但是请注意，这不是贴在系统上的一维标签：说 “X 可伸缩” 或 “Y 不可伸缩” 是没有任何意义的。相反，讨论可伸缩性意味着考虑诸如 “如果系统以特定方式增长，有什么选项可以应对增长？” 和 “如何增加计算资源来处理额外的负载？” 等问题。

討論 Scalable 應該著重在 Problem-solution 的方式

• 对于 Hadoop 这样的批处理系统，通常关心的是 吞吐量（throughput），即每秒可以处理的记录数量，或者在特定规模数据集上运行作业的总时间 3。

在規劃類似 data pipeline 的時候，我們都會去預估這個 Topic 的預期 Throughput 會是多少 (可能 1GB/s)，再搭配這個規劃 HDD 要配置的最小數量

[JimmyFUFU]

• 可靠性
  允許從人為錯誤中簡單快速地恢復，以最大限度地減少失效情況帶來的影響。 例如，快速回滾配置變更
  開發功能時要想如果這段 code deploy 上去之後出錯了要如何最快速的恢復到上一版的狀態，除了 revert code、rollback image 以外，如果有寫 migration 更新資料，也要想是否需要先備份一版以防萬一

• 可伸縮性
  沒有一招鮮吃遍天的通用可伸縮架構
  現有能夠建立完善系統架構的工具很多，如何設計、建構最符合當下應用的系統架構也是學習的一環

• 可維護性
  可演化性：擁抱變化
  雖然有一個設計原則是說不要替未來的功能預設立場，去撰寫用不到的程式碼(YAGNI)，但我感覺這個設計原則和控制可演化性之間也常常需要討論斟酌，要考慮到程式的敏捷度，但也不能預設太多的立場．

[Parkerhiphop]

1. Reliable：比起 阻止錯誤（prevent error），通常更傾向於 容忍錯誤。
   • 透過故意引發故障來確保容錯機制不斷執行並接受考驗，從而提高故障自然發生時系統能正確處理的信心。
     • 如：在沒有警告的情況下隨機地殺死單個程序。
     • Netflix - Chaos Monkey
2. Scalable：以響應時間的高百分位點（尾部延遲）來作為衡量服務效能的標準：因為請求響應最慢的客戶往往也是資料最多的客戶，也可以說是最有價值的客戶。
   • 亞馬遜觀察到：響應時間增加 100 毫秒，銷售量就減少 1%
   • 另一些報告說：慢 1 秒鐘會讓客戶滿意度指標減少 16%
   • 而應對負載的方法為： Vertical & Horizental Scaling、系統則有 彈性 和 手動兩種方式
3. Maintainable：軟體的大部分開銷並不在最初的開發階段，而是在持續的維護階段。
   • 需大量使用抽象化的思維來減少複雜度，讓系統在之後易於修改和適應新的應用場景，也方便讓新加入的工程師好入手。

[kkshyu]

• 比起「阻止錯誤」，我們更傾向「容忍錯誤」
• 針對 corner case 進行自動化測試
• 可能會選擇犧牲可靠性降低開發成本，但要意識自己在做什麼
• 透過寫入時更新緩存，而非僅透過時間來失效緩存
• SLO 可設為 p50 < 500ms、p999 < 1s

[jxiu0129]

• Reliability
  • 人类也是不可靠的。举个例子，一项关于大型互联网服务的研究发现，运维配置错误是导致服务中断的首要原因，而硬件故障（服务器或网络）仅导致了 10-25% 的服务中断
  • 方法：
    • 精心设计的抽象、API 和管理后台
    • 解耦（decouple）、 沙箱（sandbox）
    • 彻底的测试
    • 允许从人为错误中简单快速地恢复
    • 配置详细和明确的监控，比如性能指标和错误率。
• Scalability
  • percentile
    • 如果想知道典型场景下用户需要等待多长时间，那么中位数是一个好的度量标准：一半用户请求的响应时间少于响应时间的中位数，另一半服务时间比中位数长。中位数也被称为第 50 百分位点，有时缩写为 p50。注意中位数是关于单个请求的；如果用户同时发出几个请求（在一个会话过程中，或者由于一个页面中包含了多个资源），则至少一个请求比中位数慢的概率远大于 50%。
    • 百分位点通常用于 服务级别目标（SLO, service level objectives） 和 服务级别协议（SLA, service level agreements），即定义服务预期性能和可用性的合同。 SLA 可能会声明，如果服务响应时间的中位数小于 200 毫秒，且 99.9 百分位点低于 1 秒，则认为服务工作正常（如果响应时间更长，就认为服务不达标）。这些指标为客户设定了期望值，并允许客户在 SLA 未达标的情况下要求退款。
• Maintainabilty
  • 可操作性（Operability）
  • 简单性（Simplicity）
  • 可演化性（evolvability）

[emily40830]

• 現今常見的大型系統以能夠處理高資料量的讀寫為重要標準，可從 Reliability , Scalability, Maintainability 三個面向做探討
• 可靠性 Reliability 強調的是系統故障發生時的可控與影響範圍是否在適當的範圍
  • 軟體層面可以優化的方向

  仔細考慮系統中的假設和互動；徹底的測試；程序隔離；允許程序崩潰並重啟；測量、監控並分析生產環境中的系統行為。如果系統能夠提供一些保證（例如在一個訊息佇列中，進入與發出的訊息數量相等），那麼系統就可以在執行時不斷自檢，並在出現 差異（discrepancy） 時報警

• 可伸縮性 Scalability 描述負載

增加負載引數並保持系統資源（CPU、記憶體、網路頻寬等）不變時，系統性能將受到什麼影響？
增加負載引數並希望保持效能不變時，需要增加多少系統資源？

[nissenyeh]

概念

• application 可以被分為 compute-intensive 和 data-intensive，但現代由於硬體已經很強， 應付巨量 compute 通常不會是系統主要問題，相對的是巨量的 data 存取管理會造成系統挑戰，也是本書主要探討的重點。
• 一個好的 data system （data-intensive application），可以透過 Reliable / Scalability / Maintainability 三個維度來被檢視

Reliable（可靠性）表示一個系統是否可以持續的正常運作

• 一個 Reliable可靠性的系統，應該是盡量少 failure 的（failure 的定義是「使用者無法獲得他期待的服務/結果」）
• 其中，fault 跟 failure 是不同的，我們不可能設計沒有 fault（缺陷，定義是「系統中偏離 spec ／ 設計的部分」）的系統，我們只可能盡量避免 fault 造成 failure（避免使用者「無法獲得他期待的服務/結果」）。
• 常見的會影響 Reliable 可靠性的 3 個缺陷或錯誤包含
  • Hardware fault 硬體缺陷：硬體是有一定的生命週期（例子：在一個有10k disk 的儲存空間中，平均一天就會有一個 disk 壞掉），最常應對策略就是增加硬體冗余性（redundency)，當硬體壞掉時，就讓其他補上，
  • Software Errors 軟體錯誤：跟硬體缺陷最大的差異是，硬體缺陷是隨機的，但軟體通常造成連鎖性的崩潰
  • Human Errors 人為錯誤： 根據統計，錯誤通常都是人為錯誤造成的

Scalability（可增長性）：表示一個系統可以應付增長

• 脫離脈絡去談系統 A 是 scalable or not 是沒有意義的，重點是「如果Ｘ增長時，我們可以怎麼應對...」
• scalable : 「面對更多 load 時，可以維持 performance」的能力
  • performance：
    • 對於反應速度，比起平均數，最好使用「中位數」，比較好反應多數人的狀況
    • 但是 tail latencies 也很重要，因為通常速度最慢的人，是擁有最多資料，也是最有價值的客戶
• 應對策略：
  • Scale up（垂直擴展）
  • Scale out （水平擴展）

Maintainability（可維護性）：表示一個系統，在多人的情境下仍然讓工程師保持一定的生產力

• Operability：日常好維運，好監測系統監康..等
• Simplicity：足夠簡單，其他開發者可以好理解、有效率的參與
• Evolvability：可疊代性，加功能上去是簡單的