[架構師的修練] #2, SLO - 如何確保服務水準?

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是服務水準（Service Level）？

• A簡: 服務水準是對使用者感知品質的量化描述，如回應時間、成功率等可監控目標。
• A詳: 服務水準是以使用者體驗為核心，對系統品質的量化描述。常見面向包含可用性、回應時間、成功率與吞吐量等。它不是抽象口號，而是可觀測、可驗證的目標，能被監控系統持續量測，並成為 DevOps 循環的基準。明確的服務水準讓團隊能以數據對齊期待，據以擬定部署、擴縮容與優化策略，逐步提升整體服務品質。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q5, B-Q6

A-Q2: 什麼是 SLA、SLO、SLI？三者差異是什麼？

• A簡: SLA是對客戶的合約，SLO是內部目標，SLI是量測指標；三者自外而內相互對應。
• A詳: SLA（Service Level Agreement）是對客戶的正式承諾與補償條款；SLO（Service Level Objective）是內部期望達成的明確目標，如「99% 請求小於300ms」；SLI（Service Level Indicator）是可量測的指標，如P99延遲值。實務上以SLI持續量測，對齊SLO，並據此評估是否能達成SLA，三者構成服務品質治理的骨架。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, B-Q6, B-Q15

A-Q3: 什麼是 SLO（服務水準目標）？為何重要？

• A簡: SLO是明確可量測的服務品質目標，驅動監控、告警與優化決策。
• A詳: SLO將品質期待具體化，例如「99% 請求小於300ms」或「驗證簡訊5秒內送達第三方」。明確的SLO能讓團隊在架構、成本與效能間做取捨，設計監控門檻、告警流程與擴縮容策略。沒有SLO，監控與調優會失焦，難以以數據導向提升服務，亦無法對外承諾可落地的SLA。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q6, B-Q15

A-Q4: 什麼是 SLI（服務水準指標）？如何選擇？

• A簡: SLI是量測服務品質的指標，如P99延遲、錯誤率；應貼近使用者體驗與SLO。
• A詳: SLI是可觀測的數據，如P50/P95/P99延遲、成功率、Queue length等，用來評估是否達到SLO。選擇SLI的原則是可量測、可驗證且能映射使用者體感，如延遲對互動服務至關重要。SLI應有限且關鍵，並設定綠/黃/紅燈門檻，以利值班判讀與自動化處置。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q6, D-Q7

A-Q5: SLA、SLO、SLI 的關係與對應流程是什麼？

• A簡: 以SLI量測，對齊SLO；達標後才能承諾SLA；異常則啟動DevOps循環。
• A詳: 流程為：定義SLO→設計並實作SLI→用SLI持續監控→評估是否穩定達標→對外訂定可履行的SLA。運行中若SLI偏離SLO，觸發告警與SOP，進入DevOps迭代：診斷→修復→回歸驗證→調整門檻與策略，最終以數據驅動服務品質改善。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q13, B-Q6

A-Q6: 為什麼時間與流量相關需求難以用規格表達？

• A簡: 時序與負載具變動性，需以可量測指標與壓測/真實流量驗證。
• A詳: 時間與流量受環境、依賴系統、資料分佈等影響，難用單一規格定義；且延遲分佈呈長尾，平均值易誤導。因此須以P95/P99等SLI描述，並以壓測與真實流量對標。設計上以「可量測」為先，逐步明確化做法，形成可驗證的SLO與SOP。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q15, D-Q7

A-Q7: 為何要「從開發第一天」就釐清 SLO？

• A簡: 早定SLO可導出SLI與探針設計，避免事後補強成本高且難驗證。
• A詳: SLO越早定義，越能驅動架構、程式與監控的合設計：在哪裡打點、如何量測、如何切分併行、如何降級與回退。晚期才補監控常受限於既有架構，指標不完整、無法追溯，導致難以診斷與驗證改善效果。設計即運維（DfX/Design for Operation）是落實服務品質的關鍵。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, C-Q1, C-Q9

A-Q8: 非同步系統與 FaaS 在 SLO 管理上的意義？

• A簡: 非同步解耦能穩定吞吐，但需以SLI觀測延遲與隊列長度以守SLO。
• A詳: 非同步（含FaaS）藉由隊列削峰填谷，使後端以穩定節奏處理。但這也帶來傳遞延遲與堆積風險，故需定義並量測關鍵SLI：入列到出列延遲、處理時長、隊列長度等。配合分流與優先序，才能在不失控成本下守住用戶體感SLO。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q1, B-Q9

