現有系統的營運卓越改進

SAP-C02 的卓越營運改善（operational excellence improvement）是一項診斷技能，而非全新架構設計技能。考試預設工作負載已經存在，而且通常有一段痛苦的營運歷史——每月一次中斷、凌晨兩點用 SSH 手動套用修補程式、對剛才發生的故障毫無能見度、部署時把舊版本的 artifact 直接覆蓋新版本來「回滾」。身為 Professional 等級的架構師，你的工作是走進這個混亂局面，稽查缺口，並擬定一份有足夠資金支撐、也夠安全執行的分段修復計畫——執行期間工作負載必須持續服務客戶，這是與設計全新系統截然不同的工作，它是鑑識式、漸進式的。

本指南假設你已具備 Associate 等級的 CloudWatch 指標與警報、Systems Manager 基礎概念，以及 blue/green 部署基礎知識。本文聚焦於 Pro 等級的改造手冊（retrofit playbook）：以 CloudWatch Logs Insights、Contributor Insights、X-Ray、AWS Distro for OpenTelemetry (ADOT)、Amazon Managed Service for Prometheus 和 Amazon Managed Grafana 補齊可觀測性；以 AWS Systems Manager 完整套件執行 Patch Manager、Automation runbooks、OpsCenter、Incident Manager、Parameter Store、Session Manager 取代 SSH、Change Manager、Explorer；Runbook 自動化；透過 EventBridge → SNS → AWS Chatbot 建立值班通知流程；遊戲日（game days）與事後回顧（post-incident reviews）；升級至 blue/green + canary + 自動回滾的部署安全策略；以 AWS AppConfig 管理功能旗標（feature flags）；以及透過 AWS Config + Systems Manager 偵測設定漂移（drift detection）。SAP-C02 考試指南的 Domain 3 將此稱為**「改善整體卓越營運」**（task statement 3.1），此標題下的每道情境題都遵循相同模式——遺留系統、一張營運缺口清單，選出正確的修復優先順序。

為什麼卓越營運改善在 SAP-C02 如此重要

SAP-C02 的 Domain 3 佔考試 25%，而卓越營運改善是其中出題比重最大的主題。考試用語非常刻意：對比 task 3.1「決定改善整體卓越營運的策略」與 Domain 2 task 2.1「設計部署策略」——前者要求你從破損狀態開始修復，後者要求你從零開始設計。混淆這兩種思維框架，你就會用全新架構的答案回答舊系統的問題——技術上正確，但因為忽略了更動現有運行中系統的成本與風險，在營運上是幼稚的。

考試鍾愛診斷式情境，因為它能區分只會背 AWS 服務名稱的考生與真正懂得排序修復步驟的考生。典型題幹：「一個跑在三個 AZ 共 200 台 EC2 執行個體上的遺留 web 應用，每月發生四小時中斷。團隊沒有集中的指標或日誌、每逢週六晚上用 SSH 手動打修補程式、部署方式是停止執行個體再複製 artifact，並且都是靠客戶回報才知道發生故障。以下哪個選項最適合作為改善的起點？」錯誤答案會提議「改寫成 Lambda」或「遷移到有 service mesh 的 EKS」——兩者最終都有價值，但都不是第一步。正確答案從可觀測性開始，因為看不見就無法修。這種排序直覺正是 Professional 等級在測試的核心能力。

白話文解釋 Operational Excellence Improvement

卓越營運改善涉及大量 AWS 服務，若沒有貼近生活的類比，這些名稱很容易混在一起。四個類比各自帶出工作的不同面向。

類比一：連鎖工廠導入 ISO 品質管理系統

想像一家運作二十年、靠師傅口耳相傳管理品質的傳統工廠。品管全靠老師傅的經驗，出問題才知道出問題，沒有任何儀器記錄生產過程。這就是沒有可觀測性的遺留 EC2 工作負載——系統在跑，但沒有任何感測器接上去。卓越營運改善計畫就像工廠引入 ISO 9001 品質管理系統：在每台機器上裝上感測器（CloudWatch agent 安裝到每一台 EC2 執行個體），把所有數據匯入中央監控室（CloudWatch 儀表板、跨帳號可觀測性、Managed Grafana），設定閾值超標時自動呼叫值班工程師（CloudWatch alarm → EventBridge → SNS → AWS Chatbot），並加入分散式追蹤——記錄每一批貨在各工序之間的流轉時間（AWS X-Ray 或 ADOT 追蹤橫跨各微服務）。你還要把「這台機器卡料了怎麼辦」、「溫度過高怎麼辦」寫成標準作業程序，讓新進員工凌晨三點也不必靠直覺判斷（SSM Automation 文件）。工廠在升級期間不停工——你一條產線一條產線地裝感測器，這與把可觀測性分批推送到棕地 AWS 工作負載的方式完全一樣。

類比二：便利商店總部導入全店稽查系統

一家擁有三百家門市的連鎖便利商店，以前靠區域督導親自跑店稽查。進貨有沒有過期、冷藏有沒有達標、收銀機有沒有更新，每家店每季才稽查一次。這就是手動 SSH 打修補程式、沒有集中管理的老舊系統。現在總部導入全店稽查系統：每台設備掛上 IoT 感測器（CloudWatch 指標 + Contributor Insights 找出前幾名異常門市），所有操作改由後台遠端執行而不用跑現場（Session Manager 取代 SSH，所有指令都有稽核記錄，再也不需要開 port 22）。維護排程變成自動工單（SSM Patch Manager 搭配 patch baselines + Maintenance Windows）——每逢週二凌晨兩點，「生產」patch group 的每台 Linux 主機自動收到已核准的重大修補程式，不需要工程師手動操作。當感測器亮紅燈，系統自動開立工單（OpsCenter OpsItem）並附上對應的 SOP，遇到緊急事故則啟動事故橋接會議（Incident Manager 回應計畫），透過簡訊叫醒值班工程師並自動開啟共同聊天頻道。門市的設備沒有換；只是加了一套管理系統。

類比三：餐飲品牌從手寫外場單換成 POS 系統

一家經營三十年的家族餐廳靠手寫點餐單維持運作。每當客人抱怨出錯，老闆要問三個人才能重建事發經過。導入 POS 系統就是這家餐廳的可觀測性改造。每筆訂單都留下追蹤路徑：外場輸入、廚房佇列、廚師、出菜口、送餐、抵達時間——形狀與 X-Ray 服務地圖完全一樣，讓你一眼看出哪個環節拖慢了。POS 把即時儀表板推送到老闆的平板（Managed Grafana），讓老闆隨時看到哪個廚師出餐最慢。以前換菜單要印新單，現在按一個按鈕就能推送到所有平板，萬一出問題還能馬上回滾（AWS AppConfig 功能旗標搭配漸進部署與自動回滾）。餐廳不需要停業升級——先讓 POS 與手寫單並行兩週，員工熟練後再切換。你的部署安全升級（加入 canary 發布、blue/green、自動回滾）也是同樣的形狀：先把新版本送給一小部分流量，看儀表板，再決定繼續或回滾。

類比四：航空公司從電話排班換成飛行作業中心

一家老牌區域航空以前靠調度員拿著固定電話和白板協調。飛機有問題，飛行員打電話給調度員，調度員翻印刷版 SOP 再回電指示。要做到大規模的卓越營運，航空公司建立了飛行作業中心——滿牆螢幕、針對已知問題的自動化 SOP（引擎失速、艙壓異常），以及專責的事故指揮官。這就是 Incident Manager + OpsCenter + Automation 的模型。航班計畫在起飛前要通過變更管理審查委員會（Change Manager 審批流程）；飛行員依標準作業手冊（Systems Manager 文件）執行，而不是靠訓練時的記憶。跑道不安全時，作業中心即時通知所有航班（EventBridge 廣播）。最重要的是，每次事故後都有事後回顧會——機長、調度員、地勤坐在一起，比對數據，把心得寫回手冊。這就是 SAP-C02 一再考的**事後回顧（post-incident review）**步驟。

