sre: manage load finish auto-scaling

src/essay/web/tcp.md

@@ -152,15 +152,14 @@ TBD
 
 指標名稱都有前綴：`node_netstat_TcpExt_`。
 
-> [!Note]
->
-> 本列表示使用 Node Exporter 提供的指標。
->
-> 你可以透過以下指令來取得各個指標的上升幅度：
->
-> ```text
-> increase(label_replace({__name__=~"node_netstat_Tcp.*"}, "na", "$1", "__name__", "node_netstat_Tcp(.+)")[5m:1m])
-> ```
+!!! note "來源"
+    本列表示使用 Node Exporter 提供的指標。
+
+    你可以透過以下指令來取得各個指標的上升幅度：
+
+    ```text
+    increase(label_replace({__name__=~"node_netstat_Tcp.*"}, "na", "$1", "__name__", "node_netstat_Tcp(.+)")[5m:1m])
+    ```
 
 | 名稱 | 原理 | 說明 |
 | - | - | - |
@@ -437,9 +436,8 @@ sequenceDiagram
     Note right of Server: ⚠️Drop!
 ```
 
-> [!Note]
->
-> 初始化的 `SEQ` 是隨機產生的。
+!!! tip
+    初始化的 `SEQ` 是隨機產生的，避免被猜到，做出偽造封包的攻擊。
 
 SEQ 是一個 $2^32$ 的值，最大的值約為 43 億，換句話說一條連線如果傳送了 4GB 的資料，就會遇到溢位，然後就會丟棄該封包。
 不管這個連線是長連線還是短時間大量資料傳遞。
@@ -649,3 +647,17 @@ Socket 為包裝底層運作的 API，包括 Data Link Layer 和 Network Layer
 [RFC-7323](http://www.rfc-editor.org/info/rfc7323) - TCP Options: Window Scale, Timestamp
 
 之前有看到一個 RFC（忘記編號）說明棄用 TCP Timestamp，因為它佔用很多空間，故推薦其他做法，包括使用 TLS。
+
+[Backlog]: #backlog
+[Linger]: #linger
+[Defer Accept]: #defer-accept
+[Fast Retransmission]: #fast-retransmission
+[Zero Window]: #zero-window
+[Coalescing]: #coalescing
+[CORK]: #cork
+[Delayed ACK]: #delayed-ack
+[Selective ACK]: #selective-ack
+[SYN Cookies]: #syn-cookies
+[PAWS]: #paws
+[Forward RTO]: #forward-rto
+[Fast Open]: #fast-open

src/feedback/site-reliability-workbook/managing-load.md

@@ -5,7 +5,7 @@ tags: SRE-workbook
 # 負載管理
 
 通常一個大型服務的負載管理機制包含以下三種方式：
-負載平衡（load balancing）、負載削減（load shedding）和自動擴增（auto scaling）。
+負載平衡（load balancing）、負載削減（load shedding）和自動增減（auto scaling）。
 但是這些機制都需要同步彼此的狀態，否則很可能在某些時候造成錯誤設置，並破壞可用性。
 
 在千奇百怪的線上狀況中，本章節提供一些建議來遵循。
@@ -180,7 +180,32 @@ Pokémon GO 是一款由 Niantic 和寶可夢公司合作開發的擴增實境
 這件事讓 GFE 的效能評估中，更重視當後端緩慢時的處理狀況。
 而對 Pokémon GO 的開發者來說，他們使用調整了重傳的機制，以及更有經驗的處理如何應付高流量。
 
-## 自動增長
+## 自動增減
 
 透過自動增長機制，來增加服務的通量，避免高峰造成的緩慢。
-接著將來討論自動增長的最佳實踐、常見錯誤配置以及現階段的限制。
+
+以下是簡述自動增長的最佳實踐、常見錯誤配置以及現階段的限制：
+
+- 處裡異常節點：
+  避免把還沒啟動好、卡住的節點納入服務和算力統計，同時允許讓自動化機制重啟或恢復服務；
+- 有狀態請求的考量：
+  例如長連線、sticky session 等，透過應用層級去處理流量分配，
+  另外使用垂直擴張（單節點算力提高）時應避免浪費；
+- 閥值要保守：
+  避免輕易擴張和縮減，其中縮減的閥值要更保守，當服務負責處理外部進來的請求時，
+  應[預備更多的算力](https://sre.google/sre-book/service-best-practices/#capacity-planning-wPsEUPo)避免流量急升；
+- 限制增長和縮減的量；
+- 允許切換到手動增減：
+  確保值班的同仁可以手動增減節點數，同時該操作要直觀、簡單、快速且擁有充分的手冊指引；
+- 避免讓服務的依賴過載：
+  節點增加會讓其依賴負載增加，例如資料庫，應確保增加的量不會把依賴沖垮，所以，請嘗試暸解依賴的負載能力；
+- 避免區域間的不平衡：
+  多個區域可能因為量的不同，會有不同的節點數，應盡量平衡每個區域的節點數；
+
+最後，上面提的手段應該同時被考慮進去，也就是說，請嘗試用多種策略去管理負載。
+例如：
+
+- 節點群和群彼此有獨立的自動擴張性，且要有負載平衡在前端平衡彼此的流量。
+- 為了盡量滿足更多的使用者，緩慢的請求應優先被捨棄，例如來自地球另一端的請求。
+
+*負載平衡*、*負載削減* 和 *自動增減* 就是這其中需要拿捏、權衡的三大工具。