AWS Systems Manager Incident Manager 不再開放給新客戶。現有客戶可以繼續正常使用該服務。如需詳細資訊，請參閱[AWS Systems Manager Incident Manager 可用性變更](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html)。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Incident Manager 中的事件生命週期
<a name="incident-lifecycle"></a>

AWS Systems Manager Incident Manager 根據最佳實務提供step-by-step架構，以識別和回應事件，例如服務中斷或安全威脅。Incident Manager 的主要重點是協助透過完整的事件生命週期管理解決方案，盡快將受影響的服務或應用程式還原至正常狀態。

如下圖所示，Invent Manager 為事件生命週期的每個階段提供工具和最佳實務：
+ [提醒和參與](#alerting-engagement)
+ [分類](#triage)
+ [調查和緩解](#investigation-mitigation)
+ [事後分析](#lifecycle-post-incident-analysis)

![\[事件生命週期包括提醒、參與、分類、調查和分析。\]](http://docs.aws.amazon.com/zh_tw/incident-manager/latest/userguide/images/incident-lifecycle.png)


## 提醒和參與
<a name="alerting-engagement"></a>

事件生命週期的提醒和參與階段著重於將意識帶入應用程式和服務內的事件。此階段會在偵測到事件之前開始，且需要深入了解您的應用程式。您可以使用 [Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)來監控應用程式效能的資料，或使用 [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/) 彙整來自不同來源、應用程式和服務的提醒。設定應用程式監控之後，您可以開始提醒偏離歷史常態的指標。若要進一步了解監控最佳實務，請參閱 [監控](incident-response.md#incident-response-monitoring)。

若要支援回應者的事件診斷，您可以在 Incident Manager 中啟用調查結果功能。調查結果是有關事件發生前後發生的 AWS CodeDeploy 部署和 AWS CloudFormation 堆疊更新的資訊。擁有此資訊可縮短評估潛在原因所需的時間，進而減少從事件復原的平均時間 (MTTR)。

現在您正在監控應用程式中的事件，您可以定義事件*回應計劃*，以便在事件期間使用。若要進一步了解如何建立回應計劃，請參閱 [在 Incident Manager 中建立和設定回應計劃](response-plans.md)。Amazon EventBridge 事件或 CloudWatch Alarms 可以使用 搭配回應計劃作為範本來自動建立事件。若要進一步了解事件建立，請參閱 [在 Incident Manager 中自動或手動建立事件](incident-creation.md)。

回應計劃會啟動相關的*呈報計劃*和*參與計劃*，將第一個回應者帶入事件。如需設定升級計劃的詳細資訊，請參閱[建立呈報計畫](escalation.md#escalation-create)。同時，聊天應用程式中的 Amazon Q Developer 會使用聊天*管道*通知回應者，引導他們前往事件詳細資訊頁面。使用聊天管道和*事件詳細資訊*，團隊可以溝通和分類事件。如需在 Incident Manager 中設定聊天頻道的詳細資訊，請參閱 [任務 2：在聊天應用程式中在 Amazon Q Developer 中建立聊天頻道](chat.md#chat-create)。

## 分類
<a name="triage"></a>

分類是指第一個回應者嘗試判斷對客戶的影響。Incident Manager 主控台中的事件詳細資訊檢視會提供回應者時間表和指標，以協助他們評估事件。評估事件的影響也為事件的回應時間、解決方案和通訊奠定了基礎。回應者使用影響評分從 1 （關鍵） 到 5 （無影響） 來排定事件的優先順序。

您的組織可以定義每個影響評分的確切範圍，無論您選擇的為何。下表提供通常如何定義每個影響層級的範例。


| 影響碼 | 影響名稱 | 範例定義的範圍 | 
| --- | --- | --- | 
| 1 | Critical |  影響大多數客戶的完整應用程式故障。  | 
| 2 | High |  影響客戶子集的完整應用程式故障。  | 
| 3 | Medium |  部分應用程式故障會影響客戶。  | 
| 4 | Low |  對客戶影響有限的間歇性故障。  | 
| 5 | No Impact |  客戶目前沒有受到影響，但需要採取緊急動作以避免影響。  | 

## 調查和緩解
<a name="investigation-mitigation"></a>

*事件*詳細資訊檢視可為您的團隊提供 Runbook、時間表和指標。若要了解如何使用事件，請參閱 [在主控台中檢視事件詳細資訊](tracking.md#tracking-details)。

*Runbook *通常提供調查步驟，並且可以自動提取資料或嘗試常用的解決方案。Runbook 也提供明確、可重複的步驟，讓您的團隊發現這些步驟有助於緩解事件。Runbook 索引標籤著重於目前的 Runbook 步驟，並顯示過去和未來的步驟。

Incident Manager 與 Systems Manager Automation 整合，以建置 Runbook。使用 Runbook 執行下列任何動作：
+ 管理執行個體 AWS 和資源
+ 自動執行指令碼
+ 管理 CloudFormation 資源

如需支援動作類型的詳細資訊，請參閱*AWS Systems Manager 《 使用者指南*》中的 [Systems Manager Automation 動作參考](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)。

**時間軸**索引標籤會顯示已採取的動作。時間軸會使用時間戳記記錄每個 ，並自動建立詳細資訊。若要將自訂事件新增至時間軸，請參閱本使用者指南*的事件詳細資訊*頁面中的[時間軸](tracking.md#tracking-details-timeline)一節。

**診斷**索引標籤會顯示自動填入的指標和手動新增的指標。此檢視會在事件期間提供寶貴的應用程式活動資訊。

**參與**索引標籤可讓您將其他聯絡人新增至事件，並協助為參與的聯絡人提供資源，以便在事件發生後快速趕上進度。聯絡人是透過定義的呈報計畫或個人參與計畫來參與。

使用*聊天頻道*，您可以直接與事件和團隊中的其他回應者互動。在聊天應用程式中使用 Amazon Q Developer，您可以在 Slack、 Microsoft Teams和 Amazon Chime 中設定聊天頻道。在 Slack和 Microsoft Teams頻道中，回應者可以使用多個`ssm-incidents`命令，直接從聊天頻道與事件互動。如需詳細資訊，請參閱[透過聊天頻道互動](chat.md#chat-interact)。

## 事後分析
<a name="lifecycle-post-incident-analysis"></a>

Incident Manager 提供架構，用於反映事件、採取必要步驟，防止事件在未來再次發生，並改善整體的事件回應活動。改善項目可能包括：
+ 事件中涉及的應用程式變更。您的團隊可以利用這段時間來改善系統，並提高容錯能力。
+ 事件回應計劃的變更。花時間納入學到的教訓。
+ Runbook 的變更。您的團隊可以深入探討解決方案所需的步驟，以及您可以自動化的步驟。
+ 提醒的變更。事件發生後，您的團隊可能注意到指標中的關鍵點，您可以使用這些指標來更快地提醒團隊有關事件的事項。

Incident Manager 透過使用一組事後分析問題和動作項目，以及事件時間表，來促進這些潛在的改進。若要進一步了解透過分析改善，請參閱 [在 Incident Manager 中執行事件後分析](analysis.md)。