診斷起點 — 對現有系統進行五問稽查

在提出任何 AWS 服務之前，先用五個固定問題稽查現有系統。在 SAP-C02 中，「從哪裡開始？」的情境題答案幾乎都是在這五問中得分最低的那個領域。

問題一：我們現在看得到系統在做什麼嗎？

確認有無指標（CloudWatch 自訂指標、應用程式指標、業務 KPI）、日誌（集中到 CloudWatch Logs、S3 或 OpenSearch）、追蹤（X-Ray 或 OpenTelemetry 覆蓋範圍），以及儀表板（CloudWatch 儀表板、Managed Grafana 或第三方）。若有任何一項缺失或片段，可觀測性改造就是第一個修復項目。沒有這一步，後續的缺口根本無從診斷。

問題二：出問題時，我們怎麼知道？

確認有無警報、複合警報、異常偵測警報，以及通知路徑（SNS 主題、透過 AWS Chatbot 的 ChatOps、透過 EventBridge 整合 PagerDuty）。若團隊「靠客戶開票才知道」，修復項目包括 CloudWatch 警報、AWS Health + Trusted Advisor 事件的 EventBridge 規則，以及附帶 Runbook 連結頻道的 AWS Chatbot。

問題三：知道壞了什麼之後，誰來回應、怎麼回應？

確認有無值班輪班、回應計畫、事故範本，以及事後回顧紀律。若團隊靠在 Slack 私訊裡臨機應變，修復項目是 Systems Manager Incident Manager，搭配回應計畫、聯繫計畫，以及每次事故自動開啟的共享聊天頻道。

問題四：對系統的變更如何套用？

確認部署、修補程式、設定變更及操作員手動指令如何抵達生產環境。若工程師用 SSH 登入執行指令，修復項目是 Session Manager + SSM Run Command + 已核准變更的 Change Manager。若部署是就地複製，修復項目是 CodeDeploy blue/green 或 canary 搭配自動回滾。若修補程式是手動作業，修復項目是 Patch Manager 搭配 patch baselines 和 Maintenance Windows。

問題五：我們如何確認系統沒有發生漂移？

確認基礎設施、安全群組、IAM policies 和應用程式設定是否有設定漂移偵測。若「大概是有人改過」是常見的回答，修復項目是 AWS Config 規則（受管與自訂）、Config conformance packs、CloudFormation drift detection，以及帳號已加入 Control Tower 時的 Control Tower drift detection。

可觀測性改造 — 在現有工作負載上補齊指標、日誌、追蹤與儀表板

可觀測性是第一個要修復的領域，因為所有後續修復都依賴它。AWS 的可觀測性建構模組包含：Amazon CloudWatch（指標、日誌、警報、儀表板、Logs Insights、Contributor Insights、異常偵測）、AWS X-Ray（分散式追蹤）、AWS Distro for OpenTelemetry (ADOT)（廠商中立的指標/日誌/追蹤收集器）、Amazon Managed Service for Prometheus（AMP，Prometheus 格式指標，Kubernetes 原生）、Amazon Managed Grafana（AMG，跨資料來源儀表板），以及 CloudWatch Container Insights / Lambda Insights（工作負載專屬監控套件）。

透過 Systems Manager 在大規模機群中推送 CloudWatch Agent

對現有的 EC2 機群，卓越營運的第一項任務是在每一台執行個體上安裝並設定 CloudWatch agent，取得 hypervisor 層級基礎指標看不到的記憶體、磁碟、程序與自訂日誌指標。在大規模機群中，透過 AWS Systems Manager 執行此操作——以 Run Command 推送 AWS-ConfigureAWSPackage 或 AmazonCloudWatch-ManageAgent SSM 文件，並搭配 SSM State Manager association 持續強制執行已安裝的版本。CloudWatch agent 設定本身可以存放在 Parameter Store，如此一來機群範圍的設定變更只需更新一次 Parameter Store，State Manager 就會自動套用。

此模式是 SAP-C02「如何快速為現有 500 台執行個體機群加上可觀測性而不需要手動登入」的標準答案。其他替代方案——user-data 腳本、Ansible、Chef——都能運作，但 SSM 是 AWS 原生答案，且不需要開放 port 22。

CloudWatch Logs Insights 與 Contributor Insights 用於現有 Log Streams

日誌開始流向 CloudWatch Logs 之後，CloudWatch Logs Insights 可讓你以類似 SQL 的語法對日誌進行臨時查詢。它不是即時的——查詢在指定的時間範圍內按需執行——但對於在事故發生時挖掘資料，這是不需要匯出到 S3 + Athena 就能快速分析的最佳方式。典型的 Pro 等級查詢包括：依服務排出前幾名的錯誤訊息、從結構化 JSON 日誌計算百分位數延遲（stats pct(responseTime, 99) as p99），以及跨服務關聯 request ID。

CloudWatch Contributor Insights 是另一個功能，持續對指標或 log stream 中的頂端貢獻者進行排名——依請求數排出前幾名 IP、依頻率排出前幾名錯誤訊息、依消耗容量排出 DynamoDB 前幾名 partition key。在 SAP-C02 中，Contributor Insights 是「找出前 10 名異常來源」或「找出哪個客戶端 IP 佔了 40% 流量」情境的答案。你在 log group 上設定一條規則，它就持續更新。

CloudWatch 複合警報、異常偵測與 Metric Math

三個 CloudWatch 功能在改造維運中格外重要：

• 複合警報（Composite alarms） 用布林邏輯（ALARM(HighCPU) AND ALARM(HighLatency)）組合多個底層警報。它們抑制警報風暴——只有複合條件成立時才傳呼，不會每個單一指標閃爍就通知。在 SAP-C02 中，複合警報是「團隊被低訊號警報淹沒」情境的答案。
• 異常偵測警報（Anomaly detection alarms） 學習指標的預期範圍，只在偏差時觸發警報，非常適合週期性工作負載（每天中午流量高峰）——靜態閾值在此情況下容易誤報。
• Metric math（含 ANOMALY_DETECTION_BAND、IF、SEARCH）從現有指標計算衍生指標——例如從命中和未命中計數器算出快取命中率，或計算每請求標準化成本——而不需要發出新指標。

AWS X-Ray 對現有應用程式的改造

為現有應用程式加入 AWS X-Ray 分散式追蹤是一個多步驟的改造：

1. 以 X-Ray SDK（原生 SDK 支援 Java、Python、Node.js、Go、.NET、Ruby）插樁應用程式，或改用 AWS Distro for OpenTelemetry (ADOT) 進行廠商中立的插樁，並同時發送到 X-Ray。
2. 在 EC2 / ECS EC2 上部署 X-Ray daemon，或在 Fargate、Lambda 和 API Gateway 上使用內建的 X-Ray 整合（無需 daemon）。
3. 在 Lambda 函數和 API Gateway stages 上啟用 active tracing——一個點擊或 IaC 變更即可完成。
4. 設定取樣規則，對高流量請求取樣一小部分，對低流量或錯誤請求取樣 100%。預設取樣為每秒 1 個請求 + 額外請求的 5%——依成本調整。
5. 為共享同一個過濾表達式的追蹤建立 X-Ray groups（例如 service("checkout") AND responsetime > 2），並為 group 指標附加 CloudWatch 警報。
6. 使用 X-Ray Insights 自動偵測追蹤中的異常——它無需手動調整警報就能浮現延遲異常和錯誤激增。

在 SAP-C02 中，X-Ray 是「找出微服務應用程式中是哪個下游相依性造成延遲」的標準答案。服務地圖可視化加上 segment 下鑽比日誌關聯快得多。

AWS Distro for OpenTelemetry (ADOT) — 何時選它而非原生代理程式

