Airbnb透露，通过重新审视告警功能的开发和验证流程，他们显著改善了其可观测性实践，并且得出结论：虽然看上去根源是“文化问题”，但实际上是工具和工作流方面的缺失。通过重新设计其“可观测性即代码”（OaC）方法，该公司将告警功能开发周期从数周缩短至数分钟，大幅减少了告警噪音，并成功将数十万项告警迁移至新平台。
问题的核心来自一个简单的洞察：工程师并不是因为缺乏纪律而创建了糟糕的告警，而是因为他们无法在部署前看到告警行为。Airbnb 依赖 OaC 为大约 30 万项告警提供支持，为成千上万的服务提供了结构和一致性。然而，尽管代码审查验证了语法和逻辑，但它们无法捕捉到现实世界的行为。
这意味着工程师无法轻易确定告警是否会生成噪音、错过事件或不必要地唤醒值班团队。结果，生产环境成为了测试场，迫使团队在改进告警和冒着不稳定性风险或者忍受较差的信号质量之间进行权衡。随着时间的推移，这导致了告警疲劳、信任度降低和迭代速度变慢等一系列问题。
归根结底，这是因为缺乏快速反馈循环。团队不具备在部署前对真实数据进行告警验证的能力，只能依赖于缓慢的手动流程，通常是部署更改，等待几天或几周的时间，然后再进行迭代。在规模比较大时，这种方法是不切实际的，特别是当管理成千上万的服务时，现有工具因为依赖于下采样数据或手动验证而只能提供有限的支持。
Airbnb 的解决方法是重建其可观测性平台，使告警行为在部署前可见。新方法引入了快速反馈循环，允许工程师在合并更改前使用真实世界的数据预览告警行为。本地差异对比、部署前验证和大规模回测等功能使团队能够在几秒钟而不是几周内测试告警。
通过将验证提前到生命周期的早期，Airbnb 将告警测试从生产环境转移到了开发工作流中，使可观测性与现代软件工程的实践保持一致。他们获得了显著的成果：告警开发周期降至几分钟，告警噪音减少了高达 90%，人们恢复了对告警系统的信任。
这些改进对于 Airbnb 完成大约 30 万项告警到Prometheus的大规模迁移至关重要，在以前的方法下，这项工作将极其困难。
这些变化还为 Airbnb 更广泛的“零接触”可观测性愿景提供了支持，即团队在采用共享平台时可以自动继承高质量的告警、仪表板和服务等级目标。这种模式允许平台团队将最佳实践编码到可重用的模板中，不过这取决于他们对这些模板在大规模应用时是否能够正常运行的信心。
Airbnb 的这次经历为工程团队提供了一个更广泛的启示：看似源于文化的问题，往往是系统性的。在这个场景中，告警疲劳和监控不一致的问题并非源于不良实践，而是源于开发工作流的缺失。
通过改进工具和反馈循环，Airbnb 不仅改善了技术成果，还改变了工程行为。开发人员变得更愿意进行功能迭代，平台团队可以安全地演进标准，而整体的可观测性质量得到了提升。
最终，这个故事将可观测性重新定义为开发体验挑战。就像 CI/CD 管道为代码提供快速反馈一样，可观测性系统必须为监控做同样的事情。Airbnb 的方法表明，当工程师能够在早期验证更改时，他们可以更快地行动，做出更好的决策，并构建更可靠的系统。事实证明，在规模比较大时，修复系统的问题比解决人的问题更重要。
将验证左移、通过自动化和标准化手段提高信号质量，其他大型工程组织也是借助这些方法来解决类似的告警挑战。以谷歌为例，在采用站点可靠性工程（SRE）实践后，公司开始高度重视服务等级目标（SLO）和错误预算，并将其作为告警机制的基础。团队不再针对每种可能的故障情况设置告警，而是围绕与 SLO 违规相关的、会影响用户的信号来定义告警。这种方法可以确保告警具有实际意义且可操作，从而减少了告警噪音，同时为在告警影响值班工程师之前验证其有效性提供了更清晰的框架。
同样，Netflix也是通过自动化和实时可观测性工具来解决这个问题，他们大力投资于允许工程师在故障条件下模拟和测试系统行为的平台，通过将混沌工程实践与可观测性相结合，使团队可以验证告警是否触发。
其他使用Datadog或Prometheus等平台的组织也推出了告警预览、异常检测和历史回测等功能，以便增强人们对告警设置的信心。这些方法有一个明显的共同点：提高告警质量的关键不在于强制执行更严格的流程，而在于为工程师提供更清晰的可见性、更快的反馈，以及优先处理有意义的信号而非单纯关注告警数量的系统。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
原文链接：https://www.infoq.com/news/2026/03/airbnb-monitoring-alerts/