A-Q9: 為何「先監控再擴容」比「直接擴容」更關鍵？

• A簡: 監控辨識瓶頸與優先級，才能把資源花在刀口上並避免副作用。
• A詳: 盲目擴容可能治標不治本，甚至把資源錯配到低價值任務。以SLI識別瓶頸（如B高+D高），再精準擴容或分流，能迅速止血且控制成本。同時監控能揭示次生瓶頸（如DB），避免局部最佳化拖累整體表現，讓改進有依據與邊界。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q4, D-Q6

A-Q10: 簡訊案例中的 A、B、C1 指標是什麼？

• A簡: A準備時間、B排隊等待、C1內部執行；三者合計對應SLO。
• A詳: A為前台接收到送入隊列的時間（1→2），B為訊息入列至被取出的等待（2→3），C1為後端取出至送達第三方的處理（3→4）。定義與量測這三段，使「A+B+C1≤SLO」可被驗證與告警，亦能為診斷提供定位線索（哪段超時）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, C-Q1, B-Q9

A-Q11: 什麼是 D（Queue Length）？為何要量？

• A簡: D是隊列長度，代表庫存壓力；用於辨識瓶頸與觸發背壓。
• A詳: D衡量等待處理的訊息數，是訊號最明確的「庫存」。D高多半意味瓶頸前堆積，需判斷加速消化或分流。D也支援預測延遲「延遲≈D/處理速率」，作為拉繩（Rope）對上游的背壓信號，啟用降級或暫停新請求，避免雪崩。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, C-Q4, D-Q1

A-Q12: 為什麼要按 SLO 分流不同類型任務？

• A簡: 分流將高優任務與一般任務隔離，精準擴容以守住關鍵SLO與成本。
• A詳: 將驗證簡訊與行銷簡訊拆為獨立隊列與工人池，可確保高優任務不受低優任務影響。資源只對關鍵線擴容，避免不必要成本。同時可分別設門檻、告警與回退策略，讓運維操作更精準，風險隔離更明確。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, C-Q3, D-Q3

A-Q13: DevOps 循環如何支撐 SLO 的落實？

• A簡: 以SLO為核心，監控→回饋→改進→驗證，持續提升服務品質。
• A詳: DevOps以數據驅動改善：定義SLO→埋設SLI→建立儀表板/告警→運行監控→異常觸發SOP→修復與驗證→調整門檻與設計。此循環將運維問題轉為研發待辦，讓品質提升可持續、可量化，並形成對外SLA的可履行承諾。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q18, D-Q10, A-Q5

A-Q14: 什麼是限制理論（TOC）的 Drum-Buffer-Rope？

• A簡: 鼓定速、緩衝保護瓶頸、繩子控上游，協調整體產能與流量。
• A詳: Drum是瓶頸步調，決定整體節奏；Buffer在瓶頸前後設緩衝，確保滿載且不被外部阻塞；Rope向上游發出背壓，避免過度投料造成庫存爆炸。映射到系統：瓶頸工人速率、隊列做緩衝、API/功能開關做背壓，共同維持穩定與效率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q10, D-Q6

A-Q15: 何謂「預測延遲」？為何關鍵？

• A簡: 以隊列長度與處理速率推算等待時間，用於早期告警與自動降級。
• A詳: 預測延遲=Queue Length/處理速率，可評估新請求何時被處理。當預測值超過用戶容忍或業務時效（如30秒），系統可提前發警與拉繩：暫緩入口、切換備援流程、或顯示稍後再試，避免無效工作佔用瓶頸，降低雪崩風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q4, D-Q5

A-Q16: SLO 與成本（COST）如何權衡？

• A簡: 以相對成本單位量測，建立SLO–COST曲線，尋找可接受交集。
• A詳: 透過「1core/2GB/1hr=1單位」等相對單位監控資源成本，建立不同SLO下成本曲線。與產品方對齊可接受SLO與預算區間，專注在交集內的技術優化（如Process Pool提升利用率），讓升級有數據依據、投資回報可解釋。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, C-Q9, D-Q4

A-Q17: 什麼是 Process Pool？如何支援 SLO 與成本？