ADOT 是 AWS 支援的 OpenTelemetry 發行版。它把指標發送到 CloudWatch 和 Amazon Managed Prometheus，把追蹤發送到 X-Ray、AWS OpenSearch 或第三方後端，把日誌發送到 CloudWatch Logs 或其他目的地。在以下情況選擇 ADOT，而非原生 CloudWatch agent + X-Ray SDK 的組合：

• 組織希望採用廠商中立的插樁方式，讓同一個程式碼庫能同時發送到 Datadog、New Relic 或 Honeycomb 以及 AWS 後端。
• 工作負載在其他環境中已使用 OpenTelemetry，遷移到 AWS 原生 SDK 會是退步。
• Kubernetes 工作負載希望用單一的 collector sidecar 或 DaemonSet 取代多個代理程式。

ADOT 比原生代理程式複雜度稍高，但在多雲策略中提供了值得的可攜性。

Amazon Managed Service for Prometheus 與 Amazon Managed Grafana

Amazon Managed Service for Prometheus (AMP) 是 AWS 託管的 Prometheus 相容指標儲存庫。它接收來自 EKS、ECS 或自管 Prometheus 的 remote-write 流量，不需要面對一般 Prometheus 儲存的痛點就能長期保留資料，並以 IAM + SigV4 進行身份驗證。當工作負載已使用 Prometheus（Kubernetes 原生指標、kube-state-metrics、Prometheus client libraries），且團隊不想自行維運 Prometheus + Thanos stack 時，選擇 AMP。

Amazon Managed Grafana (AMG) 是受管的儀表板層，可查詢 AMP、CloudWatch、X-Ray、AWS OpenSearch、Amazon Timestream、Amazon Athena，以及許多非 AWS 來源（Datadog、Splunk、New Relic、Azure Monitor、GCP Cloud Monitoring）。在 SAP-C02 中，AMG 是「需要同時涵蓋 CloudWatch 和 Prometheus 和第三方的單一視窗」情境的答案——因為 CloudWatch 儀表板無法原生讀取 Prometheus。AMG 透過 IAM Identity Center 支援 SAML SSO 與細粒度的團隊權限。

跨帳號與跨 Region 可觀測性

大型組織通常在數十個帳號上執行工作負載。原生 CloudWatch 是 Regional 且以帳號為單位的。進行卓越營運改善時，你需要補齊一個監控帳號模式：

• CloudWatch 跨帳號可觀測性 — 一個現代功能，讓指定的監控帳號能在不複製資料的情況下，直接查看來自連結來源帳號的指標、日誌和追蹤。來源帳號執行一個小型資源政策；監控帳號進行聚合。
• 跨 Region 儀表板 — CloudWatch 儀表板可以使用明確的 region 選擇器顯示來自多個 region 的 widget。
• Managed Grafana 跨帳號 — AMG 支援在多個 AWS 帳號中擔任 IAM roles 作為資料來源，若偏好 Grafana UX，可不使用 CloudWatch 跨帳號可觀測性功能就建立跨帳號儀表板。

Systems Manager 用於卓越營運 — 完整套件

AWS Systems Manager 是一組共用 SSM Agent 和 Fleet Manager 基礎架構的營運功能集合。每個 Pro 等級的改造情境都會涉及至少兩到三個 SSM 元件，請將清單熟記於心。

Fleet Manager 與 Inventory — 掌握你擁有什麼

Fleet Manager 是不需要登入個別執行個體就能檢視和管理機群的控制台。Inventory 從每個已註冊的執行個體收集軟體、修補程式、網路和自訂屬性，儲存在可查詢的庫存中，並可透過 Systems Manager Resource Data Sync 同步到 S3 供 Athena 分析。在 SAP-C02 中，Inventory 是「如何知道 800 台執行個體上分別跑著哪個版本的 log4j？」的答案。

Patch Manager — 對現有機群自動化修補程式

Patch Manager 是最常見且最快速見效的改造項目。元件包含：

• Patch baselines — 以 OS 為單位的規則，定義哪些修補程式在等待期後自動核准、哪些被拒絕。每個支援的 OS 都有預設基線；自訂基線可覆蓋它。
• Patch groups — 執行個體上的標籤（Patch Group = Production、Patch Group = Critical），用來對應到基線。
• Maintenance Windows — 排程的時間區段（例如週日 02:00 - 04:00 UTC），在此期間 Patch Manager 針對 patch group 中的執行個體，套用或回報（僅掃描 vs 掃描並安裝）已核准的修補程式。
• 合規回報 — Patch Manager 持續回報合規狀態，並輸入到 Config 規則和 Security Hub。

遷移路徑：為每台執行個體加上 Patch Group 標籤、附加含 AmazonSSMManagedInstanceCore 的 IAM instance profile、讓 SSM agent 完成註冊、依 patch group 建立 Maintenance Window、指向 AWS-RunPatchBaseline 文件，並先以僅掃描模式驗證，再啟用安裝。

Automation Runbooks — 從部落知識到程式碼

Systems Manager Automation 執行 runbooks——以 YAML 或 JSON 定義的有序步驟文件，可呼叫 AWS API、執行腳本、暫停等待審批，或依輸出結果分支執行。整個 AWS 受管 Runbook 目錄以 AWS- 為前綴（AWS-RestartEC2Instance、AWS-StartStopAuroraCluster、AWS-UpdateAmazonLinuxAMI、AWS-CreateManagedLinuxInstance、AWS-PatchInstanceWithRollback 等）。你可以複製、自訂並以 Company- 前綴為你的 Runbook 進行版本管理。

Automation runbooks 將部落知識轉化為可重複執行的操作程序。改造目標範例：

• 執行個體恢復 Runbook：CloudWatch 警報觸發 → EventBridge 規則 → Automation runbook 停止後重啟執行個體並驗證健康狀態。
• AMI 修補 Runbook：每週執行，Automation 取得基底 AMI、啟動執行個體、套用修補程式、執行 Inspector、建立新 AMI 並更新 launch template。
• RDS 容錯移轉演練 Runbook：排程執行，Automation 發起容錯移轉、測量回復時間，並把結果寫入 S3 稽核儲存桶。

Automation runbooks 也透過 AWS Organizations 整合支援跨帳號跨 Region 執行，這是 SAP-C02「從管理帳號或委派管理員帳號一次為 50 個帳號打修補程式」的正確答案。

Session Manager — SSH 的終結

Session Manager 透過 AWS Management Console 或 CLI 在受管執行個體上開啟互動式 shell，無需開放 port 22、無需 bastion host、無需 SSH 金鑰發放，並透過 CloudTrail + CloudWatch Logs + S3 session logs 完整稽核。在 SAP-C02 中，每當情境提到「消除 SSH」、「移除 bastion host」、「稽核操作員指令」或「不透過 VPN 存取私有子網路執行個體」，Session Manager 就是正確答案。

Session Manager 支援連接埠轉發（用於透過通道存取 RDP 或資料庫）、session 錄製到 S3 + CloudWatch Logs（以 KMS 加密），以及文件式 session（SSM-SessionManagerRunShell），讓你可以限制操作員能執行的指令。

State Manager — 持續設定強制執行

State Manager 將 SSM 文件與目標（標籤、執行個體、群組）以排程方式關聯，持續強制執行所需狀態。典型的關聯項目：「每 30 分鐘，確認 CloudWatch agent 正在以 Parameter Store 中預期的設定運行」；「每日，驗證 /etc/my-app/config.yaml 符合預期的 checksum」；「執行個體啟動時，執行一次啟動引導文件」。State Manager 是 SSM 中最接近冪等設定管理器的功能。

OpsCenter — 集中問題追蹤

OpsCenter 提供 OpsItem 佇列——AWS 原生的營運票務系統。EventBridge 規則、Config 規則不合規事件、Security Hub 發現，以及 CloudWatch 警報都能自動建立 OpsItem。每個 OpsItem 可攜帶情境資料、建議的 Runbook 和指派的操作員。對於沒有票務管理習慣的棕地系統，OpsCenter 是集中化營運佇列的第一層；對於成熟的組織，它則轉發到 Jira、ServiceNow 或 PagerDuty。

