"Capacity-Planning"
- 流量模型建立
要把「這個服務會收到什麼樣的流量」量化成容量規劃的輸入時，釐清該量哪幾個維度、峰均比為什麼是最關鍵的單一指標、以及怎麼從 production log 抽出可信的模型
- 峰值估算
要估一個服務的峰值該準備多少時，先分清峰值屬於哪一種形狀、再用歷史倍率階梯與安全係數推算，並知道安全係數的數學根據在飽和曲線
- 壓力測試工具與方法
要用壓測驗證容量規劃時，釐清壓測到底在找什麼、k6 與 wrk 各自的定位、怎麼讀壓測輸出的延遲分布，以及讓結果失真的幾個反模式
- 規模拐點判斷
判斷什麼訊號代表該擴容、什麼代表可縮容、以及該往垂直還水平擴時，用飽和曲線的三段區間、膝點的早期訊號與 ramp-up 方法回來讀
- 成本模型
把容量規劃的資源翻成錢時，釐清 on-demand、reserved、spot 三種計費模式的取捨、怎麼算單位請求成本、以及過度與不足配置各自的經濟代價
- 預知的大流量要加多大、編多少預算：從業務預估到擴容規格與費用區間的換算鏈、給決策者與會計的數字，以及每次活動之後的校準
行銷活動、檔期這類事先知道的大流量，容量規劃怎麼從業務預估換算成峰值請求量、各層要開幾台與擴容的計費時數，再換算成費用區間；三點估計怎麼帶著預估的誤差，給決策者的選項要附規格、費用、不足時的後果與回退方式，給會計的預算要對齊增量與付款時點，以及每次活動之後校準換算係數、沒有歷史資料時怎麼起步
- 容器化資源設計
把容量規劃落到容器上時，怎麼定 memory 與 CPU 限制不觸發 OOMKill 或 throttle、以及 overlay filesystem 對高頻寫入的 I/O 影響
- 共用主機的資源競爭：容量估算、故障範圍、隔離層級與監控的位置
多個服務、資料庫與監控放在同一台主機（或同一台實體機上的多台虛擬機）時，資源競爭在容量估算、故障範圍、隔離的做法與監控的位置上各自要考慮什麼：共用發生在哪些層、量到的數字什麼時候能互相比較、哪些服務適合放在一起、從同機加限制到專用實體機的隔離層級與各層的觸發條件
- Cosmos DB RU/s 成本模型 + 容量規劃：RU 思維、payload、index、provisioned vs autoscale vs serverless
從 CPU+IOPS 思維轉到 RU 思維的學習曲線、依負載形狀選容量模式、payload + index policy 對 RU 的影響、autoscale reactive 限制 — 從 ASOS Black Friday + Minecraft Earth 1M RU/s 壓測切入
- Noisy Neighbor（共用資源的鄰居干擾）
服務沒有改動、自己的用量也不高卻整體變慢，或者同一台主機、同一台實體機上的其他工作負載一忙就跟著慢時，查共用資源的競爭從哪裡來、為什麼服務自己的監控看不到，以及隔離由淺到深有哪些做法
- Load Average（負載平均）
看到 uptime 或 node_load1 的數字、要判斷主機是不是在排隊時，查 load average 算的是什麼、除以核心數怎麼讀、Linux 為什麼把等磁碟的行程也算進去，以及在虛擬機與容器裡量到的值代表誰
- CPU Steal Time（被虛擬化層拿走的 CPU 時間）
雲端虛擬機的服務沒有改動、CPU 用量也不高卻變慢時，查 steal time 記的是什麼、怎麼從 node_exporter 算出比例、什麼環境量不到它，以及升高時的處置
- cgroup（控制群組）
設定容器的 CPU 與記憶體上限、讀 cAdvisor 的指標、或查容器為什麼被暫停與結束時，查 cgroup 是什麼、v1 與 v2 的差別，以及 Docker 與 Kubernetes 的參數各自對應到它的哪個控制檔