如何在网站宕机时设置 Slack 告警
2026 年,Slack 是大多数工程团队默认的告警渠道。设置本身只需要十分钟。但要做对(让频道在真实事件中有用,在平静的一周里可以忽略)则需要多花一些心思。本指南涵盖实用的设置流程、防止告警刷屏的路由规则,以及那些能让频道在多年间保持愉悦的小细节。
10 分钟搭建流程
标准做法是使用 Slack 的 Incoming Webhooks。创建一个专门的告警频道(通常是 #alerts 或 #ops-alerts),添加 Incoming Webhook 应用,将其指向该频道,然后把生成的 URL 作为新的 Slack 通知渠道粘贴到你的监控工具中。
大多数正常运行时间监控随后会发送一条带格式的消息,包含监控名称、失败原因、状态码(如果适用)以及返回仪表盘的链接。在依赖它之前,用一次刻意的失败来测试集成。一个指向故意失效 URL 的监控,是你能运行的最廉价的端到端测试。
防止告警刷屏的四条路由规则
一个每季度才收到一次告警的频道会教会人们去查看。一个每周收到五十次告警的频道会教会人们去静音。四条路由规则能让告警与信号的比例保持合理。
- 至少连续 3 次失败的阈值告警才向频道发送通知。漏掉一次检查是噪音。连续三次才是信号。
- 恢复消息发送到与失败相同的频道。已解决的事件需要一条收尾消息,否则频道会一直保持红色。
- 生产和预发布使用独立频道。预发布告警发送到 #ops-staging-alerts;生产告警发送到 #ops-prod-alerts。交叉污染会同时扼杀两边的信号。
- 按监控为最高优先级服务设置路由。面向客户的结账监控发送到独立的 #ops-incidents 频道,该频道有更高强度的值班承诺。
真正有帮助的消息格式
监控工具默认的 Slack 消息通常已经够用了。改进来自一两处自定义补充,它们会在真实事件中带来回报。
如果你有 runbook,就附上链接。在告警消息底部加一小行指向事件响应 runbook 的链接,能让值班工程师在凌晨 3 点节省九十秒。如果监控最近抖动过,附上「上次变红时间」时间戳。重复发生的事件在事后复盘时是宝贵的诊断线索。
Slack 不够用的时候
Slack 是一个聊天频道,不是寻呼系统。有三种失败模式无法通过往 Slack 添加告警来解决。
- 夜间事件——此时无人在看 Slack。需要在 Slack 频道之上叠加一个寻呼工具(PagerDuty、Opsgenie、Better Stack On-Call)以提供非工作时段的覆盖。
- 移动端通知掉线。Slack 移动应用可能在弱信号时段缓冲通知。关键告警需要一个完全绕过 Slack 的独立通道。
- 频道静音或专注模式。Slack 自身的免打扰设置会让告警静音。寻呼工具会忽略 DND。
让频道保持可用的卫生习惯
三个小习惯能让 Slack 告警频道在六个月后依然让人愿意使用。
把一条 runbook 消息钉在频道顶部。当某个告警正在被调查时,用大拇指表情回应它,这样其他读者就知道有人在处理。每季度审查一次告警量,裁掉那些噪音多于信号的监控。每季度清理一次的频道,才能在多年间保持有用。
30 分钟入门设置
创建 #ops-alerts 和 #ops-incidents 两个独立频道。为每个频道添加 Slack Incoming Webhook。配置监控工具,按连续 3 次失败的阈值向 #ops-alerts 发送 DOWN 事件。把最高优先级的面向客户的监控改为发送到 #ops-incidents。为两个频道都加上 UP 恢复消息。钉一条 runbook 消息。用一个故意损坏的监控进行测试。总耗时:三十分钟。总价值:未来每一次事件在 Slack 中都有清晰、可浏览的历史。