Incident Manager — 回應計畫與值班

Systems Manager Incident Manager 是事故回應元件：回應計畫、聯繫計畫（呼叫誰與何時呼叫）、升級計畫、Runbook 連結、透過 AWS Chatbot 整合的聊天頻道，以及事後分析。當高嚴重性 CloudWatch 警報觸發時，EventBridge 將其路由到 Incident Manager 回應計畫，該計畫會：

1. 建立含嚴重性與時間軸的事故記錄。
2. 依聯繫計畫透過簡訊、語音或電子郵件傳呼值班輪班人員。
3. 透過 AWS Chatbot 開啟含事故情境的專屬 Slack 或 Teams 頻道。
4. 附上回應者可從頻道直接執行的建議 Runbook（Automation 文件）。
5. 在時間軸上追蹤每一個動作，供事後回顧使用。

在 SAP-C02 中，「我們需要整合值班傳呼、共享聊天和 Runbook 執行的事故回應流程，且自訂程式碼最少」的標準答案是 Systems Manager Incident Manager，而不是自訂 Lambda + PagerDuty + Slack bot。

Change Manager — 變更的審批流程

Change Manager 提供與 SSM Automation 整合的變更請求流程。變更範本定義了必要的審閱者、審批門檻、變更凍結期間，以及該變更可執行哪些 Automation 文件。操作員提交變更請求；審批者在 Change Manager 中審閱並核准；核准後，關聯的 Automation runbook 即執行。Change Manager 為合規提供稽核路徑。

這是 SAP-C02「我們需要對生產基礎設施動作進行變更審批，而不需要拼湊 Lambda + Step Functions + 自訂 UI」的答案。Change Manager 疊加在 Automation 上，提供受管的變更執行。

Parameter Store — 設定與密鑰儲存

Parameter Store 儲存純文字和 KMS 加密的參數。在卓越營運面，它的角色是：

• 設定集中化 — 服務在啟動時（或收到重新整理訊號時）從 Parameter Store 讀取設定，而不是把設定烘焙進 AMI 或環境變數檔案。變更只需執行 ssm:PutParameter + 重啟。
• CloudWatch agent 設定儲存 — agent 支援直接從 Parameter Store 讀取其設定。
• 跨服務參照 — CloudFormation、CodePipeline 和 Lambda 在部署時原生解析 ssm: 參數參照。
• 低敏感度的密鑰 — Parameter Store 的 SecureString 類型支援加密；若需要自動輪換和跨帳號共用，請優先使用 Secrets Manager。

Explorer — 營運儀表板

Systems Manager Explorer 跨帳號和 region 匯總營運資料：OpsItems、修補程式合規、Inventory 摘要、State Manager 關聯合規。這是 Systems Manager 提供的整體營運態勢單一視窗。在 SAP-C02 中，Explorer 是「為管理帳號提供 80 個成員帳號的整合營運視圖」的答案。

Runbook 自動化 — 用可執行的 Runbook 取代手動 Runbook

Runbook 是一組有序的操作員動作。卓越營運改善的旅程將 Runbook 經歷三個成熟階段：

1. 手動 Runbook — wiki 頁面上的步驟清單。容易出錯、不一致、無法稽核。
2. 腳本化 Runbook — git repo 中的 bash 或 Python 腳本。較好，但仍需要操作員用正確的憑證手動執行。
3. 可執行 Runbook — SSM Automation 文件，可手動觸發、排程觸發或由 EventBridge 規則觸發，以最小權限 IAM 角色執行並留下 CloudTrail 稽核。

改造處方：盤點團隊前 10 個 wiki runbook，把每個轉成 Automation 文件，為明顯的觸發器接好線（警報 → EventBridge → 文件），並廢棄 wiki 頁面。在 SAP-C02 中，「將操作 Runbook 轉換為可執行的自動化」是「如何減少事故回應期間的操作員失誤？」的答案。

常見的 Runbook 模式：

• 自動重啟不健康的服務 — 健康檢查失敗的 CloudWatch 警報 → EventBridge → AWS-RestartEC2Instance 或 AWS-RestartECS2Task。
• 依自訂指標自動擴展 — CloudWatch 警報 → Lambda → 更新 ASG desired capacity（或直接使用 ASG 階梯式擴展政策）。
• 自動清除日誌磁碟 — State Manager association 每 6 小時執行一次清理腳本。
• 自動修復 Config 規則違規 — Config 規則不合規 → EventBridge → SSM Automation 套用修正（例如啟用加密、移除 S3 bucket 的公開 ACL）。AWS 為許多 Config 規則提供受管修復文件。

值班模式 — EventBridge、SNS、Chatbot 與 Incident Manager

值班模式是從「出問題了」到「有人在看」之間的管道。棕地工作負載的成熟管道形狀如下：

1. 來源事件：CloudWatch 警報（指標超閾）、EventBridge 規則（Config 合規狀態變更、Health Dashboard 問題、Security Hub 發現、Auto Scaling 活動）。
2. 路由：附有輸入轉換器以豐富事件情境的 EventBridge 規則。
3. 嚴重性分類：Lambda 或事件模式本身標記嚴重性（P1、P2、P3）。
4. 通知廣播：依嚴重性區分的 SNS 主題，訂閱者為 AWS Chatbot（路由到 Slack 或 Microsoft Teams 頻道，格式化顯示並附上執行 Automation runbook 的按鈕），以及 P1 的 PagerDuty / Opsgenie HTTPS 訂閱。
5. 事故建立（P1）：EventBridge 規則目標為 Systems Manager Incident Manager 回應計畫，開啟事故記錄、傳呼輪班人員、開啟作戰室頻道，並附上建議 Runbook。
6. 事後處理：事故記錄保存時間軸；後續回顧建立 OpsItem 追蹤修復工作。

AWS Chatbot 特別有價值，因為它消除了 ChatOps 的自訂程式碼。它訂閱 SNS 主題、為人類閱讀格式化事件，並且——對於卓越營運尤其關鍵——支援直接從 Slack/Teams 執行 SSM 指令、呼叫 Lambda，以及讀取 CloudWatch 指標，並以 IAM 控制權限。在 SAP-C02 中，「營運團隊希望從 Slack 查看警報並執行已核准的修復動作」的答案是 AWS Chatbot，而不是自訂 bot。

遊戲日與事後回顧 — 驗證營運準備度

卓越營運不是部署完就不管的能力；它需要持續演練。SAP-C02 考試中有兩個紀律非常重要。

遊戲日與 AWS Fault Injection Service (FIS)

遊戲日是一種排程的混沌工程演練，團隊刻意注入故障，驗證監控、警報、Runbook 和值班是否如設計般運作。AWS Fault Injection Service (FIS) 是 AWS 受管的混沌工程服務。它提供含動作（停止執行個體、終止程序、注入 CPU 負載、節流 API、注入網路延遲、RDS 容錯移轉、暫停 Auto Scaling）、目標（標籤、資源 ID、隨機選取）和停止條件（CloudWatch 警報，若觸發則自動終止實驗並復原動作）的實驗範本。FIS 與 IAM 整合以控制爆炸半徑，並與 EventBridge 整合以發出實驗事件。

典型的改造遊戲日實驗：

• 單一 AZ 故障 — 停止一個 AZ 中的所有 EC2 執行個體；驗證 ALB 切換流量且 ASG 補充替換。
• RDS 容錯移轉 — 觸發 RDS Multi-AZ 容錯移轉；驗證應用程式重新連線時間。
• 相依性延遲 — 對 DynamoDB 注入 500ms 延遲；驗證斷路器和重試預算。
• Region 撤離演練 — 停止主要 region 的流量；驗證 DR runbook 執行。

在 SAP-C02 中，FIS 是「如何持續驗證營運準備度？」和「如何在有安全網的情況下執行混沌實驗？」的答案。