• A簡: 以進程池提升VM利用率與隔離性，在守SLO前提下降低資源成本。
• A詳: Process Pool在單台VM上管理多個工作進程，動態配置、回收與隔離故障，提高CPU/記憶體使用率，同時避免單一Workload壟斷。對高優任務可保障資源配額，讓在不增加VM數的情況下，仍能提升整體吞吐與成本效率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, C-Q8, A-Q16

A-Q18: QoS/Rate Limiting 在服務水準治理扮演何角色？

• A簡: 限速抑制干擾與資源爭用，保護關鍵路徑SLO，避免局部最佳化失衡。
• A詳: 當共享資源（如DB、頻寬）成為瓶頸時，對非關鍵工作限速能釋放資源給關鍵流量，避免「交易後處理」壓垮「交易」。常見方法有令牌桶/漏斗演算法，搭配優先序與配額控制，實現全域最佳化而非單點加速。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, C-Q7, D-Q6

A-Q19: Software vs Service：為何SLO是服務的「規格」？

• A簡: 服務除功能外，必須承諾品質與時效；SLO即可驗證的服務規格。
• A詳: 軟體交付強功能完備；服務交付則包含運行品質、可用性與反應時間。SLO把抽象品質轉為可度量規格，驅動設計、監控、告警與回退機制。沒有SLO，SaaS便難以對客戶形成可履行承諾與一致體驗。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q13, D-Q10

A-Q20: Infra/Dev/Ops 在 SLO 上的責任分工？

• A簡: Infra降成本與平台能⼒、Dev落實指標與降級、Ops平衡SLO與成本運營。
• A詳: Infra（平台/架構）提升資源效率（如Process Pool、自動擴縮）；Dev（應用）實作探針、分流、背壓與fallback；Ops（維運）負責監控、告警、SOP與成本–SLO平衡。三方以共同SLI/SLO語言協作，才能在事件中快速決策與復原。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q14, D-Q10

Q&A 類別 B: 技術原理類

B-Q1: 非同步簡訊管線如何運作？關鍵節點有哪些？

• A簡: 從請求入列到工人出列處理並送第三方，四點打點量測A/B/C1。
• A詳: 原理說明：前端接收請求(1)→封包入列(2)→後端工人出列(3)→呼叫第三方完成(4)。流程：在(1)-(4)打點計時，計算A=2-1、B=3-2、C1=4-3，並上報監控。核心組件：API Gate、Message Queue、Worker、第三方SDK與監控Agent。此管線解耦吞吐與延遲，必須配合儀表化守SLO。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, C-Q1, B-Q4

B-Q2: 從請求到第三方送達的執行流程為何？

• A簡: 驗證請求→封裝入列→出列執行→重試與結果回傳→上報SLI。
• A詳: 流程：1)前端驗證與節流→2)建立訊息含追蹤ID入列→3)工人出列、反壓檢查→4)呼叫第三方API含超時/重試→5)結果記錄與回補→6)上報A/B/C1/D與狀態碼。核心組件：Idempotency、重試策略、追蹤Correlation與Metrics管道，確保可觀測與可恢復。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, C-Q3, D-Q9

B-Q3: 監控系統如何接收自定義指標？

• A簡: 以監控SDK或API上報Metrics/Events，定義維度與聚合方式。
• A詳: 原理：應用內嵌監控SDK（如App Insights、CloudWatch）、或呼叫HTTP/UDP API上報指標。流程：定義量測點→蒐集數值與標籤（租戶、任務類型、優先級）→批次上報→後台聚合（Sum/Avg/P95）→看板與告警。核心組件：Metrics Client、Exporter、Aggregator與Alert Engine。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q2, B-Q6

B-Q4: 如何從打點計算 A、B、C1？

• A簡: 在(1)-(4)記錄時間戳，分別相減得A、B、C1，上報為SLI。
• A詳: 原理：統一時間來源（單調時計/UTC），確保跨進程一致。流程：在入站、入列、出列、外呼完成記錄ticks；A=2-1、B=3-2、C1=4-3；並加上追蹤ID與任務型別維度上報。核心組件：時鐘抽象、Tracing中介、Metrics封裝與誤差校正。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, C-Q1, B-Q3

B-Q5: 如何用指標辨識瓶頸並對應 TOC？

