有朋友問：我是業務應用的 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 指標是面向整個實例的，而如果在上層應用埋點，其指標就可以細化到與這個服務相關，做得更精細化。