事後回顧（PIR）— 將事件轉化為改善

結構化的事後回顧關閉了卓越營運的迴圈。AWS Well-Architected 指導原則是在任何重大事故後 5 個工作日內執行無責怪的 PIR，涵蓋：事件時間軸、偵測缺口（我們能更早發現嗎？）、診斷缺口（Runbook 有幫助嗎？）、緩解缺口（自動化回應有效嗎？），以及有負責人的行動項目。Systems Manager Incident Manager 自動捕捉時間軸，並提供事後分析範本，引導團隊逐一檢視這些問題，並連結到事故記錄。

部署安全改善 — 從就地部署到 Blue/Green + Canary + 自動回滾

棕地部署管道通常看起來像：停止服務、複製新的 artifact、啟動服務。這種模式讓你承受約 N 分鐘的停機時間，且除了「把舊 artifact 複製回來」之外沒有回滾策略。卓越營運改善的旅程分階段升級這個流程。

階段一：滾動部署（Rolling Deployments）

將就地部署轉換為滾動部署——在負載平衡器後面一次替換一台或少量執行個體。在 EC2 上，這是 ASG instance refresh 或 CodeDeploy in-place 搭配 minimum healthy hosts 值。在 ECS 上，這是預設的滾動部署控制器，設定 minimumHealthyPercent 和 maximumPercent。滾動部署在整個過程中保持服務可用，但一個有問題的部署在你注意到之前可能已影響到每一台執行個體。

階段二：Blue/Green 部署

將滾動部署轉換為 blue/green — 在舊版本（blue）旁邊啟動全新機群（green），執行冒煙測試，然後一次性切換流量（DNS cutover、ALB target group 切換，或 Lambda alias 流量切換）。若 green 表現異常，流量立即切回 blue。實作此策略的 AWS 服務：

• AWS CodeDeploy — ECS blue/green，透過 CloudFormation hook 或直接執行；在驗證測試後切換 ALB target groups。
• AWS CodeDeploy — Lambda，透過 alias 流量切換策略：AllAtOnce、Linear、Canary（可搭配 CloudWatch 警報回滾）。
• AWS CodeDeploy — EC2/on-premises blue/green，透過替換 ASG 和 ELB target group 切換。
• ECS 原生 blue/green（2024 年發布），透過含警報回滾的服務部署。
• Elastic Beanstalk 交換環境 URL，適用於前容器世代的應用程式。

Blue/green 在部署期間使運算成本加倍——考試陷阱意識，但安全性值得此代價。

階段三：Canary 部署

更進一步採用 canary — 將一小部分流量（例如 10%）切換到新版本，在**烘焙期（bake time）**間監控關鍵指標（p99 延遲、錯誤率、業務轉換率），然後切換剩餘流量或回滾。CodeDeploy 原生支援 Lambda 和 ECS 的 canary。API Gateway canary releases 在 API 層做同樣的事。在 SAP-C02 中，canary 是「必須在影響全機群之前偵測到問題部署」或「風險容忍度要求烘焙期驗證」的答案。

階段四：透過 CloudWatch 警報自動回滾

關鍵的卓越營運能力是與警報連動的自動回滾。CodeDeploy deployment groups 接受一份 CloudWatch 警報清單；若在部署期間任何警報進入 ALARM 狀態，CodeDeploy 自動回滾——不需要人工介入。警報應該反映客戶可見的 SLO：p99 延遲、錯誤率、5xx 比率、業務 KPI（結帳轉換率）。這是 SAP-C02「部署出問題時縮短 MTTR」的標準答案。

用 AWS AppConfig 管理功能旗標

AWS AppConfig 是功能旗標（feature flag）與動態設定服務。它將設定變更與程式碼部署解耦。應用程式在啟動時呼叫 AppConfig SDK 並輪詢更新；AppConfig 以漸進方式（線性或指數，在指定的持續時間內）推出設定變更，在部署到目標之前執行驗證器（JSON schema、Lambda 函數），並在推出期間若已設定的 CloudWatch 警報觸發時自動回滾。

典型的改造用途：

• 關閉開關功能旗標（Kill-switch feature flag） — 不需程式碼部署即可關閉有問題的功能。
• 漸進功能推出 — 在一週內將新功能逐步曝光給 1% → 10% → 100% 的使用者，並監控指標。
• 每租戶設定覆蓋 — 依客戶區段切換功能。
• 營運閾值 — 把調整常數（重試次數、逾時時間、快取 TTL）從環境變數移到 AppConfig，如此可以不重新部署就變更。

在 SAP-C02 中，AppConfig 是「不需程式碼部署就改變應用程式行為」和「以自動回滾漸進啟用功能」的答案。它與 Parameter Store（啟動時讀取的靜態設定）不同，因為 AppConfig 增加了版本管理、驗證、漸進部署和警報回滾。

設定漂移偵測與持續合規

棕地系統會發生漂移。安全群組在緊急應對中被放寬後沒有收回。S3 bucket 為了一次性測試打開公開存取後被遺忘。加密預設值在帳號恢復期間被翻轉。AWS Config 是持續設定態勢的改造工具。

AWS Config 受管與自訂規則

AWS Config 記錄受支援資源的每一個設定變更，並依目前狀態評估規則：

• 受管規則由 AWS 維護（例如 s3-bucket-public-read-prohibited、restricted-ssh、rds-storage-encrypted、ec2-instance-detailed-monitoring-enabled）。它們涵蓋常見的控制項。
• 自訂規則是 Lambda 函數或 Guard 規則，用於評估你需要的任何條件。

不合規事件發送到 EventBridge，後者將其路由到 SNS（通知）、OpsCenter（追蹤）或 Automation（修復）。

透過 Systems Manager 或 Lambda 自動修復

Config 支援針對不合規資源以指定 SSM Automation 文件（以不合規資源 ID 作為輸入）進行自動修復。AWS 提供預先建立的修復文件：AWS-DisablePublicAccessForSecurityGroup、AWS-EnableS3BucketEncryption、AWS-PublishSNSNotification、AWS-DetachRolePolicy。在 SAP-C02 中，自動修復是「偵測並修復特定錯誤設定而不需要人工動作」的答案。

合規基線的 Conformance Packs

Conformance packs 是可作為一個單元部署的 Config 規則 + 修復動作集合——通常對應到某個合規框架（CIS AWS Foundations Benchmark、PCI DSS、HIPAA、FedRAMP）。透過 AWS Organizations 在組織層級部署 conformance pack，範圍內的每個帳號都會取得相同的規則集。

CloudFormation Drift Detection 與 Control Tower Drift

對於基礎設施即程式碼的工作負載，CloudFormation drift detection 將已部署的 stack 資源與範本進行比對，並標記差異（有人在控制台中編輯了安全群組）。你可以透過 EventBridge 以每日節奏排程漂移偵測。Control Tower drift detection 對 landing zone 管理的資源（Log Archive bucket policy 被更改、SCP 被分離、OU 被移動）做同樣的事。

診斷情境 — 每月中斷、無可觀測性、手動修補的遺留應用程式

這是 SAP-C02 Domain 3 的典型題幹。把它當作一道處方練習來讀。

題幹： 一個內部企業應用程式，在 Application Load Balancer 後面跨兩個 AZ 執行在 120 台 EC2 執行個體上。它使用單一 AZ 的 MySQL on EC2 和一個自行撰寫的檔案式日誌系統。營運團隊靠使用者開支援票才知道發生中斷；沒有儀表板、沒有警報、沒有彙總日誌。修補程式由一位輪值工程師每逢週六晚上透過 SSH、使用儲存在團隊 wiki 上的共用 SSH 金鑰手動套用。部署每季一次，透過一個腳本把 tarball 複製到每台執行個體，讓執行個體離線兩分鐘。團隊曾為沒有人記得做過的設定變更損失許多時間，每個月都有一次原因必須靠使用者回報來重建的四小時中斷。SAP-C02 題幹問：架構師應以什麼順序改善卓越營運？

