AWS Systems Manager Incident Manager 不再向新客户开放。现有客户可以继续正常使用该服务。有关更多信息，请参阅 [AWS Systems Manager Incident Manager 可用性变更](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-availability-change.html)。 本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 迁移指南 由于 AWS Systems 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 服务管理](migration-jira.md) + [迁移到 ServiceNow](migration-servicenow.md) + [迁移到 PagerDuty](migration-pagerduty.md) # 迁移到 AWS Systems Manager OpsCenter 本指南可帮助您了解事件管理器之间的主要区别， OpsCenter 并确定是否 OpsCenter 符合您的运营需求，并提供了 OpsCenter 从 AWS Systems Manager 事件管理器迁移到事件管理器的方法。 [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 集成，允许您使用自动化运行手册来调查和解决问题。您可以 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/)。 与事件管理器类似， OpsCenter 已与亚马逊 CloudWatch 和亚马逊 EventBridge集成。这意味着您可以将这些服务配置为 OpsItem 在 OpsCenter CloudWatch 警报进入`ALARM`状态或 EventBridge 处理来自任何 AWS 服务 发布事件的事件时自动创建输入。通过将 CloudWatch 警报和 EventBridge 事件配置为自动创建， OpsItems 您可以通过单个控制台快速诊断和修复 AWS 资源问题。 ## 了解差异 AWS Systems Manager 事件管理器提供事件响应功能，包括自动响应计划、响应者参与和升级、待命轮换管理、运行手册自动化、聊天操作集成（Slack、Microsoft Teams、Amazon Chime）和事后分析。这些功能可帮助组织协调和解决影响 AWS托管应用程序的关键的、时间敏感的事件。 相比之下， AWS Systems Manager OpsCenter 重点管理操作工作项目 (OpsItems)，以解决安全警报、性能降级、资源故障、运行状况通知和状态更改等 day-to-day操作问题。 OpsCenter 通过 Amazon CloudWatch 和 Amazon 与 AWS 资源集成 EventBridge，使用 Systems Manager Automation 运行手册实现自动 OpsItem 创建和修复。 OpsCenter 支持区域 OpsItems 内的跨账户管理，允许运营团队跨多个 AWS 账户查看、调查和解决问题。但是， OpsCenter 不包括寻呼或待命轮换功能。 这两项 AWS 服务之间的主要区别在于其重点和范围。Incident Manager 专为关键 OpsCenter 的、时间敏感的事件响应而设计，同时面向管理更广泛的操作任务和工作项目。 下表比较了 “事件管理器” 和 “事件管理器” 之间的主要功能 OpsCenter。使用此比较来确定是否 OpsCenter 符合您的运营需求。 | 特性/能力 | AWS Systems Manager  Incident Manager | AWS Systems Manager OpsCenter | | --- | --- | --- | | 主要目的 | 关键的、时效性强的事件响应和协调 | Day-to-day 操作工作项管理 | | 应用场景 | 影响应用程序的事件；安全漏洞；服务中断；严重系统故障 | 安全警报；性能降级；资源故障；Health 通知；状态更改 | | 自动寻呼 | 是-内置寻呼和回复者参与度 | 否-需要第三方集成（PagerDuty、 ServiceNow、Jira） | | 待命轮换管理 | 是-本地待命时间表和轮换 | 否-不支持 | | 升级政策 | 是-自动升级链 | 否-需要手动上报 | | 聊天操作集成 | 是的——Slack、微软 Teams、Amazon Chime | 有限-需要手动集成 | | 运行手册自动化 | 是-通过响应计划自动执行 | 是-手动执行 Systems Manager 自动化运行手册 | | 跨账户管理 | 是-跨账户事件共享 | 是-区域内的跨账户 OpsItem 管理 | ## 迁移选项   如果您已将现有的 CloudWatch 警报和 EventBridge 规则集成到事件管理器中，则需要对其进行更新才能与之集成 OpsCenter。您可以使用以下方法之一进行迁移： 使用运行手册自动迁移 使用 [Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 运行手册自动将 CloudWatch 警报和 EventBridge 规则从事件管理器迁移到。 OpsCenter这种方法包括备份、可配置的批准工作流程和详细的日志记录。您可以选择在迁移之前要求手动批准，也可以跳过自动大规模迁移的批准步骤。有关 step-by-step说明，请参阅[将迁移运行手册用于 OpsCenter](migration-opscenter-runbooks.md)。 手动集成 手动配置要与之集成的 CloudWatch 警报和 EventBridge 规则 OpsCenter。有关说明，请参阅《[Systems Manager 用户指南》 OpsItems中的配置 EventBridge 要创建的 CloudWatch 警报 OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html)[和配置要创建](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-automatically-create-OpsItems-2.html)的警报。 ## 相关资源 + [AWS Systems Manager OpsCenter 用户指南](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) + [导出事件管理器数据](export-data.md) + [清理事件管理器资源](migration-cleanup.md) # 将迁移运行手册用于 OpsCenter 本指南 step-by-step说明如何将您的亚马逊 CloudWatch 警报和亚马逊 EventBridge 规则从 AWS Systems Manager 事件管理器迁移到 AWS Systems Manager OpsCenter 使用自动迁移运行手册。 有关 OpsCenter 功能的概述以及要了解事件管理器与之间的区别 OpsCenter，请参阅[迁移到 AWS Systems Manager OpsCenter](migration-opscenter.md)。 ## 迁移概述 迁移过程使用 S [ystems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 运行手册将您的现有 CloudWatch 警报和 EventBridge 规则与 OpsCenter集成。该过程包括以下步骤： + **部署基础架构**-部署 CloudFormation 堆栈以创建迁移运行手册所需的资源。 + **迁移 CloudWatch 警报和 EventBridge 规则**-运行自动化运行手册，将您的资源迁移到。 OpsCenter + **清理资源**-（可选）删除复制集和其他事件管理器资源。 **注意** 运行手册支持单一账户-区域对的迁移。如果您拥有跨多个账户或地区的资源，则必须分别为每个账户-区域组合执行迁移。 ## 步骤 1：部署 CloudFormation 模板 部署 CloudFormation 模板以创建迁移运行手册所需的 IAM 角色、Amazon S3 存储桶和 Amazon SNS 主题。 ### 所需的 IAM 权限 要部署此 CloudFormation 模板，您需要拥有 CloudFormation 堆栈操作 (、)、IAM 角色管理 (`cloudformation:CreateStack`、、、`cloudformation:DescribeStacks``iam:PassRole`) `iam:CreateRole` `iam:PutRolePolicy` `iam:AttachRolePolicy`、Amazon S3 存储桶创建和配置 (`s3:CreateBucket`、`s3:PutBucket*`) 以及 Amazon SNS 主题操作 (、`sns:CreateTopic``sns:Subscribe`、`sns:SetTopicAttributes`) 的 IAM 权限。 有关 CloudFormation 权限的完整详细信息，请参阅《 CloudFormation 用户指南》中的[CloudFormation 权限参考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)。 ### 使用控制台部署 CloudFormation 模板 1. 下载并解压缩包含`AWS-IncidentManager-MigrationResources.yaml`模板[的 AWS-IncidentManager-MigrationResources .zip](./samples/AWS-IncidentManager-MigrationResources.zip) 文件。 1. 在 [https://console.aws.amazon.com/cloudformat](https://console.aws.amazon.com/cloudformation) ion 上打开 CloudFormation 控制台。 1. 选择**创建堆栈**。 1. 在**指定模板**部分，选择**上传模板文件**。 1. 选择 **“选择文件**”，然后选择该`AWS-IncidentManager-MigrationResources.yaml`文件。 1. 选择**下一步**。 1. 在**指定堆栈详细信息**页面上，输入以下内容： + **堆栈名称**-输入名称（例如，`im-migration-infrastructure`） + **ApprovalEmail**-输入用于接收批准通知的电子邮件地址（仅在 r RequireManualApproval unbook 参数设置为 true 时使用）。 + **IsPrimaryMigrationRegion**-选择这是`true`否是你账户中第一个部署堆栈的区域，否则选择 `false` 1. 选择 **Next**(下一步)。 1. 在**配置堆栈选项**页面上，请选择**下一步**。 1. 在 “**审阅**” 页面上，向下滚动并选择 “**我确认 CloudFormation 可能会使用自定义名称创建 IAM 资源**”。 1. 选择**提交**。 CloudFormation 显示`CREATE_IN_PROGRESS`状态。堆栈准备就绪`CREATE_COMPLETE`时，状态将更改为。 **注意** 如果您在多个区域都有 CloudWatch 警报或 EventBridge 规则，请在要执行迁移的每个区域部署此 CloudFormation 堆栈。 对于跨 AWS 组织部署多账户，请使用两个 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 对于您账户中的第一个区域，请使用以下命令： ``` 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 规则 使用 Systems Manager Automation 运行手册将 CloudWatch 警报和 EventBridge 规则从事件管理器迁移到。 OpsCenter ### 迁移操作手册 + [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 文档。 ### 运行手册是如何运作的 两个迁移运行手册都遵循相同的工作流程： + **发现和批处理**-发现使用事件管理器响应计划操作配置的所有 CloudWatch 警报或 EventBridge 规则，并将其组织成可配置的批次。 + **手动批准（可选）**-默认情况下，需要明确批准才能继续迁移，超时时间为 24 小时。Amazon SNS 通知将发送到部署期间 CloudFormation 指定的电子邮件地址。所有配置都备份到 Amazon S3，并存储待迁移资源的完整列表以供手动审查。通过设置为 false，可以跳过此步骤 RequireManualApproval 。 + **备份和迁移**-如果手动批准设置为 true，则等待批准，然后继续将每个配置备份到 Amazon S3 并执行迁移。如果设置为 false，则直接进行备份和迁移。 ### 输入参数 两个运行手册都需要以下参数： AutomationAssumeRole （必填） 堆栈`IM-Migration-Automation-Role`创建的 ARN。 CloudFormation ApproverArn （必填） 可以审查和批准迁移的 IAM 角色或用户的 ARN。 S3BucketName （必填） CloudFormation 堆栈创建的 Amazon S3 存储桶的名称。 SNSTopicArn（必填） 堆栈创建的 Amazon SNS 主题的 ARN。 CloudFormation MaxNumberOfAlarmsToMigrate 或 MaxNumberOfRulesToMigrate （可选） 单次执行中要迁移的最大资源数。有效值：1、5、10、50、100、500、5000、10000、25000、50000、50000。默认值：10000。 BatchSize （可选） 每批中要处理的资源数量。有效值：25、50、100、200、250、300、350、400、450、500、500。默认值：100。运行手册每次执行最多支持 100 × BatchSize 资源。 RequireManualApproval （可选） 用于控制迁移前是否需要手动批准的布尔值。设置为 true（默认）时，您将收到一封 Amazon SNS 通知电子邮件，其中包含资源列表的 Amazon S3 位置以及用于批准、拒绝或取消的自动执行控制台的链接。设置为 false 时，运行手册将在发现和备份后自动继续运行。有效值：真、假。默认值：真。 ### 使用控制台进行迁移 1. 在 [https://console.aws.amazon.com/systems-manager 上打开 System](https://console.aws.amazon.com/systems-manager) s Manager 控制台。 1. 在导航窗格中，选择**自动化**。 1. 搜索运行手册名称（`AWS-MigrateIncidentManagerCloudWatchAlarms`或`AWS-MigrateIncidentManagerEventBridgeRules`）。 1. 选择**执行自动化**。 1. 输入 CloudFormation 堆栈输出中的参数值。 1. （可选）`false`如果您**RequireManualApproval**想跳过手动批准步骤，请将其设置为。 1. 选择**执行**。 1. 如果设置`RequireManualApproval`为 true（默认），则在等待手动审核时您会收到一封电子邮件通知。该电子邮件包含指向自动化执行控制台页面的批准链接。查看 Amazon S3 存储桶中的资源列表，然后在 24 小时内通过电子邮件链接或控制台页面批准、拒绝或取消。只有在获得批准后才会进行迁移。如果设置为 false，则备份后会自动进行迁移。 1. 等待执行状态变为 “**成功**”。 ### 要使用迁移 AWS CLI **对于 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：验证您的迁移 完成迁移后，请验证您的资源是否正常运行： + **触发测试警报或事件**-激活已迁移的 CloudWatch 警报或 EventBridge 规则之一以生成测试通知。 + **确认 OpsItem 创建**-验证警报或事件触发 OpsCenter 时 OpsItem 是否自动创建。 + **验证严重性映射**-检查原始事件管理器配置中的严重性级别是否正确保留在中 OpsItem。（仅适用于 CloudWatch 警报）。 ## 步骤 4：清理事件管理器资源 成功迁移 CloudWatch 警报和 EventBridge 规则后，您可以选择清理事件管理器资源，使其完全脱离服务。 有关删除复制集、响应计划、联系人、运行手册和其他事件管理器资源的详细说明，请参阅[清理事件管理器资源](migration-cleanup.md)。 ### 删除 CloudFormation 堆栈（可选） 您可以删除 CloudFormation 堆栈以移除为迁移创建的 IAM 角色、Amazon SNS 主题和 Amazon S3 存储桶。 **重要** 在删除堆栈之前，必须清空包含所有迁移资源备份的 Amazon S3 存储桶。 CloudFormation 无法删除包含对象的 Amazon S3 存储桶。 **删除 CloudFormation 堆栈** ``` aws cloudformation delete-stack --stack-name ``` ## 监控和排查 **CloudWatch 日志**-迁移活动记录到 CloudWatch 日志： + 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 ``` **常见问题：** + **未收到亚马逊 SNS 通知**（当 RequireManualApproval =true 时）-请查看亚马逊 SNS 主题订阅： ``` aws sns list-subscriptions-by-topic --topic-arn ``` + **部分迁移失败**-请查看 CloudWatch 日志以获取详细的错误消息，然后在缩小批量后重试自动化。 **回滚程序：** 如果您需要回滚迁移，请执行以下操作： + 从 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 ``` ## 常见问题 问：如果在批准期间自动化超时会发生什么？ 答：如果未收到批准，自动化将在 24 小时后超时。您可以使用相同的参数重新启动自动化。 问：我能否跨区域迁移资源？ 答：不是。 必须使用特定于区域的自动化执行来单独迁移每个区域。 问：迁移需要多长时间？ 答：迁移时间取决于资源的数量： + 大约 100 个警报/规则：5-10 分钟 + 大约 1000 个警报/规则：30-60 分钟 + 大约 10000 个警报/规则：2-4 小时 问：迁移到后严重性是否保留 OpsCenter？ 答：能。在 CloudWatch 警报迁移期间，事件管理器响应计划影响级别中配置的严重性会被保留并自动映射到相应的 OpsCenter 严重性级别。这不适用于 EventBridge 规则。 问：我是否会因为执行自动化运行手册而被收费？ 答：不是。 迁移自动化运行手册不会产生执行费用。但是，迁移后的 OpsCenter 使用将产生费用。有关详情，请参阅 S [ystems Manager 定价](https://aws.amazon.com/systems-manager/pricing/)文档。 ## 相关资源 + [迁移到 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) + [导出事件管理器数据](export-data.md) + [清理事件管理器资源](migration-cleanup.md) # 迁移到 Jira 服务管理 [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 处理来自任何 AWS 服务 发布事件的事件时自动创建 Jira 服务管理警报。将 CloudWatch 警报和 EventBridge 事件配置为自动创建 Jira Service Management 警报，使您能够使用单一平台上的 AWS 资源快速诊断和修复问题。Jira Service Management 充当调度员，根据待命时间表和升级政策，通过多种渠道（电子邮件、短信、电话、移动推送）通知合适的人员。 如果您已将现有的 CloudWatch 警报和 EventBridge 规则与集成 AWS Systems Manager Incident Manager，我们建议您更新这些集成，改为使用 Jira Service Management。Atlassian 官方文档提供了将 Jira 服务管理[与 Jira 服务管理[集成 CloudWatch](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-eventbridge/)以及与](https://support.atlassian.com/jira-service-management-cloud/docs/integrate-with-amazon-cloudwatch/)之集成的详细说明。 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 ServiceNow [事件管理](https://www.servicenow.com/docs/bundle/zurich-it-service-management/page/product/incident-management/concept/c_IncidentManagement.html)是一个核心 ITSM 模块，旨在在意外中断后恢复正常的服务运营，同时最大限度地减少业务影响。与事件管理器一样， ServiceNow 事件管理提供了一个结构化的自动化系统来查看、调查和解决 IT 事件，具有自动确定优先级和内置上报流程等功能。 “带事件管理和事件管理的 ServiceNow 服务操作” 模块与 Amazon 集成 CloudWatch，允许您在警 CloudWatch 报进入状态时自动创建 ServiceNow 事件/警报和事件。`ALARM`将 CloudWatch 警报配置为使用 webhook 自动创建 ServiceNow 事件，使您能够使用单一平台上的 AWS 资源快速诊断和修复问题。 AIOps 如果您已将现有的 CloudWatch 警报与集成 AWS Systems Manager Incident Manager，我们建议您更新这些集成，改为使用 ServiceNow [事件管理和AIOps 事件](https://www.servicenow.com/products/incident-management.html)[情报](https://www.servicenow.com/products/event-management.html)平台。官方 ServiceNow 文档提供了[ ServiceNow 与Amazon集成的](https://www.servicenow.com/docs/bundle/zurich-integrate-applications/page/administer/integrationhub-store-spokes/concept/amazon-cloudwatch.html)详细说明 CloudWatch。 除了自动创建事件外， ServiceNow 事件管理还提供了一系列改进事件管理的功能，例如事件通信管理、待命调度、上报政策等。客户可以参考以下 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 [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 [ PagerDuty 与集成 CloudWatch](https://support.pagerduty.com/main/docs/amazon-eventbridge-integration-guide)和集成的](https://support.pagerduty.com/main/docs/amazon-cloudwatch-integration-guide)详细说明 EventBridge。 除了自动创建事件外， PagerDuty 还提供了一系列改进事件管理的功能，例如待命调度、上报政策以及 700 多个 out-of-box平台集成。您还可以自定义通知规则，配置聊天界面，并利用 PagerDuty 平台内的人工智能和自动化来加快事件的解决。 + [管理用户](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) 了解更多信息。