• A簡: 觀測B與D；B高+D高多為瓶頸前堆積；以隊列為Buffer，調整Drum/Rope。
• A詳: 原理：TOC指出瓶頸前會現庫存。流程：同時監看B（等待）與D（長度）；B↑且D↑→瓶頸飽和；B↑D平→處理慢；據此採分流、擴容、限速。核心組件：SLI關聯分析、閾值策略、優先佇列與背壓通道，形成Drum-Buffer-Rope閉環。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, A-Q14, D-Q1

B-Q6: 如何設計SLO監控與紅黃綠燈門檻？

• A簡: 以P95/P99設SLO，分綠/黃/紅分段，綁定告警與SOP自動化。
• A詳: 原理：長尾分佈需用分位數。流程：選定分位與視窗→定義綠<目標×50%、黃介於50–66%、紅>66%等級→每檔觸發不同動作（通知/擴容/降級）。核心組件：分段閾值、告警聚合、抑制與值班排程，確保訊號可行動且不致疲勞。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, D-Q7, C-Q6

B-Q7: 為何要用分位數（P95/P99）而非平均？

• A簡: 平均隱藏長尾，分位數反映多數使用者體驗與SLO風險。
• A詳: 延遲常呈重尾，少數極慢請求會拖高平均卻掩蓋大多數使用者體感。P95/P99能更準確反映「幾乎所有人」的延遲，對守SLO與告警更敏感。設計時宜同時觀測平均、P95、P99，並依場景選擇目標。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q6, D-Q7

B-Q8: 如何以架構實踐「按SLO分流」？

• A簡: 以路由鍵/標籤分派到獨立隊列與工人池，分別擴容與門檻。
• A詳: 原理：隔離高優與一般流。流程：在入列前根據任務型別/時效標籤選擇Queue；為高優配置專屬工人與資源配額；設不同告警與擴縮策略。核心組件：路由器、優先佇列、工作池管理與配額管理，確保關鍵SLO不被干擾。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q3, D-Q3

B-Q9: 預測延遲公式與背後假設是什麼？

• A簡: 延遲≈D/速率；假設到達穩定且工人滿載，作為早期告警與背壓依據。
• A詳: 原理：Little’s Law近似，當系統穩態且處理速率接近穩定值時，平均等待時間≈排隊長度/處理速率。流程：持續估算速率（滑動視窗）與即時D，計算預測延遲；超門檻即觸發拉繩。核心組件：速率估計、滑窗、去噪與閾值策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, C-Q4, D-Q5

B-Q10: 「繩子」在系統中的機制如何設計？

• A簡: 以API/事件向上游回報壓力，驅動限流、排隊、功能切換與告知。
• A詳: 原理：將瓶頸壓力轉為控制信號。流程：監控計算壓力指標→生成背壓事件→前端/邊界代理接收→啟動降級（停新流、改備援、提示稍後）→恢復後回復正常。核心組件：健康訊號API、特性開關、閘道器策略與用戶通知。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q14, C-Q5, D-Q5

B-Q11: Rate Limiter 的原理與常見演算法？

• A簡: 令牌桶/漏斗限制速率與突發，保護下游瓶頸資源與SLO。
• A詳: 原理：令牌桶允許突發在總量上限內；漏斗平滑輸出速率。流程：為關鍵資源設每秒令牌生成率與桶容量；請求需消耗令牌，無令牌即排隊/拒絕/降級。核心組件：限流器狀態、併發控制、優先權與拒絕策略，維持全域品質。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q7, D-Q6

B-Q12: Process Pool 架構如何提升資源利用？

• A簡: 在單VM管理多進程，動態配額與隔離，提升吞吐且控成本。
• A詳: 原理：以監管進程啟停Workers，按壓力自動擴縮與重啟，並限制每類Workload資源配額。流程：壓力評估→調整進程數→健康探針與回收→隔離異常。核心組件：Supervisor、隔離與限額、健康檢查與自動修復，提高SLO與成本效率。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q17, C-Q8, A-Q16

B-Q13: 如何以相對單位建立成本模型？

• A簡: 用固定規格與開機時長換算「單位成本」，上報與看板化。
• A詳: 原理：將成本抽象為可監控的相對單位（如1core/2GB/1hr）。流程：統一實例規格→記錄進程啟停時長→換算為成本單位→聚合到任務/租戶→看板化比較。核心組件：資源標籤、啟停勾點、成本聚合器與SLO疊圖，支持決策。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q16, C-Q9, D-Q4

B-Q14: 如何設計事件SOP與診斷決策樹？