正確順序，編碼於 AWS Well-Architected 卓越營運支柱與 SAP-C02 考試指南中，如下：

步驟一 — 在所有地方安裝 SSM Agent 和 CloudWatch Agent

沒有 SSM agent，你就無法管理機群；沒有 CloudWatch agent，你就沒有指標。透過一次性 Run Command 安裝兩者（或替換 AMI 為已預裝的版本），並以 State Manager association 強制執行。為每台執行個體附加 AmazonSSMManagedInstanceCore IAM 角色。為執行個體加上 Patch Group、Environment、Owner、Application 標籤。單單這個步驟就解鎖了所有後續工作。

步驟二 — 集中日誌並建立第一個儀表板

將 CloudWatch agent 指向應用程式日誌檔案，以結構化格式（JSON，或透過 Logs subscription + Lambda 轉換）流入 CloudWatch Logs。建立含 CPU、記憶體、磁碟、ALB 目標回應時間、ALB 5xx 率、MySQL 連線數和幾個業務 KPI 的 CloudWatch 儀表板。為 ALB 5xx 率、ALB 目標不健康數和 MySQL 連線耗盡建立第一批警報。將警報接到附有 AWS Chatbot Slack 整合的 SNS 主題，讓團隊即時在頻道看到警報。

步驟三 — 用 Session Manager 取代 SSH

刪除共用 SSH 金鑰、在安全群組關閉 port 22，並要求使用 Session Manager 進行互動式存取。啟用以 KMS 加密的 session 錄製到 S3 和 CloudWatch Logs。你現在有了稽核的存取路徑，這同時是卓越營運和安全性的改善。

步驟四 — 以 Patch Manager 自動化修補程式

定義 patch baseline（例如「重大和重要的安全修補程式在 7 天後自動核准」），透過標籤對應 patch groups，建立 Maintenance Window（週日 02:00 - 04:00），並附加 AWS-RunPatchBaseline 文件。先執行僅掃描模式，再啟用安裝。將合規性報告到 Security Hub。週六晚上的值班工程師角色就此退役。

步驟五 — 加入分散式追蹤與 Contributor Insights

在應用程式中啟用 X-Ray（或 ADOT）。建立顯示 ALB → EC2 → MySQL 的 X-Ray 服務地圖。在 access log group 上建立 Contributor Insights 規則，持續依請求數排出前幾名客戶端 IP，並依錯誤率排出前幾名 endpoints。這解鎖了以前用檔案日誌根本無法進行的單一請求診斷。

步驟六 — 升級部署至 Blue/Green 搭配自動回滾

將部署流程遷移到 CodeDeploy EC2 blue/green，搭配 ASG 替換和 ALB target group 切換。在部署群組上附加 p99 延遲和 5xx 率的 CloudWatch 警報；若在部署期間觸發，CodeDeploy 自動回滾。每台執行個體兩分鐘的停機時間消失；無法回滾的問題消失。

步驟七 — 引入 AppConfig 功能旗標

引入 AppConfig 作為關閉開關功能旗標和營運閾值調整。搭配 CloudWatch 警報回滾的漸進推出，取代「改一個設定值就要重新部署整個 tarball」的模式。

步驟八 — 加入 Config 規則與漂移偵測

啟用 AWS Config，部署 CIS AWS Foundations conformance pack，加入「必須有 Patch Group 標籤」和「MySQL 安全群組不得開放到 0.0.0.0/0」的自訂規則。在安全的情況下啟用自動修復。不合規的發現進入 OpsCenter 等待審查。

步驟九 — 採用 Incident Manager 管理值班

為前三個故障模式建立回應計畫：「ALB 5xx 激增」、「MySQL 連線耗盡」、「任何執行個體磁碟滿」。以值班輪班定義聯繫計畫。警報觸發時，Incident Manager 開啟事故、傳呼工程師、透過 Chatbot 開啟 Slack 作戰室頻道，並附上建議的 SSM Automation runbook。

步驟十 — 進行 RDS 遷移並排定遊戲日

將 MySQL on EC2 遷移到 RDS Multi-AZ（這是可靠性改善，超出 Domain 3.1 的範圍——屬於 3.4）。每季排定一次 FIS 實驗模擬 AZ 故障。每次演練後執行無責怪 PIR，並將行動項目建立為 OpsItems。

完成這個順序後，每月四小時的中斷將變成數分鐘內自動修復的事件，週六晚上的修補程式作業消失，團隊從被動追票轉向主動的 SLO 管理。在 SAP-C02 中，若題幹問「團隊第一步應該做什麼？」，答案是步驟一或步驟二——可觀測性解鎖所有其他事情。若問「什麼能最大幅降低 MTTR？」，答案是步驟六或步驟九——自動回滾和自動化事故回應。記住這個順序，具體的排序問題就水到渠成。

情境模式 — 改造模式手冊

除了典型題幹外，SAP-C02 還循環出現少數幾種改造模式。快速辨識它們。

情境模式一：跨帳號沒有能見度

一個擁有 60 個成員帳號的大型組織，各自擁有孤立的儀表板，沒有單一視窗。營運團隊希望統一所有帳號的指標、日誌和追蹤。

最佳模式：啟用 CloudWatch 跨帳號可觀測性，將監控帳號連結到每個來源帳號。部署帶有 IAM Identity Center SSO 的 Amazon Managed Grafana，設定透過 AssumeRole 跨帳號的 CloudWatch 資料來源，以及 Kubernetes 工作負載的 AMP。依團隊建立含細粒度權限的資料夾。透過跨帳號可觀測性連結將 X-Ray 追蹤發送到監控帳號。

錯誤模式：「把指標複製到 S3 然後用 Athena 查詢」（慢，非即時）；「用 Kinesis + Elasticsearch 建立自訂聚合器」（不必要的複雜度）；「用每帳號的儀表板」（違背目標）。

情境模式二：機群上的手動修補程式

一個組織在多個帳號中跑著數千台 EC2 執行個體。修補程式管理手動且不一致；稽核人員無法產出合規報告。

最佳模式：透過委派管理員和 Quick Setup 在所有帳號啟用 Systems Manager，以 patch groups 為執行個體加標籤，依 OS 系列定義 patch baselines，排定 Maintenance Windows，執行 AWS-RunPatchBaseline，並透過 Config 整合將合規資料輸入 Security Hub。從委派管理員帳號透過 Organizations 整合進行跨帳號執行。

錯誤模式：「用 user data 腳本執行 yum update」（不可重複，無合規報告）；「要求每個帳號擁有者自行修補」（無法強制執行）。

情境模式三：部署上個月導致中斷

一次生產部署造成 45 分鐘的中斷。團隊靠複製舊 artifact 回滾。管理層要求此事不再發生。

最佳模式：遷移到 CodeDeploy，採用 blue/green（全平行機群安全性）或 canary（部分流量驗證）部署。在部署群組上附加 5xx 率和 p99 延遲的 CloudWatch 警報，設定自動回滾。加入 AppConfig 功能旗標，讓有風險的程式碼路徑可以獨立禁用而不需要重新部署。要求執行事後回顧以產生部署安全行動項目。

錯誤模式：「每次部署都要求手動審批」（降低速度卻不降低風險）；「只在上班時間部署」（不能防止 bug）。

情境模式四：SOC 想要基於聊天的操作

SOC 希望在不開票的情況下，直接從 Slack 調查和修復問題。

最佳模式：AWS Chatbot 連接到依嚴重性區分的 SNS 主題，啟用 IAM 控制的指令。操作員可以從 Slack 查詢 CloudWatch 指標、執行已核准的 SSM Automation 文件，以及呼叫特定 Lambda 函數。與 Incident Manager 整合，用於 P1 作戰室。

錯誤模式：「建立自訂 Slack bot」（重複發明 Chatbot）；「用帶有控制台連結的電子郵件警報」（破壞聊天操作流程）。

