可观测性工程

112

|

第

12

章

时地耗尽内存。”

习惯于容易出现误报的告警是一个“已知”（笔者认为“默认”可能更能代表当前的现状）

的问题，同时也是一种非常危险的实践。在其他行业，这个问题被称为偏差的正常化：

这个术语是在调查“挑战者号”灾难（

https://pubmed.ncbi.nlm.nih.gov/25742063

）时创

造的。当一个组织中的个人经常关闭告警或在告警发生时不采取行动时，最终在应对系

统偏离预期状态的时候往往会消极处理甚至不处理。那些“正常”的、被忽视的故障，

在最好的情况下，只是背景噪声。在最坏的情况下，它们会导致灾难性的疏忽，而这些

疏忽是由连环的系统故障造成的。

在软件行业中，基于监控告警的信噪比很低，这往往会导致告警疲劳，即逐渐减少对所

有告警的关注，因为其中有很多都是误报或者不需要操作甚至无用的告警。不幸的是，

在基于监控的告警系统中，当事故发生时，这个问题往往会变得更加复杂。事故回顾后

通常会产生一些行动项目，这些行动项目会产生新的、更重要的告警，而这些告警可能

会及时发出告警以防止问题发生。这导致在下一个事件中产生了更大量的告警。这种告

警升级的模式造成了越来越多的告警，也给响应的工程师带来了越来越大的认知负担，

以确定哪些告警重要，哪些不重要。

这种类型的功能障碍在软件行业非常普遍，以至于许多监控和事件响应工具供应商自豪

地提供各种标有“

AIOps

”的解决方案，试图通过分组、抑制或者其他方式为你处理告

警负载（参见本书

8.3

节）。工程团队已经对告警噪声习以为常，这种模式现在被视为

正常。如果未来在生产中运行的软件注定要产生如此多的噪声 ...