REL11-BP06 当事件影响可用性时发出通知 - AWS Well-Architected Framework

REL11-BP06 当事件影响可用性时发出通知

在检测到突破阈值时发送通知,即使导致问题的事件已自动解决。

自动修复使您的工作负载变得可靠。不过,它也可能会掩盖需要处理的潜在问题。实施适当的监控和措施,以便检测问题的模式,包括那些被自动修复的问题,从而从根本上解决问题。

弹性系统经过精心设计,可以立即将性能下降事件传达给相应的团队。这些通知应通过一个或多个通信渠道发送。

期望的结果: 在突破阈值 [例如错误率、延迟或其他重要的关键绩效指标(KPI)] 时,系统会立即向运营团队发送警报,以便尽快解决这些问题,从而避免或最大限度地减少对用户的影响。

常见反模式:

  • 发送的警报过多。

  • 发送不可操作的警报。

  • 将警报阈值设置得太高(过于敏感)或太低(不够敏感)。

  • 不针对外部依赖项发送警报。

  • 在设计监控和警报时,没有考虑 灰色故障

  • 执行自动修复,但未通知相应的团队需要进行该修复。

建立此最佳实践的好处: 恢复通知可以让运营和业务团队了解到服务性能下降的情况,这样他们就可以立即做出反应,尽可能地缩短平均检测时间(MTTD,Mean Time To Detect)和平均修复时间(MTTR,Mean Time To Repair)。恢复事件通知还可确保您不会忽略不经常发生的问题。

未建立这种最佳实践的情况下暴露的风险等级: 中。未能实施适当的监控和事件通知机制,会导致未能检测到出现的问题模式,包括那些被自动修复的问题。只有当用户联系客户服务或者在偶然的情况下,团队才会了解到系统性能下降的情况。

实施指导

在定义监控策略时,触发的警报是常见事件。此事件可能包含警报的标识符、警报状态(例如 IN ALARMOK),以及触发该警报的对象的详细信息。在许多情况下,系统应该检测到警报事件并发送电子邮件通知。这是对警报执行操作的示例。警报通知对于可观测性至关重要,因为它会告知相关人员所存在的问题。不过,当您的可观测性解决方案能够针对事件采取合理的操作时,它可以自动修复问题,而无需人工干预。

建立 KPI 监控警报后,在超过阈值时,应向相应的团队发送警报。这些警报还可用于触发自动流程,尝试修复性能下降问题。

对于更复杂的阈值监控,应考虑使用复合警报。复合警报使用多个 KPI 监控警报,根据运营业务逻辑创建警报。CloudWatch 警报可被配置为发送电子邮件,或使用 Amazon SNS 集成或 Amazon EventBridge 将事件记录到第三方事件跟踪系统。

实施步骤

根据监控工作负载的方式,创建各种类型的警报,例如:

  • 使用应用程序警报,检测工作负载的任何部分未正常工作的情况。

  • 基础设施警报 指明何时扩展资源。警报可以直观地显示在控制面板上,通过 Amazon SNS 或电子邮件发送,并与 Auto Scaling 结合使用来扩展或缩减工作负载资源。

  • 您可以创建简单的 静态警报 ,用于监控在指定数量的评估周期内,指标突破静态阈值的情况。

  • 复合警报 可以处理来自多个来源的复杂警报。

  • 创建警报后,请创建相应的通知事件。您可以直接调用 Amazon SNS API 来发送通知,并关联任何自动化的修复或通信机制。

  • 集成 Amazon Health Aware 监控功能,以便监控可能出现性能下降的 AWS 资源。对于关键业务工作负载,此解决方案可提供对 AWS 服务的主动实时警报的访问。

资源

相关的 Well-Architected 最佳实践:

相关文档:

相关工具: