Systems Manager Incident Manager 和 AWS Health 是 DOP-C02 中事件與異常回應的人為端。當 EventBridge 自動補救在無需人為干預的情況下完成閉環時，Incident Manager 則負責在需要時正確地介入人力 —— 呼叫正確的輪值人員、開啟共享聊天頻道、附加正確的執行手冊、在第一回應者未確認時向上級升級，並記錄事後檢討所需的事件時間軸。AWS Health 是影響你帳戶的 AWS 側事件的入站來源：排定的維護、區域內的服務降級、過時通知、EC2 執行個體停用、憑證過期。這兩項服務共同協作：Health 發布事件，EventBridge 進行路由，而 Incident Manager 激活回應計劃，呼叫你的團隊並追蹤回應。
本指南假設你了解基本的值班概念（輪替、升級、呼叫）和基本的 Systems Manager。重點在於 DOP-C02 的實作深度：Incident Manager 回應計劃 (response plans)、參與計劃 (engagement plans)、升級計劃 (escalation plans)、聯絡人、聊天頻道（透過 AWS Chatbot 的 Slack 和 Microsoft Teams）、包含時間軸和事件後分析的事件紀錄、附加到回應計劃以引導執行的執行手冊 (runbook)、AWS Health Dashboard 的個人狀況 (Personal Health，單個帳戶事件) vs 服務狀況 (Service Health，全球服務狀態)、用於跨帳戶彙整的 AWS Health 組織視圖、AWS Health API 程式化存取（僅限商業與企業級支援）、aws.health 事件的 EventBridge 整合、作為事件閾值下方的工單主力 OpsCenter，以及自動補救、OpsItems 與完整事件 (incidents) 之間的關係。網域 5.1（管理事件源以進行處理、通知和採取行動）和網域 5.3（對系統和應用程式故障進行疑難排解）是此內容的涵蓋範圍。
為什麼 Incident Manager 與 AWS Health 對 DOP-C02 很重要
DOP-C02 考試指南明確將「AWS Health」與 EventBridge 及 CloudTrail 列為 DevOps 工程師必須整合的三個事件源。多份考後報告指出，AWS Health 和 Incident Manager 在第三方準備材料中往往被忽視 —— 而這正是考試喜歡測試的領域。這裡的考試風格是整合架構：入站的 Health 事件如何轉化為呼叫鏈，以喚醒帶著正確執行手冊的工程師，以及如何在無需手動文書工作的情況下捕捉回應過程以進行事後檢討？
典型的 DOP-C02 題幹如下：「AWS 宣布對 3 個帳戶中的 12 個 EC2 執行個體發布停用通知。平台團隊需要自動收到呼叫，並自動創建聊天頻道進行協調，同時開啟一個類似 Jira 的工單進行追蹤。」錯誤答案通常集中在自定義 Lambda + 自定義呼叫整合。正確答案是 AWS Health 組織視圖 作為彙整器，組織層級的 EventBridge 規則匹配 aws.health 的 EC2 Instance Retirement Scheduled 事件，目標為 Incident Manager 回應計劃，該計劃啟動平台值班人員的參與計劃，透過 AWS Chatbot 開啟聊天頻道，在 OpsCenter 中創建 OpsItem，並（選配）啟動負責排乾 (drain) 並更換受影響執行個體的 SSM 自動化執行手冊。考試測試你是否知道這些組件的存在以及它們如何連接。
- Incident Manager：用於事件回應的 AWS Systems Manager 組件 —— 包含回應計劃、聯絡人、升級、呼叫、聊天頻道、事件後分析。
- 回應計劃 (Response plan)：定義當事件發生時該做什麼的配置 —— 標題範本、嚴重性、參與、執行手冊、聊天頻道。
- 參與計劃 (Engagement plan)：按順序嘗試並帶有時間延遲的一系列聯絡管道（簡訊、語音、電子郵件、聊天機器人）。
- 升級計劃 (Escalation plan)：多階段的參與，每個階段有多個聯絡人，並具備可配置的進程規則。
- 聯絡人 (Contact)：Incident Manager 中的個人或團隊身分，具備一個或多個聯絡管道（電話、電子郵件、簡訊）。
- 事件紀錄 (Incident record)：帶有時間軸、參與情況、執行手冊執行情況和事件後分析的已創建事件。
- 聊天頻道 (Chat channel)：透過 AWS Chatbot 將事件連接到 Slack 或 Microsoft Teams 頻道的 Incident Manager 構件。
- 事件後分析 (Post-incident analysis, PIA)：附加到事件的結構化審查文件，包含時間軸、貢獻因素、行動項目的章節。
- AWS Health：發布有關影響你帳戶的 AWS 基礎設施事件的服務。
- 個人狀況儀表板 (Personal Health Dashboard, PHD)：該帳戶可見的單個帳戶事件。
- 服務狀況儀表板 (Service Health Dashboard, SHD)：公共的、全 AWS 範圍的服務狀態頁面。
- AWS Health 組織視圖 (Organizational View)：在組織中所有帳戶彙整的狀況事件，可從管理帳戶或委派管理員帳戶查看。
- AWS Health API：程式化獲取事件的接口（僅限商業與企業級支援）。
- OpsCenter / OpsItem：輕量級的工單構件，嚴重性低於事件 (incident)。
- 參考資料：https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html
白話文解釋 Incident Manager 與 AWS Health
值班回應領域在概念上很熟悉，但 AWS 特有的連接方式往往會讓工程師感到困惑。三個類比可以釐清各個部分。
類比 1：醫院急救小組 (Code Team)
想像醫院對病人病情惡化的反應。心臟監測器（CloudWatch 警報）觸發「藍色代碼」(Code Blue)（EventBridge 事件），激活了藍色代碼小組回應計劃 (Incident Manager 回應計劃)。計劃透過醫院的呼叫系統派遣：首先是值班住院醫師（參與計劃第 1 階段，簡訊）；如果 2 分鐘內未確認，則呼叫心臟科研究員（第 2 階段，語音電話）；如果仍無回應，則呼叫主治醫師（第 3 階段，升級）。自動創建了一個藍色代碼聊天頻道 (Incident Manager 聊天頻道，透過 AWS Chatbot)，並在團隊平板電腦上調出了復甦執行手冊 (附加到回應計劃的 SSM 自動化文件)。事件解決後，主治醫師領導一場發病率與死亡率會議 (M&M conference)，記錄時間軸、貢獻因素和流程改進行動（事件後分析）。在此類比中，AWS Health 是醫院的傳染病警示系統 —— 在任何個體病人發生代碼之前，它會告訴你「社群中正在流行一種新變種」（區域性的服務降級）。聰明的醫院會將警示整合到回應計劃中：如果代碼發生在社群疫情期間，計劃會自動分支出來增加傳染病防護措施。
類比 2：消防局調度
當煙霧警報器響起（CloudWatch 警報）時，大樓的火警面板會撥打 911（EventBridge → Incident Manager）。調度員激活了火災回應計劃，該計劃按位置和嚴重性進行路由：最近的消防隊（參與計劃第 1 階段），如果是多級火警則由第二家消防局支援（升級）。現場指揮部開啟一個專用無線電頻道 (Incident Manager 聊天頻道)，並調出大樓預案執行手冊，顯示樓層平面圖、危險材料、消防栓位置和截止閥（帶有相關上下文的 SSM 自動化文件）。火撲滅後，隊長編寫事故報告，包括原因、時間軸、回應績效和建議（事件後分析）。AWS Health 相當於國家氣象局的紅旗警報 —— 「今日全區極度火災危險」。消防局在收到這些警告時會調整人員配置並預先部署資源。AWS DevOps 團隊在收到 AWS Health 的「us-east-1 錯誤率增加」事件時，也會調整監控並預先部署執行手冊。
類比 3：飛機轉降期間的航空公司營運中心
飛機在飛行途中出現機械問題（服務警報）。機師聯絡調度中心 (EventBridge)，調度中心激活轉降回應計劃。調度中心參與：當值營運總監（第 1 階段）、轉降機場的維護中心（第 2 階段）、乘客服務團隊（第 2 階段並行），如果轉降到需要與領事館協調的國外則升級到營運副總裁（升級第 3 階段）。開啟了一個專用通訊橋樑 —— 機師、維護、營運、客戶服務都在同一個頻道上（聊天頻道）。開啟了轉降執行手冊：文書工作、海關、飯店安排、重新訂位（SSM 自動化執行手冊，包含大部分資訊步驟和一些自動化步驟如訂位通知）。飛機安全落地後，安全團隊為監管機構編寫事故報告（事件後分析）。AWS Health 是 FAA 的航行通告 (NOTAMs) 饋送 —— 「JFK 的 27R 跑道於 14:00-18:00 UTC 因維修關閉」。航空公司的營運儀表板整合了 NOTAMs 並自動調整排程；AWS DevOps 團隊整合了 Health 事件並自動調整部署窗口。
對於以「觸發警報並呼叫帶著正確執行手冊的正確人員」為核心的 DOP-C02 題目，請參考醫院急救小組類比。對於以「跨團隊的多級升級」為核心的題目，請參考消防局類比。對於以「觸發主動回應的 AWS 基礎設施事件」為核心的題目，請參考航空公司營運中心類比。參考資料：https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html
Incident Manager 回應計劃組成
回應計劃是核心範本。組件包括：
標題與嚴重性
支援事件創建時插值的自由文字標題範本 (Critical: API Latency High - {{IncidentId}})。嚴重性為 1-5，1 為最高。
參與 (Engagements)
每個計劃最多 5 個參與項目，每個參與項目可以是：
- 直接聯絡人（個人），或
- 聯絡群組（團隊），或
- 升級計劃（帶階段的序列）。
當事件開始時，所有參與項目會並行啟動（每個項目根據其參與計劃按順序呼叫其聯絡管道）。
聊天頻道
選配附加 AWS Chatbot 配置。當事件開始時，Incident Manager 會自動創建 Slack 或 Teams 頻道，並將事件更新、執行手冊進度以及團隊評論發布回時間軸。
執行手冊 (Runbook)
附加單個 SSM 自動化文件。執行手冊作為事件創建的一部分執行；工程師可以從事件主控台暫停、恢復和修改步驟。執行手冊的輸出會出現在時間軸中。
事件標籤與範本
附加到已創建的事件，用於篩選、搜尋和下游自動化。
觸發器
回應計劃觸發自：
- 帶有操作
arn:aws:ssm-incidents:::response-plan/...的 CloudWatch 警報。 - 目標為回應計劃 ARN 的 EventBridge 規則。
- 透過主控台或 API 手動創建。
- CodeDeploy 部署失敗（自動創建事件選項）。
參與計劃 — 呼叫序列
參與計劃定義了如何呼叫單個聯絡人。步驟範例：
- 發送簡訊到手機（延遲 0）。
- 撥打語音電話到手機（延遲 5 分鐘）。
- 發送電子郵件（延遲 10 分鐘）。
每個步驟都有聯絡管道、順序和延遲（從事件開始計的分鐘數）。一旦聯絡人透過任何管道確認，參與即停止。每個聯絡人都有自己的參與計劃。
升級計劃 — 跨聯絡人的階段劃分
升級計劃將多個聯絡人串連在一起，並具備進程規則。各個階段按順序運行；在一個階段內，所有聯絡人會並行接收呼叫。階段進程：
- 所有聯絡人均已確認：參與完成。
- 超時後無人確認：進入下一階段。
- 階段中有一人確認：可選擇要求所有人確認，或立即進入下一階段。
將升級計劃用於「一線值班 → 二線值班 → 經理」模式。
一個常見的 DOP-C02 混淆：考生認為回應計劃的 5 個參與項目是按順序排列的。其實它們是並行的 —— 事件開始時所有 5 個都會觸發。若要實現跨團隊的順序階段，請將它們封裝在一個具有明確階段的升級計劃中。正確模式：回應計劃參與 = 「平台值班升級」；內部的升級計劃包含第 1 階段（一線）、第 2 階段（二線，5 分鐘後）、第 3 階段（經理，10 分鐘後）。參考資料：https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html
透過 AWS Chatbot 整合聊天頻道
AWS Chatbot 將 AWS 服務橋接到 Slack 和 Microsoft Teams。對於 Incident Manager：
- 配置 Chatbot 與 Slack/Teams 工作區和目標頻道。
- 在 Incident Manager 中創建參照 Chatbot 配置的聊天頻道。
- 將聊天頻道附加到回應計劃。
當事件創建時，Chatbot 可以發布到現有頻道，或自動創建一個按事件劃分的頻道（可配置）。機器人發布：
- 事件開啟/關閉事件。
- 參與確認情況。
- 執行手冊步驟進度。
- 添加到時間軸的評論。
工程師可以將評論發布回頻道，Incident Manager 會將其記錄在時間軸中。
AWS Health — 入站事件饋送
AWS Health 發布三個類別的事件：
異常事件 (Issue events)
影響你資源的即時服務問題。範例：
- 區域內錯誤率增加。
- 服務的連通性問題。
- 效能降級。
排定的變更事件 (Scheduled change events)
影響你資源的即將到來的維護。範例：
- EC2 執行個體排定停用。
- RDS 資料庫升級時段。
- Certificate Manager 自動續約失敗。
- IAM 存取金鑰輪換提醒。
帳戶通知 (Account notifications)
帳戶特定通知：配額增加、帳單警示、濫用報告、安全最佳實務提醒。
個人狀況 vs 服務狀況儀表板
- 個人狀況儀表板 (PHD) 是按帳戶劃分的；它僅顯示影響你特定資源的事件。免費。
- 服務狀況儀表板 (SHD) 是全 AWS 範圍的服務狀態頁面。非帳戶特定。
DOP-C02 考試測試 個人狀況是正確的來源，用於帳戶特定的自動化；SHD 僅供參考。
組織視圖 (Organizational View)
AWS Health 組織視圖將組織中每個成員帳戶的事件彙整到管理帳戶或委派管理員帳戶中。在 Organizations 層級啟用；為平台團隊提供查看所有受影響帳戶的單一主控台。
AWS Health API
Health API 需要商業或企業級支援計劃。用於程式化事件檢索和篩選。基本或開發者級支援無法使用。
常見的 DOP-C02 陷阱：考生設計了一個自定義 Lambda 輪詢 AWS Health API 以進行主動事件處理，卻沒意識到客戶使用的是不提供該 API 的開發者級支援計劃。修復方法：使用在所有支援層級（包含免費）都能運作的 EventBridge，它會浮現 Health 事件，並讓 EventBridge 路由到你的處理程序。只有在大批量歷史檢索時才需要 Health API，而大多數情況並不需要。參考資料：https://docs.aws.amazon.com/health/latest/ug/health-api.html
EventBridge 的 Health 整合
AWS Health 將事件發布到預設的 EventBridge 匯流排，其 source 為 aws.health。常見的 detail-types：
AWS Health Event（異常）。AWS Health Abuse Event（濫用）。- 詳情中包含
service、eventTypeCode、eventTypeCategory、affectedEntities、region。
模式範例：
- 匹配所有 EC2 停用通知：
{"source": ["aws.health"], "detail": {"service": ["EC2"], "eventTypeCategory": ["scheduledChange"]}}。 - 匹配全區域問題：
{"source": ["aws.health"], "detail": {"eventTypeCategory": ["issue"]}}。
目標通常包括 Incident Manager 回應計劃、用於自定義邏輯的 Lambda、用於人為通知的 SNS、用於創建工單的 OpsCenter。
OpsCenter — 閾值以下的工單
OpsCenter 保存不值得啟動完整事件回應的問題的 OpsItems。範例：
- Config 規則不合規發現（在嘗試自動補救後）。
- 低嚴重性的 GuardDuty 發現。
- 需要審查的 AWS Health 排定變更事件。
- 失敗的管道執行。
OpsItems 具有嚴重性、狀態（開啟/進行中/已解決）、指派人員、相關資源和執行手冊建議。DOP-C02 考試模式：自動補救完全成功 → 無 OpsItem；部分成功或需要人為審查 → OpsItem；影響生產的緊急情況 → Incident Manager 事件。
事件後分析 (PIA)
事件解決後，Incident Manager 會生成一個 PIA 範本，包含：
- 時間軸（從事件時間軸自動填充）。
- 貢獻因素。
- 解決方案。
- 經驗教訓。
- 帶有負責人和截止日期的行動項目。
行動項目可以與 Jira、ServiceNow 或 OpsCenter 整合以進行追蹤。PIA 可在團隊內搜尋，並成為制度化知識。
- 帶有插值的標題範本。
- 嚴重性 1-5。
- 參與項目（最多 5 個，並行）。
- 透過 AWS Chatbot 的聊天頻道 (Slack/Teams)。
- 執行手冊（附加單個 SSM 自動化文件）。
- 用於篩選和下游自動化的標籤。
- 帶有預設摘要的事件範本。 觸發器：CloudWatch 警報操作 ARN、EventBridge 規則目標 ARN、手動 API 調用、CodeDeploy 自動創建選項。參與計劃針對每個聯絡人按順序運行（簡訊 → 語音 → 電子郵件且帶有延遲）。升級計劃跨多個聯絡人按順序運行階段。參考資料：https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html
高頻考試陷阱
陷阱 1：參與項目是並行的，而非按順序的
回應計劃上的 5 個參與項目會同時啟動。若要進行跨團隊的順序呼叫，請使用具有明確階段的升級計劃。
陷阱 2：個人狀況 vs 服務狀況
個人狀況是按帳戶劃分的 (PHD)。服務狀況是全球 AWS 範圍的狀態頁面 (SHD)。對於自動化，請透過 EventBridge 使用個人狀況。
陷阱 3：Health API 支援層級限制
Health API 需要商業或企業級支援。Health EventBridge 整合適用於所有層級，包括基本級。
陷阱 4：每個回應計劃一個執行手冊
回應計劃附加一個 SSM 自動化文件。若要運行多個按順序排列的執行手冊，請構建一個調用子手冊的父手冊，或使用 Step Functions。
陷阱 5：Incident Manager 是區域性的
Incident Manager 是一項按區域提供的服務。為了具備多區域就緒能力，請在各個區域配置回應計劃。有一個「複寫集」(replication set) 功能可跨區域同步配置。
陷阱 6：聊天頻道自動創建 vs 重用
聊天頻道可以是固定頻道（事件開始時所有人加入）或按事件劃分（自動創建並存檔）。按事件劃分對於事後檢討更清晰，但需要 Slack/Teams 管理員權限才能自動創建。
陷阱 7：OpsCenter vs Incident Manager 嚴重性
OpsItem 是輕量級工單；Incident Manager 事件是完整的呼叫與執行手冊活動。將雜訊歸類為事件會過度呼叫值班人員；將真實事件歸類為 OpsItems 則會延誤回應。
Incident Manager 本身是區域性服務。如果主要區域受損，你可能無法在該區域創建事件。解決方法是複寫集 —— 一個跨區域複寫 Incident Manager 狀態的區域清單。配置 2-3 個區域作為複寫集；回應計劃只需創建一次即可複寫。這是「如果呼叫系統本身所在的區域宕機了怎麼辦」的正確答案。參考資料：https://docs.aws.amazon.com/incident-manager/latest/userguide/replication-set.html
DOP-C02 考試模式與情境演練
情境 1：由 AWS Health 驅動的值班參與
題幹：「AWS 宣布對生產磁碟區進行 EBS 磁碟區排定維護；團隊需要自動收到呼叫並自動創建一個 Jira 工單。」正確：EventBridge 規則針對 aws.health 來源，篩選為 EBS scheduledChange，目標為 (1) 參與存儲值班人員的 Incident Manager 回應計劃，(2) 透過 API 目的地創建 Jira 工單的 Lambda。
情境 2：P1 故障的多階段升級
題幹：「當 API 錯誤率超過 5% 時，呼叫一線值班；如果 5 分鐘內未確認，則呼叫二線值班；如果再過 5 分鐘仍未確認，則呼叫經理。」正確：回應計劃配備升級計劃，第 1 階段 = 一線，第 2 階段 = 二線 (5 分鐘)，第 3 階段 = 經理 (10 分鐘)。
情境 3：由 CodeDeploy 失敗自動創建事件
題幹：「生產部署失敗必須立即觸發一個附加了部署執行手冊的事件。」正確：啟用 CodeDeploy 與 CloudWatch 警報的 Alarm 整合；警報操作觸發回應計劃，其附加的執行手冊為 AWS-RollbackDeployment 或自定義回滾文件。
情境 4：跨帳戶 AWS Health 彙整
題幹：「平台團隊需要查看 50 個成員帳戶的 Health 事件。」正確：在管理帳戶啟用 AWS Health 組織視圖；在管理/委派管理員帳戶的組織範圍匯流排上創建 EventBridge 規則。
情境 5：事件後行動項目追蹤
題幹：「事件解決後，團隊需要結構化的 PIA，並追蹤行動項目直至完成。」正確：使用 Incident Manager 內建的事件後分析範本，並將行動項目同步至 OpsCenter 或 Jira。
常見問題 (FAQ)
Q1：我何時該使用 OpsItem 或 Incident Manager 事件？
OpsItem 用於需要人為審查但不需要呼叫的低/中嚴重性問題。範例：Config 規則不合規（自動補救後）、用於未來計劃的 AWS Health 排定變更。Incident Manager 事件用於需要立即呼叫和執行執行手冊的影響生產的事件。
Q2：我如何將 Incident Manager 與 PagerDuty 或 Opsgenie 整合？
兩條路徑：(1) 直接使用 Incident Manager，因為它包含完整的呼叫功能 —— 除非你有它無法涵蓋的需求，否則無需 PagerDuty（供應商整合可降低成本）。(2) 保留 PagerDuty 作為呼叫平台；使用 EventBridge → API 目的地 → PagerDuty REST API 進行路由。在沒有特定的多廠商限制時，DOP-C02 考試更傾向於 AWS 原生答案 (Incident Manager)。
Q3：我可以將多個執行手冊附加到回應計劃嗎？
不行 —— 每個計劃一個文件。解決方法：構建一個父 SSM 自動化文件，使用 aws:executeAutomation 按順序調用子文件，或者使用 Step Functions 作為編排器並附加一個啟動狀態機的精簡執行手冊。
Q4：如果我的區域受損且我無法在該區域訪問 Incident Manager 怎麼辦？
使用跨 2-3 個區域的複寫集。Incident Manager 會跨區域複寫回應計劃、聯絡人和事件。當主要區域受損時，在複寫集的任何區域創建事件。
Q5：AWS Health 組織視圖與按帳戶劃分的個人狀況有何不同？
個人狀況顯示影響單個帳戶資源的事件。組織視圖將每個成員帳戶的個人狀況彙整到管理帳戶或委派管理員帳戶中。這是跨帳戶平台團隊可見性所必需的。
Q6：AWS Health 是否包含帳單或配額相關事件？
有 —— AWS Health 會發布服務配額接近警告、帳單異常警報、濫用通知和帳戶級別的安全最佳實務提醒。按 eventTypeCategory: accountNotification 進行篩選，以將這些事件與基礎設施事件分開路由。
Q7：我如何防止來自吵雜 Health 事件的警報疲勞？
在 EventBridge 規則層級進行篩選 —— 僅針對特定服務和 eventTypeCategory: issue 進行呼叫等級的匹配；將 scheduledChange 事件路由到 OpsCenter 進行無需呼叫的審查；存檔 accountNotification 事件以便每月審查。
交叉參照
- EventBridge 自動補救執行手冊涵蓋了 Incident Manager 回應計劃附加的 SSM 自動化模式；請參閱
eventbridge-auto-remediation-runbooks。 - CloudWatch 警報與 EventBridge 解釋了從警報到事件觸發鏈；請參閱
cloudwatch-alarms-eventbridge-integration。 - CloudTrail 與 Config 儀表板提供了事件時間軸參照的稽核追蹤；請參閱
cloudtrail-config-audit-dashboards。 - 部署失敗疑難排解在部署失敗升級為影響使用者的停機時使用 Incident Manager；請參閱
deployment-failure-troubleshooting。 - CloudWatch 指標與 Logs Insights 為事件時間軸和 PIA 根本原因分析提供資料；請參閱
cloudwatch-metrics-logs-insights。