打开网易新闻 查看精彩图片

Airbnb最近复盘了一桩"悬案"：他们的告警系统吵了多年，值班工程师被半夜叫醒无数次，所有人都说是"文化问题"——工程师太懒、太糙、太不爱写好的告警规则。但查到最后发现，真凶根本不是人。

是工具。

具体来说，是工程师在把告警部署到生产环境之前，根本看不见这玩意儿会怎么表现。Airbnb用"可观测性即代码"（OaC）管着大约30万条告警，代码审查能过语法、能过逻辑，但过不了现实——这条告警会不会误报？会不会漏报？会不会凌晨三点把睡梦中的同事轰起来？没人知道。生产环境成了唯一试验场，改完部署，等上几周看效果，不行再改。循环几次，团队累了，告警烂了，信任崩了。

这就像让厨师在客人桌上尝咸淡。不是厨师不想做好菜，是厨房没给试吃的机会。

Airbnb的解法是把"试吃"环节搬进厨房。他们重建了平台，让工程师在合并代码前就能用真实数据预览告警行为：本地差异对比、部署前验证、大规模历史回测——几秒钟知道结果，而不是几周。验证左移，测试从生产环境挪到开发工作流，告警开发周期从数周压到数分钟，噪音砍掉90%，30万条告警顺利迁移到新平台。

这套思路不是Airbnb独创。Google用SLO和错误预算替代"所有故障都告警"，Netflix把混沌工程和可观测性拧在一起，Datadog、Prometheus们也在推告警预览和回测。共同点是：别跟工程师较劲，给工程师眼睛。

Airbnb最后有个挺反直觉的结论：规模大了之后，修系统比管人管用。当工具让正确的事变得容易，文化自然会跟上来。一位工程师在内部反馈里写，现在改告警"像改单元测试一样无压力"——这才是可观测性该有的样子：不是生产环境的消防队，是写代码时的副驾驶。