

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

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

# 遷移指南
<a name="migration-guides"></a>

由於 AWS Systems Manager Incident Manager 不會再新增新的功能，因此請務必了解事件管理的替代方案。本節提供遷移指南，協助您從 Incident Manager 轉換到替代解決方案。

若要管理 AWS 基礎設施上的操作問題，建議您使用 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)。對於自動分頁和回應功能，我們建議[AWS 合作夥伴網路合作夥伴](https://partners.amazonaws.com/)提供的解決方案。 AWS 解決方案架構師和技術客戶經理將能夠根據您的特定需求，引導您選擇最適合的選項。

您也可以探索下列用於與合作夥伴解決方案整合的遷移指南：
+ [遷移至 AWS Systems Manager OpsCenter](migration-opscenter.md)
+ [遷移至 Jira Service Management](migration-jira.md)
+ [遷移至 ServiceNow](migration-servicenow.md)
+ [遷移至 PagerDuty](migration-pagerduty.md)

# 遷移至 AWS Systems Manager OpsCenter
<a name="migration-opscenter"></a>

本指南可協助您了解 Incident Manager 和 OpsCenter 之間的主要差異，以判斷 OpsCenter 是否符合您的營運需求，並提供從 AWS Systems Manager Incident Manager 遷移至 OpsCenter 的方法。

[AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 是 的一項功能 AWS Systems Manager，提供中央位置，讓營運工程師和 IT 專業人員可以檢視、調查和解決與 AWS 資源相關的操作工作項目 (OpsItems)。OpsCenter 旨在減少影響 AWS 資源的問題的平均解決時間 (MTTR)。OpsCenter 彙總和標準化跨 服務的 OpsItems同時提供每個 OpsItem、相關 OpsItems和相關資源的情境式調查資料。OpsCenter 與 Systems Manager Automation 整合，可讓您使用 Automation Runbook 來調查和解決問題。您可以依狀態和來源檢視自動產生的 OpsItems 摘要報告。您也可以使用 [OpsCenter 的跨帳戶](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-setting-up-cross-account.html)功能來集中管理跨帳戶的 OpsItems 

**注意**  
使用 OpsCenter 會產生相關費用。如需詳細資訊，請參閱 [AWS Systems Manager 定價頁面](https://aws.amazon.com/systems-manager/pricing/)。

與 Incident Manager 類似，OpsCenter 與 Amazon CloudWatch 和 Amazon EventBridge 整合。這表示您可以將這些服務設定為在 CloudWatch 警示進入 `ALARM` 狀態，或 EventBridge 從發佈事件的任何 處理事件時 AWS 服務 ，在 OpsCenter 中自動建立 OpsItemOpsItem 。設定 CloudWatch 警示和 EventBridge 事件以自動建立 OpsItems，可讓您快速診斷和修復來自單一主控台 AWS 的資源問題。

## 了解差異
<a name="opscenter-differences"></a>

AWS Systems Manager Incident Manager 提供事件回應功能，包括自動化回應計畫、回應者參與和呈報、通話中輪換管理、執行手冊自動化、聊天操作整合 (Slack、Microsoft Teams、Amazon Chime)，以及事件後分析。這些功能可協助組織協調和解決影響 AWS託管應用程式的關鍵、時間敏感事件。

相反地， AWS Systems Manager OpsCenter 專注於管理日常操作問題的操作工作項目 day-to-day (OpsItems)，例如安全提醒、效能降低、資源故障、運作狀態通知和狀態變更。OpsCenter 透過 Amazon CloudWatch 和 Amazon EventBridge 與 AWS 資源整合，使用 Systems Manager Automation Runbook 實現自動 OpsItem 建立和修復。OpsCenter 支援區域中 OpsItems 的跨帳戶管理，可讓營運團隊檢視、調查和解決多個 AWS 帳戶的問題。不過，OpsCenter 不包含分頁或通話中輪換功能。

這兩個 AWS 服務的主要差異在於其焦點和範圍。Incident Manager 專為關鍵、時間敏感的事件回應而設計，而 OpsCenter 則傾向於管理更廣泛的操作任務和工作項目。

下表比較 Incident Manager 和 OpsCenter 之間的主要功能。使用此比較來決定 OpsCenter 是否符合您的營運需求。


| 特徵/功能 | AWS Systems Manager Incident Manager | AWS Systems Manager OpsCenter | 
| --- | --- | --- | 
| 主要用途 | 關鍵、時間敏感的事件回應和協調 | Day-to-day操作工作項目管理 | 
| 使用案例 | 應用程式影響事件；安全漏洞；服務中斷；重大系統故障 | 安全提醒；效能降低；資源故障；運作狀態通知；狀態變更 | 
| 自動化分頁 | 是 - 內建分頁和回應者參與 | 否 - 需要第三方整合 (PagerDuty、ServiceNow、Jira) | 
| 隨時待命輪換管理 | 是 - 原生通話中排程和輪換 | 否 - 不支援 | 
| 呈報政策 | 是 - 自動化呈報鏈 | 否 - 需要手動呈報 | 
| Chat-Ops 整合 | 是 - Slack、Microsoft Teams、Amazon Chime | 有限 - 需要手動整合 | 
| Runbook 自動化 | 是 - 透過回應計劃自動執行 | 是 - 手動執行 Systems Manager Automation Runbook | 
| 跨帳戶管理 | 是 - 跨帳戶事件共用 | 是 - 區域內的跨帳戶 OpsItem 管理 | 

## 遷移選項
<a name="migration-options"></a>

如果您有現有的 CloudWatch 警示和 EventBridge 規則與 Incident Manager 整合，則需要更新這些警示和 EventBridge 規則，才能與 OpsCenter 整合。您可以使用下列其中一種方法遷移：

使用 Runbook 自動遷移  
使用 [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) Runbook 自動將 CloudWatch 警示和 EventBridge 規則從 Incident Manager 遷移至 OpsCenter。此方法包括備份、可設定的核准工作流程和詳細記錄。您可以選擇在遷移之前要求手動核准，或略過自動化大規模遷移的核准步驟。如需逐步說明，請參閱 [使用 OpsCenter 的遷移 Runbook](migration-opscenter-runbooks.md)。

手動整合  
手動設定 CloudWatch 警示和 EventBridge 規則，以與 OpsCenter 整合。如需說明，請參閱 Systems Manager 使用者指南中的[設定 CloudWatch 警示以建立 OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) 和[設定 EventBridge 以建立 OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-automatically-create-OpsItems-2.html)。

## 相關資源
<a name="related-resources-opscenter"></a>
+ [AWS Systems Manager OpsCenter 使用者指南](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [匯出 Incident Manager 資料](export-data.md)
+ [清除 Incident Manager 資源](migration-cleanup.md)

# 使用 OpsCenter 的遷移 Runbook
<a name="migration-opscenter-runbooks"></a>

本指南提供step-by-step說明，讓您使用自動化遷移執行手冊，將 Amazon CloudWatch 警示和 Amazon EventBridge 規則從 AWS Systems Manager Incident Manager 遷移至 AWS Systems Manager OpsCenter。

如需 OpsCenter 功能的概觀，以及了解 Incident Manager 和 OpsCenter 之間的差異，請參閱 [遷移至 AWS Systems Manager OpsCenter](migration-opscenter.md)。

## 遷移概觀
<a name="migration-overview"></a>

遷移程序使用 [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) Runbook 將您現有的 CloudWatch 警示和 EventBridge 規則與 OpsCenter 整合。此程序包含以下步驟：
+ **部署基礎設施** - 部署 CloudFormation 堆疊以建立遷移 Runbook 所需的資源。
+ **遷移 CloudWatch 警示和 EventBridge 規則** - 執行自動化 Runbook，將您的資源遷移至 OpsCenter。
+ **清除資源** - 選擇性地刪除複寫集和其他 Incident Manager 資源。

**注意**  
Runbook 支援單一帳戶區域對的遷移。如果您有跨多個帳戶或區域的資源，您必須為每個帳戶區域組合分別執行遷移。

## 步驟 1：部署 CloudFormation 範本
<a name="deploy-cloudformation-template"></a>

部署 CloudFormation 範本以建立遷移 Runbook 所需的 IAM 角色、Amazon S3 儲存貯體和 Amazon SNS 主題。

### 所需的 IAM 許可
<a name="required-iam-permissions"></a>

若要部署此 CloudFormation 範本，您需要 CloudFormation 堆疊操作 (`cloudformation:CreateStack`、`cloudformation:DescribeStacks`)、IAM 角色管理 (`iam:CreateRole`、`iam:AttachRolePolicy`、、`iam:PassRole`)`iam:PutRolePolicy`、Amazon S3 儲存貯體建立和組態 (`s3:CreateBucket`、`s3:PutBucket*`) 和 Amazon SNS 主題操作 (`sns:CreateTopic`、`sns:Subscribe`、) 的 IAM 許可`sns:SetTopicAttributes`。

如需 CloudFormation 許可的完整詳細資訊，請參閱 CloudFormation 《 使用者指南》中的[CloudFormation 許可參考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)。

### 使用主控台部署 CloudFormation 範本
<a name="deploy-console"></a>

1. 下載並擷取包含`AWS-IncidentManager-MigrationResources.yaml`範本的 [AWS-IncidentManager-MigrationResources.zip](./samples/AWS-IncidentManager-MigrationResources.zip) 檔案。

1. 在 https：//[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation) 開啟 CloudFormation 主控台。

1. 選擇**建立堆疊**。

1. 在 **Specify template (指定範本)** 區段中，選擇 **Upload a template file (上傳範本檔案)**。

1. 選擇**選擇檔案**，然後選擇`AWS-IncidentManager-MigrationResources.yaml`檔案。

1. 選擇**下一步**。

1. 在**指定堆疊詳細資訊**頁面上，輸入下列內容：
   + **堆疊名稱** - 輸入名稱 （例如 `im-migration-infrastructure`)
   + **ApprovalEmail** - 輸入電子郵件地址以接收核准通知 （僅在 RequireManualApproval Runbook 參數設定為 true 時使用）。
   + **IsPrimaryMigrationRegion** - 選擇這`true`是否是您部署堆疊之帳戶中的第一個區域，否則請選擇 `false`

1. 選擇**下一步**。

1. 在 **Configure stack options** (設定堆疊選項) 頁面，選擇 **Next** (下一步)。

1. 在**檢閱**頁面上，向下捲動並選取**我確認 CloudFormation 可能會使用自訂名稱建立 IAM 資源**。

1. 選擇**提交**。

CloudFormation 會顯示 `CREATE_IN_PROGRESS` 狀態。當堆疊就緒`CREATE_COMPLETE`時，狀態會變更為 。

**注意**  
如果您在多個區域中有 CloudWatch 警示或 EventBridge 規則，請在您要執行遷移的每個區域中部署此 CloudFormation 堆疊。  
對於跨 AWS Organizations 的多帳戶部署，請使用兩個 CloudFormation StackSets：  
**主要 StackSet** - 針對每個帳戶一個區域將 IsPrimaryMigrationRegion 設為 true
**次要 StackSet** - 針對所有其他區域將 IsPrimaryMigrationRegion 設定為 false
  
如需說明，請參閱 CloudFormation 《 使用者指南》中的[使用 CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)。

### 使用 部署 CloudFormation 範本 AWS CLI
<a name="deploy-cli"></a>

對於您帳戶中的第一個區域，請使用下列命令：

```
aws cloudformation create-stack \
    --stack-name im-migration-infrastructure \
    --template-body file://AWS-IncidentManager-MigrationResources.yaml \
    --parameters ParameterKey=ApprovalEmail,ParameterValue=your-email@example.com \
    ParameterKey=IsPrimaryMigrationRegion,ParameterValue=true \
    --capabilities CAPABILITY_NAMED_IAM \
    --region us-east-1
```

對於相同帳戶中的其他區域，將 `IsPrimaryMigrationRegion`設定為 `false`：

```
aws cloudformation create-stack \
    --stack-name im-migration-infrastructure \
    --template-body file://AWS-IncidentManager-MigrationResources.yaml \
    --parameters ParameterKey=ApprovalEmail,ParameterValue=your-email@example.com \
    ParameterKey=IsPrimaryMigrationRegion,ParameterValue=false \
    --capabilities CAPABILITY_NAMED_IAM \
    --region us-west-2
```

若要驗證堆疊狀態：

```
aws cloudformation describe-stacks \
    --stack-name im-migration-infrastructure \
    --query 'Stacks[0].StackStatus' \
    --output text
```

等到命令傳回，`CREATE_COMPLETE`再繼續下一個步驟。

## 步驟 2：遷移 CloudWatch 警示和 EventBridge 規則
<a name="migrate-resources"></a>

使用 Systems Manager Automation Runbook 將 CloudWatch 警示和 EventBridge 規則從 Incident Manager 遷移至 OpsCenter。

### 遷移 Runbook
<a name="migration-runbooks-overview"></a>
+ [AWS-MigrateIncidentManagerCloudWatchAlarms](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerCloudWatchAlarms)
+ [AWS-MigrateIncidentManagerEventBridgeRules](https://console.aws.amazon.com/systems-manager/documents/AWS-MigrateIncidentManagerEventBridgeRules)

如需這些 Runbook 功能的詳細資訊，包括詳細的步驟說明、輸入參數和輸出，請參閱 Runbook 文件。

### Runbook 的運作方式
<a name="how-runbooks-work"></a>

兩個遷移 Runbook 都遵循相同的工作流程：
+ **探索和批次處理** - 探索使用 Incident Manager 回應計劃動作設定的所有 CloudWatch 警示或 EventBridge 規則，並將其整理成可設定的批次。
+ **手動核准 （選用）** - 在預設情況下， 需要明確核准才能繼續進行遷移，並具有 24 小時逾時。Amazon SNS 通知會傳送至 CloudFormation 部署期間指定的電子郵件地址。所有組態都會備份到 Amazon S3，並存放要遷移的完整資源清單以供手動檢閱。將 RequireManualApproval 設定為 false，即可略過此步驟。
+ **備份和遷移** - 如果手動核准設為 true， 會等待核准，然後繼續將每個組態備份到 Amazon S3 並執行遷移。如果設定為 false，則 會直接進行備份和遷移。

### 輸入參數
<a name="input-parameters"></a>

兩個 Runbook 都需要下列參數：

AutomationAssumeRole （必要）  
 CloudFormation 堆疊所`IM-Migration-Automation-Role`建立 的 ARN。

ApproverArn （必要）  
可以檢閱和核准遷移的 IAM 角色或使用者的 ARN。

S3BucketName （必要）  
 CloudFormation 堆疊建立的 Amazon S3 儲存貯體名稱。

SNSTopicArn （必要）  
 CloudFormation 堆疊所建立 Amazon SNS 主題的 ARN。

MaxNumberOfAlarmsToMigrate 或 MaxNumberOfRulesToMigrate （選用）  
在單一執行中要遷移的資源數量上限。有效值：1、5、10、50、100、500、5000、10000、25000、50000。預設：10000。

BatchSize （選用）  
每個批次中要處理的資源數量。有效值：25、50、100、200、250、300、350、400、450、500。預設：100。Runbook 每次執行最多支援 100 × BatchSize 資源。

RequireManualApproval （選用）  
布林值，用於控制是否需要在遷移之前手動核准。設為 true （預設） 時，您會收到 Amazon SNS 通知電子郵件，其中包含資源清單的 Amazon S3 位置，以及要核准、拒絕或取消的自動化執行主控台連結。設定為 false 時，執行手冊會在探索和備份之後自動繼續。有效值：true、false。預設：true。

### 使用主控台遷移
<a name="migrate-console"></a>

1. 開啟 [https://console.aws.amazon.com/systems-manager](https://console.aws.amazon.com/systems-manager) 中的 Systems Manager 主控台。

1. 在導覽窗格中，選擇 **Automation** (自動化)。

1. 搜尋 Runbook 名稱 (`AWS-MigrateIncidentManagerCloudWatchAlarms` 或 `AWS-MigrateIncidentManagerEventBridgeRules`)。

1. 選擇 **Execute automation (執行自動化)**。

1. 輸入 CloudFormation 堆疊輸出中的參數值。

1. （選用） `false` 如果您想要略過手動核准步驟，請將 **RequireManualApproval** 設定為 。

1. 選擇 **Execute (執行)**。

1. 如果 `RequireManualApproval` 設為 true （預設），您會在執行等待手動檢閱時收到電子郵件通知。電子郵件包含自動化執行主控台頁面的核准連結。檢閱 Amazon S3 儲存貯體中的資源清單，然後在 24 小時內從電子郵件連結或主控台頁面核准、拒絕或取消。遷移只會在核准後繼續進行。如果設定為 false，遷移會在備份後自動繼續進行。

1. 等待執行狀態變更為**成功**。

### 使用 遷移 AWS CLI
<a name="migrate-cli"></a>

**對於 CloudWatch 警示：**

```
aws ssm start-automation-execution \
    --document-name "AWS-MigrateIncidentManagerCloudWatchAlarms" \
    --parameters '{
        "AutomationAssumeRole": ["arn:aws:iam::123456789012:role/IM-Migration-Automation-Role"],
        "ApproverArn": ["arn:aws:iam::123456789012:role/Admin"],
        "S3BucketName": ["im-migration-logs-123456789012-us-east-1"],
        "SNSTopicArn": ["arn:aws:sns:us-east-1:123456789012:Automation-IM-Migration-Approvals"],
        "RequireManualApproval": ["false"]
    }' \
    --region us-east-1
```

**對於 EventBridge 規則：**

```
aws ssm start-automation-execution \
    --document-name "AWS-MigrateIncidentManagerEventBridgeRules" \
    --parameters '{
        "AutomationAssumeRole": ["arn:aws:iam::123456789012:role/IM-Migration-Automation-Role"],
        "ApproverArn": ["arn:aws:iam::123456789012:role/Admin"],
        "S3BucketName": ["im-migration-logs-123456789012-us-east-1"],
        "SNSTopicArn": ["arn:aws:sns:us-east-1:123456789012:Automation-IM-Migration-Approvals"],
        "RequireManualApproval": ["false"]
    }' \
    --region us-east-1
```

若要檢閱 Amazon S3 中的資源清單：

```
# For CloudWatch alarms
aws s3 cp s3://im-migration-logs-123456789012-us-east-1/review/CloudWatch/review_CW_alarms_to_migrate_123456789012_us-east-1.json ./

# For EventBridge rules
aws s3 cp s3://im-migration-logs-123456789012-us-east-1/review/EventBridge/review_EB_rules_to_migrate_123456789012_us-east-1.json ./
```

如果 RequireManualApproval 設為 true，請檢閱資源清單，並按一下電子郵件通知或自動化執行主控台頁面中的核准連結來核准遷移。如果設定為 false，遷移會在備份後自動繼續進行。

## 步驟 3：驗證您的遷移
<a name="verify-migration"></a>

完成遷移後，請確認您的資源正常運作：
+ **觸發測試警示或事件** - 啟用其中一個遷移的 CloudWatch 警示或 EventBridge 規則，以產生測試通知。
+ **確認 OpsItem 建立** - 當警示或事件觸發時，確認 OpsItem 已在 OpsCenter 中自動建立。
+ **驗證嚴重性映射** - 檢查 OpsItem 中是否正確保留原始 Incident Manager 組態的嚴重性層級。（僅適用於 CloudWatch 警示）。

## 步驟 4：清除 Incident Manager 資源
<a name="cleanup-resources"></a>

成功遷移 CloudWatch 警示和 EventBridge 規則之後，您可以選擇清除 Incident Manager 資源，以完全離開服務。

如需刪除複寫集、回應計劃、聯絡人、執行手冊和其他 Incident Manager 資源的詳細說明，請參閱 [清除 Incident Manager 資源](migration-cleanup.md)。

### 刪除 CloudFormation 堆疊 （選用）
<a name="delete-cloudformation-stacks"></a>

您可以刪除 CloudFormation 堆疊，以移除為遷移建立的 IAM 角色、Amazon SNS 主題和 Amazon S3 儲存貯體。

**重要**  
在刪除堆疊之前，必須清空包含所有已遷移資源備份的 Amazon S3 儲存貯體。 CloudFormation 無法刪除包含物件的 Amazon S3 儲存貯體。

**刪除 CloudFormation 堆疊**

```
aws cloudformation delete-stack --stack-name <your-stack-name>
```

## 監控和疑難排解
<a name="monitoring-troubleshooting"></a>

**CloudWatch Logs** - 遷移活動會記錄到 CloudWatch Logs：
+ CloudWatch 警示： `/aws/ssm/incidentmanager/cwmigration`
+ EventBridge 規則： `/aws/ssm/incidentmanager/ebmigration`

**Amazon S3 備份結構** - 所有組態都會在遷移之前備份至 Amazon S3：

```
migration-logs-{AccountId}-{Region}/
├── backups/
│   ├── CloudWatch/
│   │   └── {AccountId}/
│   │       └── {Region}/
│   │           └── {AlarmName}_backup.json
│   └── EventBridge/
│       └── {AccountId}/
│           └── {Region}/
│               └── {RuleName}_backup.json
└── review/
    ├── CloudWatch/
    │   └── review_CW_alarms_to_migrate_{AccountId}_{Region}.json
    └── EventBridge/
        └── review_EB_rules_to_migrate_{AccountId}_{Region}.json
```

**常見問題：**
+ **未收到 Amazon SNS 通知** （當 RequireManualApproval=true 時） - 檢查 Amazon SNS 主題訂閱：

  ```
  aws sns list-subscriptions-by-topic --topic-arn <sns-topic-arn>
  ```
+ **部分遷移失敗** - 檢查 CloudWatch Logs 以取得詳細的錯誤訊息，並以較低的批次大小重試自動化。

**轉返程序：**

如果您需要復原遷移：
+ 從 Amazon S3 擷取備份：

  ```
  aws s3 sync s3://im-migration-logs-123456789012-us-east-1/backups/ ./backups/
  ```
+ 還原資源：

  ```
  # For CloudWatch alarms
  aws cloudwatch put-metric-alarm --cli-input-json file://backups/CloudWatch/123456789012/us-east-1/MyAlarm_backup.json
  
  # For EventBridge rules
  aws events put-targets --rule MyRule --targets file://backups/EventBridge/123456789012/us-east-1/MyRule_backup.json
  ```

## 常見問答集
<a name="faq"></a>

問：如果自動化在核准期間逾時，會發生什麼情況？  
答：如果未收到核准，自動化會在 24 小時後逾時。您可以使用相同的參數重新啟動自動化。

問：我可以跨區域遷移資源嗎？  
答：否。每個區域都必須使用區域特定的自動化執行分別遷移。

問：遷移需要多長時間？  
答：遷移時間取決於資源數量：  
+ \$1100 個警示/規則：5-10 分鐘
+ \$11000 個警示/規則：30-60 分鐘
+ \$110000 個警示/規則：2-4 小時

問：遷移至 OpsCenter 後是否保留嚴重性？  
答案：是。在 CloudWatch 警示遷移期間，會保留在 Incident Manager 回應計畫影響層級中設定的嚴重性，並自動對應至適當的 OpsCenter 嚴重性層級。這不適用於 EventBridge 規則。

問：執行自動化 Runbook 是否需要支付費用？  
答：否。遷移自動化執行手冊不會產生執行費用。不過，遷移後的 OpsCenter 用量會產生費用。如需詳細資訊，請參閱 [Systems Manager 定價](https://aws.amazon.com/systems-manager/pricing/)文件。

## 相關資源
<a name="related-resources-runbooks"></a>
+ [遷移至 AWS Systems Manager OpsCenter](migration-opscenter.md)
+ [AWS Systems Manager OpsCenter 使用者指南](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
+ [Systems Manager 自動化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [匯出 Incident Manager 資料](export-data.md)
+ [清除 Incident Manager 資源](migration-cleanup.md)

# 遷移至 Jira Service Management
<a name="migration-jira"></a>

[Jira Service Management (JSM)](https://www.atlassian.com/software/jira/service-management/features/itsm#incident-management) 是一種 IT 服務管理 (ITSM) 解決方案，可協助團隊透過多個管道接收、追蹤、管理和解決員工和客戶請求，包括電子郵件、聊天、說明中心和小工具。Jira Service Management 以 Jira 平台為基礎，可讓整個組織的團隊 - 從開發到 IT 再到人力資源 - 接收請求、回應警示和事件、部署變更、追蹤資產、表面知識，以及自動化工作流程。Jira Service Management 包含事件管理功能，例如通話中排程、提醒、主要事件管理、變更管理和專為 DevOps 工作流程設計的無責事後 (PIR) 功能，利用現有的 CI/CD 管道和自動化來減少手動工作量。

Jira Service Management 與 Amazon CloudWatch 和 Amazon EventBridge 整合，可讓您在 CloudWatch 警示進入 `ALARM` 狀態或 EventBridge 處理來自發佈事件的任何事件時，自動建立 Jira Service Management AWS 服務 警示。設定 CloudWatch 警示和 EventBridge 事件以自動建立 Jira Service Management 警示，可讓您快速診斷和修復來自單一平台 AWS 的資源問題。Jira Service Management 充當分派程式，根據通話排程和呈報政策，透過多個管道 （電子郵件、簡訊、電話、行動推播） 通知正確的人員。

如果您現有的 CloudWatch 警示和 EventBridge 規則已與 整合 AWS Systems Manager Incident Manager，建議您更新這些整合以改用 Jira Service Management。官方 Atlassian 文件提供將 [Jira Service Management 與 CloudWatch 整合](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-cloudwatch/)，以及[將 Jira Service Management 與 EventBridge 整合](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-eventbridge/)的詳細說明。

除了自動建立提醒之外，Jira Service Management 還提供一系列功能來簡化事件管理，例如隨需排程、升級政策和自動化規則。如需設定這些功能的詳細資訊，客戶可以參閱下列 Atlassian 文件：
+ [探索提醒和通話中](https://support.atlassian.com/jira-service-management-cloud/docs/discover-alerting-and-on-call/)
+ [建立隨時待命排程](https://support.atlassian.com/jira-service-management-cloud/docs/create-an-on-call-schedule/)
+ [建立呈報政策](https://support.atlassian.com/jira-service-management-cloud/docs/create-edit-delete-an-escalation-policy/)
+ [設定團隊和人員](https://support.atlassian.com/platform-experiences/docs/start-an-atlassian-team/)
+ [設定聯絡方法](https://support.atlassian.com/jira-service-management-cloud/docs/add-contact-methods/)
+ [設定通知規則](https://support.atlassian.com/jira-service-management-cloud/docs/add-notification-rules/)
+ [設定簡訊和語音通知](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sms-and-voice-notifications/)
+ [設定自動化規則](https://www.atlassian.com/software/jira/service-management/product-guide/tips-and-tricks/automation#overview)
+ [設定和管理事件利益相關者](https://support.atlassian.com/jira-service-management-cloud/docs/how-can-i-add-and-manage-internal-stakeholders/)

如需其他支援，請聯絡您的技術客戶經理或 [Atlassian 銷售代表](https://www.atlassian.com/enterprise/contact)以取得詳細資訊。

# 遷移至 ServiceNow
<a name="migration-servicenow"></a>

ServiceNow [Incident Management](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html) 是一種核心 ITSM 模組，旨在在意外中斷後還原正常的服務操作，同時將業務影響降至最低。如同 Incident Manager，ServiceNow Incident Management 提供結構化的自動化系統來檢視、調查和解決 IT 事件，並具有自動化優先順序和內建呈報程序等功能。

ServiceNow Service Operations with Incident Management and Event Management 模組與 Amazon CloudWatch 整合，可讓您在 CloudWatch 警示進入 `ALARM` 狀態時自動建立 ServiceNow 事件/警示和事件。設定 CloudWatch 警示以使用 Webhook 自動建立 ServiceNow 事件至 AIOps 事件管理，可讓您快速診斷和修復單一平台 AWS 的資源問題。

如果您現有的 CloudWatch 警示已與 整合 AWS Systems Manager Incident Manager，建議您更新這些整合，以改用 ServiceNow [Incident Management](https://www.servicenow.com/products/incident-management.html) 和 [AIOps 事件智慧](https://www.servicenow.com/products/event-management.html)平台。官方 ServiceNow 文件提供將 [ ServiceNow 與 Amazon CloudWatch 整合](https://www.servicenow.com/docs/bundle/zurich-integrate-applications/page/administer/integrationhub-store-spokes/concept/amazon-cloudwatch.html)的詳細說明。

除了自動建立事件之外，ServiceNow Incident Management 還提供一系列功能來改善事件管理，例如事件通訊管理、通話排程、呈報政策等。如需設定這些功能的詳細資訊，客戶可以參閱下列 ServiceNow 文件：
+ [事件管理文件](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html)
+ [服務可靠性管理](https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/service-reliability/reference/sr-landing-page.html)
+ [事件通訊管理和聯絡](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-alert-management/concept/c_IncidentAlertContact.html)
+ [待命排程](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/administer/on-call-scheduling/concept/c_OnCallScheduling.html)
+ [升級程序](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/administer/on-call-scheduling/concept/designing-escalation-process-oncall.html)

如需其他支援，請聯絡您的技術客戶經理或 [ServiceNow 銷售代表](https://www.servicenow.com/be/contact-us/sales.html)以取得詳細資訊。

# 遷移至 PagerDuty
<a name="migration-pagerduty"></a>

[PagerDuty](https://support.pagerduty.com/main/docs/introduction) 是一種事件管理平台，可協助組織偵測、回應甚至防止事件。如同 Incident Manager，PagerDuty 提供集中位置，讓營運團隊處理與 AWS 資源相關的重要工作，減少客戶的影響。

PagerDuty 與 Amazon CloudWatch 和 Amazon EventBridge 整合，可讓您在 CloudWatch 警示進入 `ALARM` 狀態或 EventBridge 從發佈事件的任何 AWS 服務 處理事件時，自動建立 PagerDuty 事件。透過設定 CloudWatch 警示和 EventBridge 事件自動建立 PagerDuty 事件，您可以從單一平台快速診斷和修復 AWS 資源問題。

如果您現有的 CloudWatch 警示和 EventBridge 規則已與 整合 AWS Systems Manager Incident Manager，我們建議您更新這些整合以改用 PagerDuty。官方 PagerDuty 文件提供[將 PagerDuty 與 CloudWatch 整合](https://support.pagerduty.com/main/docs/amazon-cloudwatch-integration-guide)，以及[將 PagerDuty 與 EventBridge 整合](https://support.pagerduty.com/main/docs/amazon-eventbridge-integration-guide)的詳細說明。

除了自動建立事件之外，PagerDuty 還提供了一系列功能來改善事件管理，例如通話中排程、升級政策和超過 700 個out-of-box平台整合。您也可以自訂通知規則、設定聊天表面，以及利用 PagerDuty 平台中的 AI 和自動化來加速事件解決。
+ [管理使用者](https://support.pagerduty.com/main/docs/manage-users)
+ [建立團隊](https://support.pagerduty.com/main/docs/teams)
+ [設定聯絡方法](https://support.pagerduty.com/main/docs/contact-information)
+ [設定通知規則](https://support.pagerduty.com/main/docs/notification-rules)
+ [設定隨時待命輪換](https://support.pagerduty.com/main/docs/schedule-basics)
+ [建立呈報政策](https://support.pagerduty.com/main/docs/escalation-policies)
+ [設定 Slack 整合](https://support.pagerduty.com/main/docs/slack-integration-guide)
+ [設定自動化動作](https://support.pagerduty.com/main/docs/automation-actions)

如需其他支援，請聯絡您的技術客戶經理或 [AWS-IM-help@pagerduty.com](mailto:AWS-IM-help@pagerduty.com) 以取得詳細資訊。