• A簡: 以A/B/C1/D對照表判斷情境，綁定對策與責任人與回報節點。
• A詳: 原理：將指標模式映射到處置方案。流程：蒐集常見情境（如B↑D↑）→定義對策（分流/擴容/限速）→綁定執行者與時限→回報與復盤。核心組件：Runbook、告警分級、指令化操作與演練，縮短MTTR並降低風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, D-Q3, A-Q20

B-Q15: 如何自 SLO 推倒 SLI 與打點設計？

• A簡: 由目標拆步驟，為每步定上限與探針，確保可量測與可告警。
• A詳: 原理：從「用戶何時算完成」逆推過程節點。流程：標定關鍵路徑→定義各步延遲/成功率上限→設置打點（時間戳、結果、維度）→對齊監控與看板→驗證信號完整性。核心組件：觀測設計準則、打點規約、SDK與稽核。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, C-Q1, B-Q3

B-Q16: 如何以路由與優先序管理多工人池？

• A簡: 以多隊列+權重分配+配額，保證高優先隊列最小帶寬與延遲。
• A詳: 原理：分級排程與配額管理。流程：高/中/低優隊列獨立→工人配額與權重→動態調整搶占→監控各隊列P99與D→觸發擴縮或限流。核心組件：Scheduler、配額器、優先佇列與觀測回路。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q12, C-Q3, B-Q11

B-Q17: 如何辨識隱性瓶頸（如資料庫）？

• A簡: 建立端到端追蹤與相關性分析，觀測下游資源飽和跡象。
• A詳: 原理：透過分散式追蹤關聯工作與下游耗時，並疊圖資源SLI。流程：收集Span與下游資源指標→關聯工作量與DB延遲/鎖等待→識別局部最佳化副作用。核心組件：Tracing、資源監控、關聯查詢與告警抑制策略。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q6, B-Q5, B-Q18

B-Q18: 如何把監控融入 DevOps 迭代？

• A簡: 以看板與告警驅動需求排程與驗收，改善以分位數驗證。
• A詳: 原理：以數據定義成功。流程：每次改動前定義預期幅度→部署後對比SLI→以看板追進展→未達標回滾或加碼→復盤更新SOP。核心組件：變更快照、SLI驗收門檻、告警閘與回滾自動化，形成閉環學習。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q13, D-Q10, C-Q6

B-Q19: 如何設計降級與回退保護SLO？

• A簡: 以功能開關切換替代路徑、延遲佇列或拒絕，保護關鍵流程。
• A詳: 原理：在壓力與故障時保全核心體驗。流程：定義降級矩陣（哪些功能可關）→觸發條件（SLI與背壓）→切換到備援（如改打電話驗證）→恢復時平滑回切。核心組件：Feature Toggle、策略引擎、用戶告知與審計。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q5, D-Q5, B-Q10

B-Q20: 如何避免「局部最佳化」傷害整體SLO？

• A簡: 引入全域約束（瓶頸與共享資源）與限速，做全局最優分配。
• A詳: 原理：全局瓶頸決定上限，局部加速會轉嫁壓力。流程：識別共享資源（DB/頻寬）→設定全域配額與隊列→對非關鍵工作限速→監控核心路徑P99→以數據調整配比。核心組件：全域Scheduler、配額與優先序、跨域儀表板。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q18, D-Q6, B-Q17

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何在(1)-(4)節點實作打點並上報A/B/C1？

• A簡: 於入站/入列/出列/完成記錄時間與追蹤ID，上報自定義Metrics。
• A詳: 步驟：1)建立TimeProvider與Tracing中介；2)在API(1)記t1與CorrelationId；3)入列前記t2上報A=t2-t1；4)工人出列記t3上報B=t3-t2；5)完成記t4上報C1=t4-t3。程式碼：以監控SDK TrackMetric(“A”,值,維度)上報。注意：統一時鐘、異常也上報、維度含任務型別。最佳實踐：封裝打點SDK避免遺漏。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, B-Q3, A-Q7

C-Q2: 如何建立 CloudWatch/App Insights 儀表板呈現SLI與燈號？

• A簡: 建立自訂指標命名空間與維度，配置P95/P99與綠黃紅區段與告警。
• A詳: 步驟：1)定義命名空間app.slo；2)上報A/B/C1/D含type=verify/marketing；3)建圖卡：P99(A+B+C1)、D、Received、Dequeue-Over-SLO；4)設閾值：綠/黃/紅；5)告警綁SNS/Slack。注意：時間窗與聚合一致。最佳實踐：建立共用看板模板跨服務複用。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, A-Q6, D-Q7

