"Devops"
- 把遠端 agent 工作機鋪成一條路：個人尺度的 paved road
要從零架一台遠端 agent 工作機、卻面對選型 / 連線 / 認證 / 無人值守散在多篇不知照什麼順序走、或想把個人 infra 用一條可重現的路收斂決策時回來讀
- Health check endpoint 設計
設計服務的健康檢查端點時，判斷什麼回應算健康、check 要探到多深、依賴要不要一起檢查時回來讀
- Stateless 設計原則
要把服務改成能水平擴展的無狀態設計時，釐清什麼算「本機狀態」、哪些常見寫法會破壞無狀態、隱式狀態怎麼抓、以及定時 job 這種無狀態例外怎麼處理
- 反向代理的職責
釐清反向代理在單一入口後面承擔哪些職責、TLS 終止與路由怎麼設計、以及一條請求路徑上的 timeout 為什麼要由外到內遞減時回來讀
- 流量模型建立
要把「這個服務會收到什麼樣的流量」量化成容量規劃的輸入時，釐清該量哪幾個維度、峰均比為什麼是最關鍵的單一指標、以及怎麼從 production log 抽出可信的模型
- 計費模式理解
看懂雲端帳單怎麼生成時，先認清收費的維度、on-demand/reserved/savings plan/spot 的承諾差異、以及 egress 這類最常被忽略的隱藏成本
- 單點故障盤點
要系統性找出哪些元件掛了整個系統就跟著掛時，用 pre-mortem 反推失敗路徑、依賴 budget 算可用性上限、以及按 blast radius 排序缺口
- 突發流量的分類
可預期 vs 不可預期的突發流量 — 不同來源、持續時間和倍率決定不同的應對策略
- 背壓機制
下游處理慢時上游怎麼減速 — 有限 buffer + 回壓訊號的設計、和 rate limit 的區別
- Liveness 與 Readiness
分不清該用哪種探針、或探針失敗後平台重啟了不該重啟的服務時，回來釐清 liveness、readiness、startup 三種探針各自宣告什麼、失敗後平台做什麼
- Right-sizing
把配置規格調到貼近實際用量時，怎麼找出過度配置的資源、downsizing 不能砍過膝點、以及機型世代與 reserved 過剩的回收
- Session 處理
多實例下要決定用戶登入狀態怎麼放時，比較 sticky session、外部 session store、無狀態 token 三種途徑，以及剛寫完就要讀到的 session 一致性怎麼保證
- 冗餘設計模式
在 active-passive、active-active、multi-region 之間選冗餘模式時，用資料同步方式與 standby 是否服務流量來區分，並知道冗餘不等於備份
- 負載分散演算法
在 round-robin、least-connections、IP hash、consistent hash 之間選負載分散演算法時，用請求成本是否均勻、實例是否同質、需不需要親和性當判準
- 峰值估算
要估一個服務的峰值該準備多少時，先分清峰值屬於哪一種形狀、再用歷史倍率階梯與安全係數推算，並知道安全係數的數學根據在飽和曲線
- Rate Limiting
主動限制每個來源的請求速率 — per-client vs global、token bucket vs sliding window、優先級豁免
- 降級策略
系統超載時犧牲什麼保住什麼 — 動態取樣、事件優先級、功能降級、聚合前移四種策略
- Failover 機制
設計單點掛掉自動切到替代路徑的機制時，釐清觸發靠探活、故障域要先劃定、恢復順序的循環等待風險、以及 rollback 與 roll-forward 怎麼選
- nginx 實務配置
用 nginx 當反向代理配 upstream、負載分散方法、健康檢查與 timeout 時，特別是要知道開源版的主動健康檢查限制與 proxy header 陷阱時回來讀
- Shared storage 選型
把外置的狀態放進共享儲存時，按存取型態與狀態性質選 DB、KV、物件儲存，並處理多實例共享一個 DB 帶來的讀路徑與連線瓶頸
- systemd watchdog 與自動重啟
在單機 systemd 上做服務自動恢復時，釐清 watchdog 主動報活與 restart policy 被動拉起是兩套機制、以及為什麼要先重啟幾次才放棄
- 成本監控與告警
要讓雲端帳單不失控時，靠歸因把每筆花費追到擁有者、用異常告警抓突增、以及選 showback 或 chargeback 讓成本有人負責
- 壓力測試工具與方法
要用壓測驗證容量規劃時，釐清壓測到底在找什麼、k6 與 wrk 各自的定位、怎麼讀壓測輸出的延遲分布，以及讓結果失真的幾個反模式
- Queue 緩衝
在 ingestion 和 processing 之間加 message queue 做 burst 緩衝 — Kafka / NATS / Redis Streams 的選型和引入條件
- 熔斷器
依賴服務失敗時怎麼快速失敗而非拖慢自己 — 三狀態模型（closed → open → half-open）和熔斷判斷條件
- Disaster recovery 策略
設計災難復原時，先確認恢復路徑走得通再談 RTO/RPO、用 restore drill 把估值變量值、以及知道恢復不是切回流量就結束
- Process supervisor 選型
在 systemd、supervisord、Docker restart policy、Kubernetes 之間選服務監管方式時，用平台能不能分開表達 startup、readiness、liveness、drain 當判準
- 健康檢查路由設計
設計負載平衡的健康檢查時，釐清被動與主動探測的差別、interval 與 threshold 怎麼定出兩個時間窗口、以及為什麼 LB 顯示 healthy 不等於服務可服務
- 規模拐點判斷
判斷什麼訊號代表該擴容、什麼代表可縮容、以及該往垂直還水平擴時，用飽和曲線的三段區間、膝點的早期訊號與 ramp-up 方法回來讀
- 開發環境成本控制
壓非 production 環境的隱形浪費時，用排程關機、用完即拆的 ephemeral 環境、CI 跑 spot、以及 per-team 成本上限
- 擴展的觸發與縮回
設計自動擴縮時，釐清擴展前要先窮盡哪些低成本手段、觸發訊號怎麼分層、以及縮回為什麼比擴容難、要先 drain 才能縮
- Bulkhead 隔離
不同工作負載的資源池隔離 — 一個功能過載不拖垮其他功能的隔艙設計
- 規模分級應對表
自用級 → 中型 → 大型 → 商業網站級的四級應對方案 — 每級的觸發條件、架構組成和成本
- Graceful shutdown
設計服務收到停止信號後的收束流程時，釐清 SIGTERM 到 SIGKILL 的 grace period、退場的固定順序、以及不同 workload 的 drain 窗口要留多長
- LB 是水平擴展的前提
想靠加實例分攤流量卻發現擴不動時，釐清水平擴展的兩個前提——流量要分得進新實例（LB）、任何實例要能接任何請求（無狀態）
- 成本模型
把容量規劃的資源翻成錢時，釐清 on-demand、reserved、spot 三種計費模式的取捨、怎麼算單位請求成本、以及過度與不足配置各自的經濟代價
- 自架 vs 雲端的成本交叉點
判斷該自架還是用雲端/商業方案時，看兩條成本曲線的交叉點、部署光譜的漸進選項、以及人力與 lock-in 這些不在帳單上的成本
- 垂直與水平擴展的判斷
決定該加 CPU 還是加實例時，用「這個元件能不能做成無狀態」當判斷樞紐，並知道有狀態的節點該用垂直撐、讀路徑用副本擴、撐不住才分片
- 高可用的成本
判斷高可用值不值得時，用停機的商業代價衡量冗餘的 2x 成本、按可用性等級階梯評估投資、以及知道沒驗證的冗餘等於白付
- 容器化資源設計
把容量規劃落到容器上時，怎麼定 memory 與 CPU 限制不觸發 OOMKill 或 throttle、以及 overlay filesystem 對高頻寫入的 I/O 影響
- DevOps Dashboard 設計
Collector 和 SDK 是否健康 — 日常監控的服務狀態卡、吞吐量曲線、儲存用量，以及告警觸發後的排障視圖
- 持續交付與交付效能
想用證據而非經驗談判斷工程做法有沒有效、該追哪些交付指標時，依證據強度分層的選讀
- Golden Path / paved road
要判斷該不該為一套重複性的 setup 鋪一條預設路徑、或分辨組織尺度的 developer portal 跟個人尺度的 repo 加腳本加路標哪個適用時回來讀