执行持续优化以减少无意义的警报
在本单元中，你将了解可用于监视站点可靠性的进程。 你还将了解如何对警报进行持续优化以减少无意义的警报。
监视和警报
通过监视和警报，系统可以在发生中断时告知人们，或者告诉他们即将中断的内容。 如果有人需要调查问题，则警报应提供相关信息，以便人们知道从何处着手。
当你查看现有警报或编写新的警报规则时，请考虑以下准则，以使警报保持相关性，并让你的待命轮转更愉快：
- 引起人们关注的警报应该是紧急的、重要的、面向操作的和真实的。
- 警报应表示服务中正在发生或即将发生的问题。
- 删除干扰警报。 与监视不足相比，监视过度是更难解决的问题。
- 将问题分类为以下类别之一：
- 可用性和基本功能。
- Latency。
- 正确性。
- 特定于功能的问题。
- 症状是一种更好的方法，可以更轻松、更全面、更可靠地捕获问题。
- 在基于症状的页面或仪表板中包含基于原因的信息，但要避免直接对原因发出警报。
- 你的服务堆栈越深入，你在单个规则中捕获的问题就越多。 但是不要走得太远，以至于无法充分区分正在发生的事情。
- 如果你想要安静的待命轮换，请使用一个系统来处理需要及时响应但并不严重的问题。
监视用户
对用户的监视也称为“基于症状的监视”。这与“基于原因的监视”相反。 用户不关心数据推送是否失败，他们关心其结果是否是全新的。
通常，用户关心以下内容：
- 基本可用性和正确性：任何以某种方式破坏核心服务的情况都应归类为不可用性。
- 延迟：页面应快速加载。
- 新鲜度、时效性和持续性：用户的数据应该是安全的，应该及时返回，搜索索引应是最新的。
- 运行时间：即使该服务暂时不可用，用户也应该完全相信该服务将很快备份。
- 功能：用户关心该服务的所有功能是否正常运行。 监视服务的重要方面，即使它不是核心功能。
数据库服务器不可用和用户数据不可用之间有一个细微但重要的区别。 前者是直接原因，后者是一种症状。
基于原因的警报也有其作用
有时没有触发警报的症状，但仍需向你发出警报。 例如，内存不足。 你希望规则在引起症状之前将可能成为问题的内容通知你。 在这种情况下，你可以编写一个规则在这种情况下发出警报。
不过，请不要编写在调用警报上触发的基于原因的规则，这些规则可以以其他方式捕获。
票证、报表和电子邮件
需要尽快关注但不需要立即关注的警报是次要警报。 下面是一些建议，可用于记录次要警报，以便日后跟进：
- Bug 或票证跟踪系统可用于此类警报：只要将同一警报正确地置于单个票证或 bug 中，警报就可以打开 bug。 然后，这些 bug 可以进行会审处理，然后分配给其他人进行跟进。 在这些类型的问题变得严重之前，必须对其加以解决，这一点很重要。 请考虑你的团队成员有多少时间可以用来解决 bug。
- 每日（或更频繁）报表可能有用：将长期存在的临界值以下的警报（例如，数据库已满 90% 以上）写入显示所有活动警报的报表中。 指派某人每天对这份报表进行会审。
- 每个警报都应通过工作流系统进行跟踪：这确保发现并解决它们。
一般情况下，创建一个可提升响应能力的系统，但不会产生直接人工干预的高成本。
攻略
剧本（有时称为 Runbook）是警报系统的重要组成部分。 剧本中有一个条目，其中说明了应对每个出现症状的警报或警报系列采取的措施。
跟踪和问责
如果有人接收到警报并确定没有任何错误，则表明你需要删除规则，将其降级或以其他方式收集数据。 准确度低于 50% 的警报将被视为已损坏。 即使是那些只有 10% 的时间会触发误报的警报也应重新评估。
每周查看所有触发的待命警报并分析季度警报统计信息，可以帮助你查看专注于单个警报时丢失的模式。
何时从规则中查找异常？
下面是可能违反上述准则的一些原因：
你有一个已知的原因，该原因实际低于你的症状中的噪声：例如，如果你的服务具有 99.99% 的可用性，但是有一个导致 0.001% 的请求失败的常见事件，则你不能将其作为症状发出警报，因为它处于混乱状态，但是你可以捕获导致事件。
你无法在入口点进行监视，因为丢失了数据解析：例如，你忍受某些终结点速度慢，如信用卡验证。 在负载均衡器中，这种差异可能会丢失。 你将需要向下遍历堆栈，并从具有差异的最高位置发出警报。
症状出现时为时已晚：例如，配额已用完。 你需要在为时已晚之前向某人发出警报，有时这意味着要找到发出警报的原因。 例如，你的使用量大于 80%，并且将在 4 小时内以最近 1 小时的增长率耗尽。
但是，你也应该能够找到不太紧急的类似原因。 例如，你的配额大于 90%，并且将在 4 天内以最近 1 天的增长率耗尽。 这一组情况将适用于大多数案例。 然后，你可以将问题作为票证或电子邮件警报或每日问题报告来处理，而不是警报所代表的最后一次升级。
你的警报设置比它尝试检测的问题更复杂：目标应该是简单、可靠、自我保护的系统。