故障复盘后的告警如何加出效果？浙江移动等老司机总结了 6 条注意事项

一分钟精华速览

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

TakinTalks 社区的 5 位专家，分别给出了 6 条注意事项，总结如下：

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

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

3.告警内容应该偏向业务和应用侧，这才能真正反映服务质量能否满足业务要求；

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

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

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

老师们针对今日热点话题都给出了自己的详细回答，感兴趣的可以往下浏览完整回答。👇

— — — — — — — — — — — — — — — — — — — — — — — —

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

这个问题是我非常关注的，我认为从业务视角（或者叫客户视角）的告警远比其他告警更重要。如果要加告警，你得先明确是不是业务视角漏了什么必须监控的指标，如果是，那么先加业务视角的监控。系统视角的监控，则更多用于预警（即将发生事故，需要立即处理）、分析（业务发生告警了，那么具体是哪儿的问题）。剩下的系统预警，如果能用统计报表(比如一些预期中的异常)或者自动提交 issue（比如硬盘损坏，需要更换）来达到目的，那么就不要加告警。两年前我就有做一个能自动分解业务层面告警的系统的想法，因为当我的业务出现问题了就代表我业务接触的某个系统出现了问题，背后一定是依赖的某个模块出现问题了，按照这个逻辑层层分解下去，对应部分的告警才是你应该关注的，而其他的比如说某个机器磁盘快满了、某个日志检测到一个错误信息，这些跟业务逻辑都没有关系，就不应该是你关注的重点，在你分析业务告警时，这些就需要自动隐藏起来。从业务视角出发像金字塔一样逐步深入往下分解告警最好，从这个角度去评判你复盘出来的添加告警的 action 要不要落地比较合理。

告警、工单、巡检的分工与侧重点不同，不应该所有内容都走告警渠道。

这个问题很典型，在我们的复盘报告里研发也会提出增加告警的需求，但其实很多人对告警的理解是有误区的。告警、工单和巡检是不一样的，分工和侧重点不同，我们不应该把所有通过监控系统发现的事件都走告警渠道。该走巡检来发现的问题走巡检，该走工单发现的问题走工单，当线上真的出现问题的时候才是一个告警。

告警内容应该偏向业务和应用侧，这才能真正反映服务质量能否满足业务要求。

告警要偏向业务和应用，它是最接近用户的指标，告警才能真正代表服务质量是否满足业务要求。目前 B 站的做法是定义好业务核心功能的 SLO 指标以及应用的 SLO 指标，基于业务和应用来做 SLO 告警。比如应用的成功率下降、应用的数据更新延迟、业务某个核心功能成功率下降等，这都是基于业务或应用 SLO 指标来做的告警，一旦告警就代表 SLI 指标受到了影响，用户体验可能有损。而机器的磁盘容量预警、cpu 容量预警、应用的连接池预警其实严格意义上并不能算告警，完全可以通过工单来处理；还有一些风险点，类似服务的抖动、突刺、重试等，这种也可以通过巡检的模式把问题找出来，然后走巡检工单去处理。

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

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

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

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

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

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

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

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

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

• 更快地、更准确地感知和定位问题

• 进而降低 MTTR、提升服务的稳定性(SLA)

• 最终提升服务的用户体验和满意度

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

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

查看更多【故障专题内容】