可操作的警报
到目前为止，本模块介绍了如何看待、衡量系统可靠性及如何与之交互。 可靠性还有一个与我们交互的途径：警报。 可以轻松地设置 Azure Monitor 和其他工具，以便根据各种指标和信号（包括之前了解的 SLI 和 SLO）发送警报。 Azure 还可通过 Azure 服务运行状况功能，基于服务问题发送警报。
轻松发出警报的能力也带来了潜在的危害。 于是，“持续”一词引入之前见到的 SRE 定义：
站点可靠性工程是一种工程规范，致力于持续帮助组织实现系统、服务和产品的适当可靠性级别。
警报旨在系统出现问题时通知你。 但是，当警报配置地不正确时，它可能会破坏践行可持续操作的目标。 如果大量警报像冰雹一样砸向员工，这很可能会打乱之前将 SLI 和 SLO 引入组织的努力。 “警报疲劳”是操作社区中广为人知的问题。 本单元旨在帮助你防止警报疲劳出现在组织中。
警报疲劳很大程度上源自无法操作的警报。 我们来了解一下如何避免创建它们。
警报是什么（以及警报不是什么）
若要了解错误警报会造成问题的原因，需要思考警报的用途以及它们与其他操作信号有何不同。
可操作的警报不是：
日志：警报不是事件的记录，那是日志的职责。 如果只是想记录发生的事件，请将其写入日志文件，而不是发送紧急通知。
通知：警报不用于公布不重要的事件，如软件生成完成。 不必为了传达一条新闻去打扰别人，打断人家的注意力。
检测信号：警报不应用作系统仍在运行的提醒。 我们曾遇到过这么一种情况，人们说“噢，如果每小时没看到来自系统的至少一个页面，我就知道肯定出了什么问题，必须去处理它。”这是个糟糕的想法。
如果需要人力去调查并介入来修正问题的话，这时就会用到可操作的警报。 警报应传达这么一种信息 - 发生了某些异常或意外，需要引起人们注意。
如果系统通过自动化流程就可以处理事件（例如在预设限制内缩放资源），则不需要使用警报。 系统应该对其进行处理，并将其写入日志。 它不该在凌晨 2 点向你发送一个页面，告诉你成功处理了一个问题。
创建可操作的警报
为了使警报变得可操作，它必须：
简单 - 你不希望发出的警报需要接收者绞尽脑汁才能弄明白要采取什么操作。 如果警报过于复杂，倒霉的人半夜被叫醒，费力去搞清楚它的含义，白白浪费了宝贵的时间。
范围 - 为了能够有效地会审警报，接收消息的人首先要做的一件事就是确定问题的范围。 是单个服务器的问题吗？ 一项服务？ 整个区域？ 全球？ 为了使接受者更轻松地了解，请将此信息包含在警报中。
上下文 - 为了开始处理警报，接收者需要知道什么信息？ 让我们进一步探讨一下。
在警报中提供上下文
来看一些可操作警报应始终包含的元素，以便接收者了解所需的上下文：
警报来自何处？ 许多组织在任一时间使用多个监视系统，并且有大量互连的系统。 如果警报显示“针对工资系统 THX-1138 的警报来自 "prod" Azure Monitor 订阅”，则可节省大量时间。
违反了什么预期？ 如果警报只描述当前事务状态，则它远不及想象的那样有用。 将“数据库服务器在 80% 的负载下运行”与“过去两小时内，数据库服务器在 80% 的负载下运行，而它应在 60% 或者更低的负载下运行”进行对比。
为什么会出现这个问题（针对客户）？ 知道出现的状况已对或者可能会对客户造成什么影响，为我们提供一种方法来确定重要性并适当地估量反应。
接下来要采取哪些措施？ 如果可能，警报应包含响应者接下来应执行的操作，哪怕只是故障排除指南或其他一些文档的链接，以便寻求诊断和修正问题的帮助。
包括此类有用的上下文并努力使警报变得可操作，让操作实践更加可持续，并让响应这些警报更加轻松。