一个非常古老的故事，至今仍是解释值班团队为何不再响应告警的最佳方式。先读故事，再看 NGN 如何帮助世界各地的 IT 团队解决这个问题。
从前，在村子上方的山坡上，有个牧童负责看守羊群。如果狼来了，他就要大声呼喊，全村人都会赶来帮忙。夜很长，可什么事都没发生过。
一天夜里，他实在无聊，深吸一口气，用尽全力大喊：狼来了！狼来了！
山下的村民放下手头的事，抓起火把和草叉，跑上山坡。狼在哪儿？！
根本没有狼。只有那个男孩在哈哈大笑。哈！骗到你们了！
村民们嘟囔着走下山去。
几个晚上之后，他又这样做了。一次，又一次。每次村民都跑来，每次都什么也没有。又来了……
过了一阵子，村民们不再跑了。喊声传来时，他们耸耸肩说又是那个孩子，
然后继续吃晚饭。松林里，有什么东西正在盯着。
后来有一天夜里，一只狼真的从树林里钻了出来，低伏着身子，悄无声息，直奔羊群。男孩喊得比以往任何时候都大声：狼来了！这次是真的！
山下的村民都听见了。他们之前已经听过上百次了。没有一个人来。
到了早上，羊群全都不见了。
说谎的人，即使说真话也没人相信。
这是伊索在两千五百多年前讲述的寓意。
把山坡换成机房，其他什么都不用改。这就是告警疲劳，它每天晚上都在世界各地的 IT 团队中上演。
Nagios、Icinga、Prometheus、Zabbix、Datadog、AWS CloudWatch、Azure Monitor、Microsoft 365：只要配置成那样，它们每一个都会对所有事情大喊大叫。CPU 达到 87%、证书 60 天后到期、备份多运行了六分钟。每一条听起来都有道理，合在一起就是噪音。
今晚值班
P主值班午夜以来 47 次呼叫已静音
S备值班手机已静音已睡着
#noc 别管了，又是那条 CPU 告警
一开始他们会立刻赶来。后来他们发现几乎每条告警都不需要他们做任何事，于是把频道静音，并开始用这种态度对待所有告警。
凌晨 3:07，核心路由器断开了互联网连接。这条告警出现在同一个频道、以同样的格式，夹在周围四十六条误报之中。
客户无法下单，员工无法工作，电话无人响起。这就是狼在无人看守时夺走的东西，而直到第一位客户打来电话，才有人发现。
告警频道里一个平静的夜晚。八个工具，各自用自己的话大喊，每一行都显得很紧急。其中一条就是明天早上会让您付出代价的故障，而值班工程师正半睡半醒地在手机上看这些。
就是这条。BGP neighbour down on core-rtr-01：主站点已断开互联网连接，而这条告警看起来和周围十条一模一样。
#alerts星期二，凌晨 3:11 · 11 条新消息
解决方法不是更响的警报，也不是更多的值班人员，而是一个只在狼真的来了时才喊“狼来了”的男孩，以及一个清楚知道他喊时该谁出动的村庄。
我们会梳理过去一个月实际触发的内容：每一条告警、它发给了谁，以及是否有人需要采取行动。
由业务部门而不是工程师来定义紧急情况：客户无法登录、订单停止、电话中断、数据面临风险。
告警基于用户能感知到的指标触发（延迟、流量、错误和饱和度，即 Google 的四大黄金信号），并基于服务消耗错误预算的速度触发，而不是每一次 CPU 尖峰。2,3
相关告警被合并为一条通知，在根因告警触发期间抑制连带告警，每条告警按服务和严重程度路由给负责人，并持续升级直到有人确认。4,5
每一条会叫醒人的告警都链接到一份简短的运行手册：它意味着什么、影响了谁、先检查什么、该联系谁。
您的工程师将学会编写告警，并主持每周十五分钟的复盘：触发了什么、是否有人需要行动、是否保留。从不需要处理的告警会被删除。
区别不在于更响的警报，而在于告警能说明利害关系、影响了谁、谁已经在处理，并悄悄地把噪音收起来。
之前
+ 今晚还有 46 条类似的告警。哪一条才重要？从这里根本看不出来。
之后
P1悉尼办公室离线已于 03:09 确认
38 条相关告警已合并到此条12 条连带告警已暂缓
运行手册： 上游 BGP 会话中断
NGN 与澳大利亚及世界各地的 IT 团队合作，可现场或远程进行，使用您现有的工具。
这则寓意出自伊索，距今已有两千五百多年。完整的方法以及基于症状的告警实例，请参阅如果您的监控在凌晨 3 点把您叫醒，那就不是监控；我们使用的监控工具见网络自动化与监控。
这是同一个故事。一个对任何事情都发出告警的监控系统，会让值班人员认为告警毫无意义，于是当真正的故障来临时，它也会像之前的误报一样被忽略。在 IT 领域，这被称为告警疲劳。和寓言一样，问题出在告警本身，而不在于那些不再响应的人。
没人看的告警频道或邮件文件夹；告警经常在没人查看的情况下就被确认；同一条告警每晚都会触发；客户比监控更早发现故障；只有一位资深工程师凭经验知道哪些告警是真的。只要出现其中任何一种情况，就说明这套告警需要重建。
只要方法得当，就不会。保留下来的告警围绕客户能感知到的问题构建，因此比一大堆 CPU 和磁盘警告更能可靠地发现真正的问题。我们还会跟踪那些没有任何告警就发生的事件，一旦有删减过度的地方，马上就能看出来。
重建本身通常需要几周时间，并使用您现有的工具，例如 Icinga2、Prometheus 或 Grafana。之后保持系统安静的每周复盘大约只需十五分钟。
遵循 Google 为其站点可靠性工程（SRE）团队公开的实践：每一次呼叫都必须可操作；告警基于用户能感知到的症状触发，而不是内部原因；是否呼叫取决于服务消耗错误预算的速度；一名值班工程师在十二小时的班次中最多只应处理两起事件。告警在 Prometheus Alertmanager 等工具中进行分组、抑制和路由，并持续升级，直到有人确认。
可以。NGN 提供全天候监控，告警按严重程度路由给我们的工程师，非工作时间则按您选择的升级路径处理，确保凌晨 3 点的真实告警也能送达能够立即处理的人。
We have used Next Generation Networks for several custom solution projects that went well beyond the standard scope listed on their website. Every time, the team has been exceptional—genuinely enthusiastic about tackling complex challenges and consistently delivering solutions that exceed…
James Johnson
View on Google
Great internet and phone service, excellent customer service.
Fiori Mercuri
View on Google
Impeccable support and service! Would highly recommend.
Samuel Tolentino
View on Google
⭐⭐⭐⭐⭐
Great service from Next Generation! They really helped us get our internet running fast and smoothly. The process was easy, and their team was very helpful and responsive. We’re really happy with the improved internet speed and connection. Highly recommended!
Mariwel Largosa
View on Google
We engaged Next Generation Networks to build the ecommerce site for South West Apparel, and we couldn't be happier with the result. The team's attention to detail was outstanding. Everything from the layout and product pages to the checkout experience was carefully thought through, and they took…
Houssam Homsi
View on Google
告诉我们您的告警情况。我们会使用您现有的工具，把嘈杂的监控重建为团队愿意响应的系统，通常只需几周。
我们会在同一个工作日内回复