情境模式五：設定漂移正在破壞合規性

稽核人員發現資源不合規；團隊認為有人在事故期間「修復」了設定但沒有復原。

最佳模式：透過委派管理員到 Audit 帳號，在組織層級啟用 AWS Config。部署 conformance packs（視適用情況選 CIS、PCI）。為組織特定的控制項加入自訂規則。對安全的控制項啟用自動修復（例如重新啟用 S3 預設加密）。無法自動修復的發現以 OpsItems 進入 OpsCenter。定期執行 Control Tower drift detection 報告。

錯誤模式：「每月做一次手動稽查」（太慢，錯過事件）；「對工程師進行更好的訓練」（無法規模化）。

稽查工作流程 — Pro 架構師如何診斷營運態勢

在 SAP-C02 中，有時問題不是「要修什麼」而是「先診斷什麼」。Pro 架構師走進新客戶或新帳號時使用的稽查工作流程：

1. AWS Trusted Advisor — 開啟帳號的 Business 等級 Trusted Advisor 檢查，依嚴重性排序，記錄效能、安全性、容錯性、服務限制和成本最佳化的紅色與黃色發現。這是 10 分鐘的第一次快速掃描。
2. AWS Health Dashboard — 檢查是否有任何正在影響的 AWS Health 事件。若 AWS 事故正在進行，營運態勢問題可能是症狀，而非根本原因。
3. Security Hub 與 GuardDuty — 檢查目前的分數和前幾名發現。營運態勢與安全態勢高度相關。
4. AWS Config 儀表板 — 計算不合規資源數量並依規則排名，找出哪些控制項違規最多。
5. Systems Manager Explorer — 檢查已涵蓋帳號的修補程式合規性、庫存和 OpsItem 積壓。
6. CloudWatch 儀表板與警報庫存 — 是否有儀表板，以及是否有定義在有意義指標上的警報？
7. CloudTrail 與 CloudTrail Lake 查詢 — 查詢過去 30 天內 root 使用者和特權角色的控制台登入，以衡量治理衛生狀況。
8. Cost Explorer 與 CUR — 營運效率低下與成本異常相關；NAT Gateway 帳單激增可能是缺少 VPC endpoints 的症狀。
9. Well-Architected Tool 審查 — 對工作負載執行 Well-Architected 審查，聚焦在卓越營運支柱，並將高風險問題捕捉為 OpsItems。

這個稽查模式本身就是一項卓越營運能力——你應該能在一小時內執行它，以產出改善計畫。在 SAP-C02 中，稽查式問題會列舉其中幾個來源，並問哪一個用於特定問題（「哪裡可以找到最小權限角色分析？」→ IAM Access Analyzer；「哪裡可以找到未使用的 Elastic IPs？」→ Trusted Advisor；「哪裡可以找到前 10 名貢獻者 IPs？」→ Contributor Insights）。

改善指標 — 將營運與業務連結

卓越營運改善只有在與主管們出資的指標掛鉤時才具可讀性。Pro 架構師追蹤四個受 DORA 啟發的指標加上三個業務可見的 SLO：

• 部署頻率 — 每天部署次數。目標：從每季到每天。
• 變更失敗率 — 被回滾的部署百分比。目標：低於 15%。
• 平均恢復時間（MTTR） — 從偵測到解決的時間。目標：分鐘，而非小時。
• 變更前置時間 — 從提交到生產環境。目標：小時，而非週。
• 可用性 SLO — 一段時間內成功請求的百分比；與錯誤預算掛鉤。
• 延遲 SLO — p99 在閾值內；與使用者體驗掛鉤。
• 業務影響指標 — 例如結帳轉換率——以業務語言展示營運健康狀況。

CloudWatch 是 SLO 指標的來源。CodeDeploy 和 CodePipeline 發出部署頻率和變更失敗率。Incident Manager 的時間軸提供 MTTR。將這些發佈到與管理層共享的 Managed Grafana 儀表板，在營運與業務成果之間建立一致性。

常見陷阱 — 卓越營運改善

陷阱一：提議改寫，而答案應是可觀測性

SAP-C02 最高等級的陷阱：情境描述了一個痛苦的棕地系統，錯誤答案是「遷移到無伺服器 Lambda + API Gateway」。正確的第一步是可觀測性，因為改寫是一個多季度的專案，而可觀測性改造只需要數天到數週。改寫是後來的事，而且需要有證據支持。

陷阱二：混淆 Config 與 SCP

AWS Config 是偵測性的——它在事後記錄並評估狀態。SCP 是預防性的——它在組織邊界拒絕 API 呼叫。「用 Config 阻止建立公開 S3 bucket」是錯的；Config 只能偵測和修復。若要預防，需要 SCP 或 CloudFormation Hook。

陷阱三：該用 AppConfig 時用了 Parameter Store

Parameter Store 是帶版本管理的靜態設定；AppConfig 增加了漸進推出、驗證和警報觸發自動回滾。若情境要求有漸進推出和安全部署的功能旗標，答案是 AppConfig，不是 Parameter Store。

陷阱四：從管理帳號執行營運工具

從 Organizations 管理帳號執行 Systems Manager、OpsCenter 或 Incident Manager 是反模式。使用委派管理員模型——通常委派到 Audit 或 Shared Services 帳號——用於 Systems Manager、Config aggregator 和 Security Hub，讓日常營運工作不需要管理帳號憑證。

陷阱五：Session Manager 沒有先決條件

Session Manager 需要 SSM Agent + AmazonSSMManagedInstanceCore IAM 角色 + 連到 ssm、ssmmessages、ec2messages 端點的對外網路路徑。私有子網路中沒有 NAT Gateway 或 VPC endpoints 的執行個體會靜默失敗。說「只要在控制台啟用 Session Manager」而不解決這些先決條件的考試答案是不完整的。

陷阱六：CloudWatch Logs Insights 不是即時的

Logs Insights 按需執行查詢；它不是串流查詢引擎。若題幹需要持續的前幾名監控，選 Contributor Insights。若需要即時串流，選 Kinesis Data Firehose 搭配 OpenSearch 或 Lambda subscription filter。

陷阱七：自動回滾需要領先指標的警報

CodeDeploy 回滾在 CloudWatch 警報上觸發，但若警報是在落後指標上（事後的帳單錯誤），回滾觸發得太晚。警報必須在領先指標上——請求錯誤率、p99 延遲、健康檢查失敗——這些指標在部署烘焙期內就會發生變化。

陷阱八：X-Ray 預設取樣遮蓋了問題

預設 X-Ray 取樣追蹤每秒 1 個請求加上額外請求的 5%。對於低流量的關鍵端點，預設率可能漏掉那個罕見的失敗請求。針對錯誤回應設定 100% 取樣，並對優先端點提高取樣率。

陷阱九：Incident Manager 需要 EventBridge 路由

Incident Manager 不直接監控 CloudWatch 警報；它在被呼叫時執行回應計畫。接線方式是 CloudWatch alarm → EventBridge rule → Incident Manager response plan。暗示 Incident Manager「監視指標」的答案是錯的。

陷阱十：AWS Chatbot 沒有 SNS 就無法路由出站

AWS Chatbot 消費來自 SNS 或 CloudWatch Events/EventBridge 的事件。它不輪詢 API。若情境說「將 CloudWatch 警報路由到 Slack」，路徑是 Alarm → SNS topic → Chatbot → Slack。警報直接到 Chatbot 的整合不存在。

卓越營運改善 — 決策矩陣

FAQ — 卓越營運改善常見問題

Q1：在沒有可觀測性的棕地 AWS 工作負載中，如果只能修一件事，應該先修什麼？