C-Q3: 如何在SQS/RabbitMQ實作按SLO分流與工人池？

• A簡: 以路由鍵將高優任務入高優佇列，配置專屬工人與擴縮規則。
• A詳: 步驟：RabbitMQ設Exchange與Queue：sms.verify、sms.marketing；綁routingKey=verify/marketing；SQS建立兩隊列；兩組工人分別消費。設定擴縮：高優以P99與D觸發擴容閾值更敏感。注意：隔離重試與死信。最佳實踐：以標籤記錄任務SLO等級便於統計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q16, A-Q12

C-Q4: 如何實作「預測延遲」API 供前端查詢？

• A簡: 以近窗速率與即時D估算延遲，返回秒數與建議動作。
• A詳: 步驟：1)維護滑窗速率X（msg/sec）；2)讀取隊列長度D；3)計算delay≈D/X；4)回傳JSON：{delay,level,advice}；5)緩存與限頻。程式：GET /queues/verify/predicted-delay。注意：處理X≈0與尖峰去噪。最佳實踐：同時回報置信度，供前端策略判斷。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, B-Q10, D-Q5

C-Q5: 如何以Feature Toggle實作驗證方式的自動降級？

• A簡: 以開關切換SMS→語音或排隊提示，觸發條件接軌預測延遲。
• A詳: 步驟：1)引入開關平台（如Unleash/Config）；2)定義toggle sms.verify.enabled；3)監控服務當delay>30s調關；4)前端依開關走語音驗證或顯示稍後再試；5)恢復時平滑回切。注意：版本對齊與回切檢查。最佳實踐：降級前後都要上報事件以追蹤影響面。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, B-Q19, D-Q5

C-Q6: 如何設定告警與SOP串接（Slack/SMS/On-call）？

• A簡: 以紅黃燈對應不同嚴重度，綁定通知通道與Runbook連結。
• A詳: 步驟：1)定義告警規則（P99>門檻、D升速率、Dequeue-Over-SLO>0）；2)Severity綁通道（黃→Slack，紅→On-call+SMS）；3)訊息攜帶Runbook與值班人；4)自動開票；5)演練。注意：降噪與抑制窗口。最佳實踐：事後自動產生Incident報告模板。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q14, D-Q7

C-Q7: 如何在Worker加入令牌桶Rate Limiter保護DB？

• A簡: 以每秒令牌生成與桶容量限制呼叫速率，超出則排隊或延後。
• A詳: 步驟：1)設定rate=R tokens/s、burst=B；2)每次DB操作需取1 token；3)無token則等待最多T毫秒，逾時丟回隊列或標記延後；4)指標上報限流次數。程式：Acquire(timeout)失敗→延後。注意：不同任務權重與優先權。最佳實踐：動態調整R依DB健康度。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, D-Q6, B-Q20

C-Q8: 如何部署Process Pool提升VM利用率？

• A簡: 以監管程式動態啟停多進程Worker，配置資源配額與健康檢查。
• A詳: 步驟：1)撰寫Supervisor管理Worker生命周期；2)為不同SLO級Worker設定CPU/記憶體配額；3)健康探針與自動重啟；4)依壓力調整進程數；5)上報每進程CPU/記憶體與處理速率。注意：避免過度擁塞與抖動。最佳實踐：灰度調整與回滾。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q12, A-Q17, A-Q16

C-Q9: 如何上報「相對成本單位」並看板化？

• A簡: 以進程啟停時長×規格換算單位成本，上報聚合至服務/租戶。
• A詳: 步驟：1)規範實例規格對應單位；2)在Worker啟停勾點記錄時長；3)換算單位成本並上報metrics(cost_units){service,tenant};4)儀表板疊圖SLO與成本；5)定期審視。注意：與雲計費對齊抽象。最佳實踐：配合配額管理形成成本護欄。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q13, A-Q16, D-Q4

C-Q10: 如何實作「TOC監控視圖」輔助決策？

• A簡: 同圖呈現D、B、工人速率與下游健康，標示Drum/Buffer/Rope。
• A詳: 步驟：1)建立看板聚合B/D/速率/DB延遲；2)標註瓶頸節點（Drum）與隊列（Buffer）；3)顯示背壓狀態（Rope開/關）；4)串接擴縮與降級按鈕；5)保存快照用於復盤。注意：同步時窗。最佳實踐：加入事件註記關聯變更。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q10, D-Q1

