有朋友问：我是业务应用的 DEV 或 SRE，我的应用依赖了底层服务和基础设施，比如依赖基础网络、Kubernetes、MySQL、收银台服务，那这些基础服务如果出问题，我应该收告警吗？夜莺里有个订阅规则，是不是就是为此设计的？
本文讲讲笔者的个人理解，欢迎大家留言一起探讨实践经验。
首先，请大家看一下上一篇文章《CPU负载高，到底应不应该告警？》，其中提到一个点：只有 actionable 的告警规则才有意义，网友的留言也很直白有效：没有 SOP 的告警都是垃圾！
所以，要看你们的情况：
1，如果你的服务是单机房部署，这些基础设施和服务出问题你无能为力，只能被动等待恢复，即你没有 SOP，那收这些告警意义不大。
此时推荐的做法是：做一个可视化页面，把你依赖的基础设施和服务的关键 SLI 放上去，你能通过查看 UI 趋势图，了解到各个基础设施和服务的健康状况即可。Facebook 有个内部产品叫 SLICK，就是类似的逻辑，我们创业做的 Flashcat 里有个功能叫“灭火图”，也有类似的效果。这算是一个惯常做法。
2，如果你有 SOP，比如可以切流，那么去订阅这类告警是有意义的。
但是，很多底层服务的关键指标你也未必看得懂，此时最好有个规范。比如，每个底层服务的负责人，在配置告警规则时，如果觉得那个告警规则很重要，对应的告警会影响上层服务，那就给那个规则打上一个特殊标签，比如 advertise=mysql 表示所有 MySQL 相关的需要周知的告警，之后上层应用的 DEV、SRE 就可以订阅这个标签，知悉相关的告警。
另外
MySQL、收银台这类服务，相比去订阅它们的 SLI 告警，更好的方式是在上层应用里自行埋点，主要是采集一下成功率、延迟就可以了。
因为从 MySQL 的视角来看，其 SLI 指标是面向整个实例的，而如果在上层应用埋点，其指标就可以细化到与这个服务相关，做得更精细化。
