某企业内部故障统计数据显示85%的异常是靠用户上报发现而非监控发现。针对一个故障场景增加一个告警，往往需要增加数百上千个监控项，这样加下去，真的能提升业务异常的监控效率吗？到底告警要怎样加才是有效的？

TakinTalks社区的4位专家，分别给出了这些注意事项，总结如下：

1.业务视角的告警比其他告警更重要，是评判告警该不该加的重要标准。

2.告警要紧贴业务，而业务分核心与非核心，围绕核心用户旅程也就是系统的核心业务来布局告警才是重点

3.在添加告警前先问自己一个问题“这个告警是否能帮助我们达成业务目标”答案就出来了。

4.除了明确告警该不该加，更应该考虑能否将产生告警的驱动转化成面向失败的设计，从而完成自动化闭环，提升故障处理效率。

李道兵-奈雪的茶高级技术总监:

业务视角的告警比其他告警更重要，是评判告警该不该加的重要标准。这个问题是我非常关注的，我认为从业务视角（或者叫客户视角）的告警远比其他告警更重要。如果要加告警，你得先明确是不是业务视角漏了什么必须监控的指标，如果是，那么先加业务视角的监控。系统视角的监控，则更多用于预警（即将发生事故，需要立即处理）、分析（业务发生告警了，那么具体是哪儿的问题）。剩下的系统预警，如果能用统计报表(比如一些预期中的异常)或者自动提交issue（比如硬盘损坏，需要更换）来达到目的，那么就不要加告警。

两年前我就有做一个能自动分解业务层面告警的系统的想法，因为当我的业务出现问题了就代表我业务接触的某个系统出现了问题，背后一定是依赖的某个模块出现问题了，按照这个逻辑层层分解下去，对应部分的告警才是你应该关注的，而其他的比如说某个机器磁盘快满了、某个日志检测到一个错误信息，这些跟业务逻辑都没有关系，就不应该是你关注的重点，在你分析业务告警时，这些就需要自动隐藏起来。从业务视角出发像金字塔一样逐步深入往下分解告警最好，从这个角度去评判你复盘出来的添加告警的action要不要落地比较合理。

杨德华TakinTalks社区发起人:

       告警要紧贴业务，而业务分核心与非核心，围绕核心用户旅程也就是系统的核心业务来布局告警才是重点。

如果一直不断增加系统底层的告警，告警就会极度泛滥，所以告警要结合业务来做。我刚毕业的时候在阿里做数据库，有一次被拉着做故障复盘，我提出的需求就是要加一个告警，我的师兄就问我“你这个告警要加到猴年马月去，数据库现在已经有几百个告警了，加上你说的这个有什么用？”我当时觉得他不懂，后来才发现是我太年轻，那时淘宝一年发告警短信花费就有几百万之多。

告警除了要紧贴业务，还有一个点需要注意，业务分核心业务与非核心业务，谷歌SRE里面有一个概念叫「CUJ」，也就是「核心用户旅程」，在我看来围绕核心用户旅程也就是系统的核心业务来布局告警才是重点。
史军艇浙江移动SRE架构师:

 除了明确告警该不该加，更应该考虑能否将产生告警的驱动转化成面向失败的设计，从而完成自动化闭环，提升故障处理效率。

我们在故障复盘中，肯定是会剖析到一个很重要的点：故障期间可观测性是否生效，告警是否做到了有效触达。关于如何判断这个告警是否需要添加，我们的评判标准是这个告警是否可以帮我们达到业务快速恢复的最终目标。

另外其实在目前的运维体系中，告警是需要压缩/降噪的。所以在故障复盘时，我认为在考虑告警action要不要加之前，得先考虑这样一个问题：能不能把产生这个告警的驱动，改造成一个面向失败的设计，由这个设计完成自动化闭环，提升到不需要人介入，甚至不需要人看到。久而久之，养成这个思维方式最终会对整个应急团队的处理效率有更好的提升。
石鹏美图高级运维经理:

在添加告警前先问自己一个问题“这个告警是否能帮助我们达成业务目标”答案就出来了。

在故障复盘之后得出的待办事项中，完善监控告警、增加或完善制度流程都是一些常规的选项。但是这些选项是否必要，则需要审慎地来看，处理不当可能会产生负作用。

监控告警是否应该添加这个问题，我感觉或许可以转换为“这个告警是否能帮助我们达成业务目标”，即是否能帮助我们：

  • 更快地、更准确地感知和定位问题
  • 进而降低MTTR、提升服务的稳定性(SLA)
  • 最终提升服务的用户体验和满意度

因此，这里我们可以用“以终为始”的思路来回答这个问题，我们可以定义和归纳一组可以真实反馈业务的关键指标，这些指标在业界可能会有不同的称呼，比如“业务黄金指标”、“北极星指标”等。在此基础上去构建端到端的全链路监控，在关键的节点上安插指标告警。

故障复盘的时候，原则上我们就可以来审视这套关键指标/告警是否正常工作，是否覆盖完善，是否需要更新迭代。如果讨论得出的告警并不能有效的回答上面的几个问题，那这些个告警大概率是无需增加的。