在每台執行個體上安裝 CloudWatch agent 和 SSM agent，並建立第一個 CloudWatch 儀表板，加上幾個在客戶可見訊號上的警報（ALB 5xx 率、p99 延遲、資料庫連線飽和度）。沒有指標和日誌，你無法診斷任何其他事情，所以可觀測性永遠優先於修復。在 SAP-C02 中，「改善卓越營運，起始步驟」的問題，若選項同時包含可觀測性和某個後續步驟（CodeDeploy、Incident Manager、AppConfig），幾乎都預期可觀測性優先。大規模安裝兩個 agent 最快的方式，是透過 Systems Manager Run Command 使用 AWS-ConfigureAWSPackage 和 AmazonCloudWatch-ManageAgent 文件，之後透過 State Manager associations 強制執行。State Manager association 也能修復 agent 漂移，若有人停止了程序或回滾了 AMI。

Q2：什麼時候應該選擇 Amazon Managed Grafana 而非原生 CloudWatch 儀表板？

當儀表板必須結合 CloudWatch 無法原生讀取的來源時，或當團隊已標準化 Grafana UX 時，選擇 Managed Grafana。CloudWatch 儀表板支援 CloudWatch 指標、CloudWatch Logs Insights 查詢和 X-Ray 追蹤，但不支援 Prometheus、OpenSearch、Athena、Timestream 或第三方 SaaS（如 Datadog 或 New Relic）。Managed Grafana 支援所有這些，以及透過 IAM Identity Center 的 SAML SSO、細粒度的團隊權限和警報。若情境提到 Prometheus 或跨雲或第三方，就是 Managed Grafana。若情境是「單一團隊、只有 CloudWatch 的工作負載、最小化成本」，CloudWatch 儀表板就足夠了。在 Pro 考試中，「橫跨多個 AWS 帳號和現有 Prometheus cluster 的單一視窗」情境，毫無疑問是 Managed Grafana 搭配 Amazon Managed Service for Prometheus。

Q3：如何在不破壞任何事情的情況下，消除 500 台執行個體機群中的 SSH？

使用 Systems Manager Session Manager 作為替換。遷移步驟：（1）確認每台執行個體都有 SSM Agent 在運行，且有附帶 AmazonSSMManagedInstanceCore 的 IAM instance profile；（2）確認對外網路能存取 SSM、SSMMESSAGES 和 EC2MESSAGES 端點，私有子網路執行個體可透過 NAT Gateway 或 VPC interface endpoints；（3）設定以 KMS 加密的 session 錄製到 S3 和 CloudWatch Logs；（4）透過 Identity Center permission sets（以資源標籤為範圍）授予操作員 IAM 權限以啟動 session；（5）移除允許 port 22 入站的安全群組規則，並刪除 bastion host。Session Manager session 透過 AWS API 進行，因此沒有公開端點、沒有要輪換的 SSH 金鑰，每個指令都透過 CloudTrail 和 session logs 稽核。在 SAP-C02 中，Session Manager 是「消除 SSH 同時保留緊急應對時的互動存取」的標準答案。

Q4：AWS 端對端事故回應自動化的正確接線方式是什麼？

慣用的接線方式是：CloudWatch alarm 偵測條件 → EventBridge rule 透過輸入轉換路由狀態變更事件 → 規則有多個目標：SNS topic 用於人工通知（AWS Chatbot 訂閱以發送到 Slack 或 Teams）、SSM Automation runbook 用於自動的第一次接觸修復（例如重啟服務），以及 Systems Manager Incident Manager response plan，開啟事故、依聯繫計畫傳呼值班人員、透過 Chatbot 開啟作戰室聊天頻道，並附上建議的 Runbook。對於不那麼嚴重的警報，可以跳過 Incident Manager，只通知 SNS。對於更複雜的邏輯，在 EventBridge 和下游目標之間插入 Lambda 以分類嚴重性並進行不同路由。AWS Chatbot 支援直接從 Slack 頻道執行已核准的 SSM 指令，操作員無需切換到控制台就能採取行動——IAM 控制哪些指令被允許。此模式是 Pro 等級的標準，是「最小化自訂程式碼的整合事故回應」情境的答案。

Q5：AWS AppConfig 與 Parameter Store 有何不同，各自何時選用？

Parameter Store（Systems Manager 的一部分）儲存含版本管理的命名參數，包括 SecureString 加密參數。應用程式在啟動時（或定期輪詢）取得參數。Parameter Store 適合靜態設定、無法使用 Secrets Manager 的服務的密鑰，以及 CloudFormation 參數解析。AWS AppConfig 專為動態設定和功能旗標而設計。AppConfig 增加了有版本的設定 profiles、在部署到目標之前必須通過的驗證器（JSON schema 或 Lambda）、漸進推出策略（線性、指數，在指定的持續時間內），以及推出期間若 CloudWatch 警報觸發時的自動回滾。AppConfig 的客戶端 SDK 輪詢更新並以最短延遲傳遞。選 Parameter Store 用於「儲存一個字串並取得它」；選 AppConfig 用於「以可控推出和安全警報變更功能旗標」。在 SAP-C02 中，當題幹說「漸進啟用生產環境的新功能，並在錯誤率激增時自動回滾」，答案是 AppConfig。當說「為 Lambda 函數儲存資料庫連線字串」，Parameter Store 就足夠了。

Q6：我可以從 Organizations 管理帳號執行卓越營運工具嗎？

技術上可以，但這是 Pro 考試特別測試的反模式。管理帳號有更高的爆炸半徑，應執行最少的工作負載。改用委派管理員到一個專用成員帳號（通常是 Audit 或 Shared Services 帳號），用於 Systems Manager（透過 Systems Manager Quick Setup 多帳號）、AWS Config aggregator、Security Hub、GuardDuty、Incident Manager 和 CloudFormation StackSets 服務管理模式。日常營運工作在委派管理員帳號進行。管理帳號限制在 Identity Center 管理、組織範圍的政策變更，以及緊急應對存取。任何從管理帳號執行安全或營運工具的 SAP-C02 答案都是錯的；正確答案永遠指定委派管理員到指定的成員帳號。

Q7：如何確保每個新帳號自動取得可觀測性、修補程式管理和事故回應的基線？

使用三層方法。（1）AWS Control Tower 搭配 Account Factory Customization (AFC)，在帳號建立時以基線 VPC、IAM 角色和 SSM 設定引導新帳號。（2）CloudFormation StackSets 搭配服務管理式權限，以及自動部署目標為工作負載 OUs，部署 Parameter Store 中的 CloudWatch agent 設定、IAM instance profile policy、SSM Patch Manager 基線和 Maintenance Windows、Config 規則，以及路由到中央 SNS/Incident Manager 的 EventBridge 規則。（3）Systems Manager Quick Setup 搭配 Organizations 整合，在整個 Organization 的所有帳號中部署 Inventory、Explorer、Patch Manager 主機管理和預設 Automation runbook 權限。加入 OU 的新帳號自動繼承所有三層——可觀測性、修補程式管理和事故回應基線從帳號的第一個小時就已就位。

Q8：如何在生產工作負載上安全地執行混沌工程？

使用 AWS Fault Injection Service (FIS) 搭配停止條件作為安全網。每個 FIS 實驗範本都應包含：（1）明確限定 FIS 可接觸哪些資源的 IAM 角色；（2）以標籤定義的資源目標，避免爆炸半徑擴大；（3）一個或多個停止條件——若在實驗期間觸發的 CloudWatch 警報，自動停止並復原實驗；（4）明確限定範圍的實驗持續時間（通常 10-30 分鐘）；（5）排定實驗後審查以捕捉發現。常見的生產實驗：AZ 故障模擬（停止所有標記 az=X 的執行個體）、RDS 容錯移轉、API 延遲注入、ECS 上的程序終止、停用 SSM Agent 以模擬監控盲點。停止條件讓生產混沌實驗安全可行，因為任何客戶可見的 SLO 違規都會立即結束實驗。在 SAP-C02 中，FIS 是「如何驗證營運準備度？」和「如何在有安全網的情況下執行韌性演練？」的 Pro 等級答案。