Q&A 類別 D: 問題解決類（10題）

D-Q1: 遇到SLO違反且B、D同時升高怎麼辦？

• A簡: 判定瓶頸飽和，先分流與精準擴容高優隊列，並檢查背壓是否生效。
• A詳: 症狀：P99飆高、B↑、D↑。原因：瓶頸滿載前堆積。解法：1)立即啟用分流，確保高優工人池；2)只對高優擴容；3)檢查Rope，限制入口與降級；4)觀測預測延遲回落。預防：設定保留配額與峰值策略，常態化演練背壓。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, C-Q3, B-Q10

D-Q2: B高但D正常，處理延遲如何診斷？

• A簡: 檢查C1與下游依賴；多為Worker慢或外部服務退化，需優化或降級。
• A詳: 症狀：等待時間高但隊列不長。原因：工人處理變慢、外部API阻塞、資源爭用。解法：1)觀測C1與外部服務P99；2)啟用重試/超時調整；3)對非關鍵工作限速；4)必要時降級。預防：第三方健康檢測與熔斷策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q11, D-Q9

D-Q3: Dequeue-Over-SLO 指標飆升代表什麼？如何處置？

• A簡: 出列即已超時；應立即拉繩、暫緩新流量，並只擴容高優池。
• A詳: 症狀：大量訊息出列時已超SLO。原因：在隊列等待過久。解法：1)啟用背壓停止入口；2)擴高優工人；3)跳過視為無效的過期工作；4)溝通用戶提示。預防：預測延遲告警、分流與最長等待TTL。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q9, C-Q4

D-Q4: 擴容有效但成本過高，如何平衡？

• A簡: 以相對成本單位看板，對刀口擴容並引入Process Pool與優化。
• A詳: 症狀：SLO守住但成本暴增。原因：粗放擴容、資源空轉。解法：1)分流後只擴高優；2)導入Process Pool提升利用率；3)設定成本護欄與告警；4)與產品對齊SLO–COST交集。預防：容量規劃與壓測曲線。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q13, C-Q8

D-Q5: 預測延遲>用戶容忍時怎麼辦？

• A簡: 觸發背壓與降級：暫停入口、切換替代方案、明確告知稍後再試。
• A詳: 症狀：delay估算超過門檻（如30秒）。原因：隊列過長或速率下降。解法：1)API回傳「稍後再試」或展示排隊；2)改語音驗證或離線流程；3)加速消化高優；4)記錄事件與影響。預防：提前告警與容量管理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, B-Q19, C-Q5

D-Q6: 交易後處理壓垮資料庫怎麼辦？

• A簡: 局部最佳化導致全局退化；加入限速、配額與優先序保護交易。
• A詳: 症狀：DB延遲上升、交易變慢；交易後處理吞吐異常高。原因：共享瓶頸資源遭挪用。解法：1)為後處理加Rate Limiter；2)設定DB配額與排程；3)必要時拆分DB或分區。預防：全域看板與配額治治理。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q17, B-Q20, C-Q7

D-Q7: 告警太吵如何調優門檻與策略？

• A簡: 用分位數與動態窗、抑制與關聯，保持可操作且避免疲勞。
• A詳: 症狀：頻繁誤報。原因：門檻過敏、無抑制、未關聯事件。解法：1)改用P95/P99；2)設抑制與聚合；3)與變更/部署關聯；4)按業務時段調整閾值。預防：定期告警健檢與回顧。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q18, C-Q6

D-Q8: 無法直接取得Queue Length時如何估算？

• A簡: 以到達/完成速率差積分估算，或用內部計數器近似。
• A詳: 症狀：MQ不提供D或權限受限。解法：1)以λin與λout差值積分估D；2)在應用側維護入列/出列計數；3)以采樣校正；4)評估誤差與信心區間。預防：爭取權限或改用支持的MQ。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q9, C-Q4, B-Q3

D-Q9: 第三方簡訊商變慢如何檢出並隔離？

• A簡: 監測外呼P99與錯誤率，設熔斷與備援供應商切換。
• A詳: 症狀：C1上升、外呼超時多。原因：第三方退化或故障。解法：1)觀測外部SLI；2)設熔斷與重試退避；3)切換備援供應商；4)降級至語音或通知稍後。預防：多供應商策略與健康檢測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q19, C-Q5

D-Q10: 如何避免相同事故再次發生？

• A簡: 做復盤與行動項，將SOP/監控/設計改動納入DevOps循環。
• A詳: 症狀：重複性事件。原因：缺乏復盤與制度化修正。解法：1)無責任復盤；2)形成行動項：新增SLI、調整門檻、改善分流/限流；3)納入迭代與驗收SLI；4)加強演練。預防：設變更審查與指標門檻。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q13, B-Q18, B-Q14

學習路徑索引

• 初學者：建議先學習 15 題
  • A-Q1: 什麼是服務水準（Service Level）？
  • A-Q2: 什麼是 SLA、SLO、SLI？三者差異是什麼？
  • A-Q3: 什麼是 SLO（服務水準目標）？為何重要？
  • A-Q4: 什麼是 SLI（服務水準指標）？如何選擇？
  • A-Q5: SLA、SLO、SLI 的關係與對應流程是什麼？
  • A-Q10: 簡訊案例中的 A、B、C1 指標是什麼？
  • A-Q11: 什麼是 D（Queue Length）？為何要量？
  • A-Q12: 為什麼要按 SLO 分流不同類型任務？
  • A-Q13: DevOps 循環如何支撐 SLO 的落實？
  • B-Q1: 非同步簡訊管線如何運作？關鍵節點有哪些？
  • B-Q4: 如何從打點計算 A、B、C1？
  • B-Q6: 如何設計SLO監控與紅黃綠燈門檻？
  • B-Q7: 為何要用分位數（P95/P99）而非平均？
  • C-Q1: 如何在(1)-(4)節點實作打點並上報A/B/C1？
  • D-Q3: Dequeue-Over-SLO 指標飆升代表什麼？如何處置？
• 中級者：建議學習 20 題
  • A-Q6: 為什麼時間與流量相關需求難以用規格表達？
  • A-Q7: 為何要「從開發第一天」就釐清 SLO？
  • A-Q8: 非同步系統與 FaaS 在 SLO 管理上的意義？
  • A-Q9: 為何「先監控再擴容」更關鍵？
  • A-Q14: 什麼是限制理論（TOC）的 Drum-Buffer-Rope？
  • A-Q15: 何謂「預測延遲」？為何關鍵？
  • B-Q2: 從請求到第三方送達的執行流程為何？
  • B-Q3: 監控系統如何接收自定義指標？
  • B-Q5: 如何用指標辨識瓶頸並對應 TOC？
  • B-Q8: 如何以架構實踐「按SLO分流」？
  • B-Q9: 預測延遲公式與背後假設是什麼？
  • B-Q10: 「繩子」在系統中的機制如何設計？
  • B-Q11: Rate Limiter 的原理與常見演算法？
  • B-Q15: 如何自 SLO 推倒 SLI 與打點設計？
  • B-Q18: 如何把監控融入 DevOps 迭代？
  • C-Q2: 如何建立儀表板呈現SLI與燈號？
  • C-Q3: 如何在MQ實作按SLO分流與工人池？
  • C-Q4: 如何實作「預測延遲」API 供前端查詢？
  • C-Q6: 如何設定告警與SOP串接？
  • D-Q1: 遇到SLO違反且B、D同時升高怎麼辦？
• 高級者：建議關注 15 題
  • A-Q16: SLO 與成本（COST）如何權衡？
  • A-Q17: 什麼是 Process Pool？如何支援 SLO 與成本？
  • A-Q18: QoS/Rate Limiting 在服務水準治理扮演何角色？
  • B-Q12: Process Pool 架構如何提升資源利用？
  • B-Q13: 如何以相對單位建立成本模型？
  • B-Q16: 如何以路由與優先序管理多工人池？
  • B-Q17: 如何辨識隱性瓶頸（如資料庫）？
  • B-Q19: 如何設計降級與回退保護SLO？
  • B-Q20: 如何避免「局部最佳化」傷害整體SLO？
  • C-Q5: 如何以Feature Toggle實作自動降級？
  • C-Q7: 如何加入令牌桶保護DB？
  • C-Q8: 如何部署Process Pool提升VM利用率？
  • C-Q9: 如何上報「相對成本單位」並看板化？
  • D-Q4: 擴容有效但成本過高，如何平衡？
  • D-Q6: 交易後處理壓垮資料庫怎麼辦？