新盛公司联系我们
企业消息通知与告警机制的设计，核心在于把"正确的信息在正确的时间送到正确的人手上"。一套可用的告警体系至少需要解决四个问题：哪些事件值得告警、告警应该发给谁、通过什么渠道发、发出之后由谁负责闭环。如果只在业务代码里随手加几行发邮件、发短信的调用，短期内看似能用，但随着系统规模扩大，很快就会陷入告警风暴、关键告警被淹没、值班人员疲于应付却漏掉真实故障的局面。合理的做法是把通知能力从业务逻辑中抽离出来，做成独立的通知服务：业务侧只负责上报事件和级别，通知服务统一负责模板渲染、渠道分发、去重收敛、升级与统计。这样既能保证告警质量，也能让后续优化有数据可依。
为什么企业需要一套独立的告警通知体系
很多团队初期把告警逻辑直接写在业务代码里，比如订单支付失败就调用一次短信接口，服务器 CPU 超阈值就发一封邮件。这种做法在系统只有两三个服务时问题不大，但会带来几个结构性缺陷。
第一是耦合。业务代码需要关心短信服务商的 SDK、邮件模板、接收人列表，一旦更换渠道或调整模板，就要改动多个业务模块，回归成本高。第二是缺少统一治理。不同团队各自发送，同一个故障可能触发十几条重复通知，运维人员的手机在同一分钟内收到大量消息，真正的根因反而被淹没。第三是无法沉淀数据。告警发了多少条、有多少被确认、平均响应时长是多少，这些信息散落在各个系统里，无法用来评估告警质量。
独立通知体系的价值在于把"产生事件"和"投递事件"分开。业务系统通过统一的接口上报事件，通知服务负责后续所有环节：按规则匹配接收人、按级别选择渠道、按策略去重收敛、按值班表路由、按升级规则兜底。这样做的好处是告警策略可以集中配置和灰度调整，新增一个渠道只需要改通知服务，不用动业务代码；同时所有投递记录集中留存，为后续分析提供基础。
从架构上看，通知服务通常包含事件接入层、规则引擎、渠道适配层和记录与统计模块。事件接入层提供 HTTP 接口或消息队列订阅，接收业务上报的结构化事件；规则引擎根据事件类型、级别、标签匹配通知策略；渠道适配层封装站内信、邮件、短信、IM 等不同通道的差异；记录模块保存每次投递的状态，便于排查"为什么没收到"这类问题。
告警分级：把噪音挡在值班人员之外
告警分级的目的是让不同严重程度的问题走不同的处理路径。没有分级的告警体系，所有消息一视同仁地推给值班人员，结果就是重要故障和无关紧要的提示混在一起，久而久之值班人员对告警麻木，真正紧急的问题反而被忽略。
常见的分级方式是四级：紧急、重要、一般、提示。紧急级别对应核心业务不可用或数据面临丢失风险，需要立即人工介入；重要级别对应功能明显受损但仍有降级方案；一般级别对应指标异常但暂不影响用户；提示级别只做记录，不主动打扰人。分级不能只写在文档里，必须落到通知策略上：紧急级别走电话或强提醒 IM 并触发升级，重要级别走短信加 IM，一般级别走 IM 或站内信，提示级别只入库不推送。
分级的难点在于判断标准要可执行。建议为每个级别定义明确的触发条件，而不是让开发者凭感觉填写。例如可以规定：核心接口错误率连续若干分钟超过阈值、核心链路完全不可用、出现数据一致性问题，归为紧急；非核心功能异常、容量接近上限，归为重要；单实例异常但已被自动摘除，归为一般。标准写清楚之后，代码里上报级别就有据可依，评审时也容易发现级别定得过高或过低的情况。
另一个容易被忽视的点是"提示级别"的克制。很多团队把大量调试信息也做成告警推送，导致通道被占满。提示类信息应该进入日志或站内信列表，由需要的人主动查看，而不是主动推送。把噪音挡在推送环节之外，是提升告警可信度最直接的手段。
通知渠道怎么选：站内信、邮件、短信与IM的配合
不同渠道的时效性、成本和打扰程度差异明显，设计时要按"时效优先、成本可控、打扰适度"的原则组合使用，而不是所有告警都全渠道群发。
渠道时效性适用场景注意事项 站内信低，依赖用户主动查看提示类信息、处理结果回执、历史记录查询需要未读标记和消息中心入口，避免发出去无人知晓 邮件中，适合留痕日报周报、一般级别告警、需要附详情的通知容易被归入垃圾箱，不适合作为紧急告警的唯一通道 短信高，触达稳定紧急和重要级别、需要确保被看到的通知有成本，需控制发送量，配合去重避免重复计费 IM高，支持富文本和交互团队协作处理、一般到紧急级别的日常告警群消息容易被刷走，建议配合@指定负责人和卡片式消息实际组合时，可以按级别设定渠道矩阵：紧急级别先发 IM 并@值班人，若若干分钟内未确认则补发短信；重要级别发 IM 加邮件留痕；一般级别只发 IM 对应频道；提示级别只进站内信和日志。这样既保证紧急问题有人响应，又避免低级别信息消耗短信成本。
渠道选择还要考虑接收人的实际工作习惯。值班人员未必一直盯着邮件，也未必随时看群消息，因此紧急告警需要至少一条"强触达"通道。同时要提供确认机制，接收人点击确认后停止后续补发，未确认则按升级规则继续通知下一责任人。渠道适配层应把"发送成功"和"已被确认"区分开，前者只代表通道返回成功，后者才代表问题有人接手。
告警去重与收敛：让同一个问题只打扰一次
告警风暴往往不是因为有太多不同的问题，而是同一个问题被反复上报。比如一台机器磁盘写满，可能同时触发磁盘使用率、写入失败、服务健康检查失败等多条告警；一个下游服务超时，可能让几十个上游接口同时报错。如果不做收敛，值班人员看到的是满屏消息，很难判断根因。
去重的常见做法是给每条告警生成一个指纹，指纹由告警类型、受影响对象和关键标签组成。相同指纹的告警在时间窗口内只投递一次，后续重复上报只累加计数，不再重复推送。窗口长度按场景设定，短则几分钟，长则半小时，窗口结束后如果问题仍在，可以再提醒一次，但应标明"持续未恢复"而不是当作新告警。
收敛则是在去重基础上做聚合。可以把同一服务、同一机房或同一依赖链路上的多条告警合并成一条摘要消息，列出受影响的对象数量和代表性错误，而不是逐条罗列。对于由同一个根因引发的连锁告警，可以通过标签建立关联，例如给告警打上服务名、实例、依赖组件等标签，聚合时按标签分组。这样值班人员看到的是"某服务多个实例异常，疑似依赖的数据库连接池耗尽"，而不是几十条孤立的错误。
还要处理告警恢复。问题恢复后应发送恢复通知，并与原始告警关联，让处理人知道闭环完成。如果只发告警不发恢复，值班人员无法判断问题是否已经结束，容易重复排查。恢复通知同样要去重，避免恢复消息本身形成新的噪音。
值班与升级机制：告警发出之后谁来接
告警发出去只是开始，关键是有人接、有人处理、处理不了有人兜底。值班机制要明确三件事：谁在什么时间段负责、通过什么方式确认、超时之后通知谁。
值班表应按团队和维护范围配置，支持按天或按周轮换，并允许临时调班。告警路由时根据告警标签匹配到对应的值班组，再找到当前值班人。如果告警涉及多个团队，应指定一个主责团队，避免互相等待。值班信息要与人员组织信息保持同步，人员离职或转岗后及时更新，否则会出现告警发给已不在岗的人的情况。
升级机制是值班的兜底。可以设定多级升级：第一级通知当前值班人，若在规定时间内未确认，升级到备份值班人；仍未确认则升级到团队负责人；紧急级别还可以继续升级到更高层级。升级时间间隔按级别设定，紧急级别可以短一些，一般级别可以长一些。升级不只是换人，还应在消息中注明"已升级"和前一接收人未确认的事实，让接手人了解上下文。
确认动作要简单可操作。IM 卡片上提供确认按钮，或支持回复固定指令确认，避免要求处理人登录多个系统操作。确认后应记录确认人和确认时间，作为后续统计响应时长的依据。同时要允许"误报"标记，处理人确认后可以标注该告警为误报，这类数据是后续优化规则的重要输入。
告警内容怎么写才便于快速定位问题
告警内容是处理人看到的第一手信息，写得好可以省去大量排查时间，写得差就只剩一句"服务异常"，处理人还得从头查起。一条合格的告警应包含以下要素：发生了什么、影响范围、发生时间、当前状态、关键指标或错误信息、相关链接。
- 标题：一句话说明现象和对象，例如"订单服务支付回调错误率超阈值"，避免只写"告警"或"异常"。
- 级别与状态：标明紧急程度以及是触发还是恢复，方便快速判断优先级。
- 影响范围：涉及哪些服务、实例、机房或用户群体，数量尽量具体。
- 关键数据：触发时的指标值、阈值、错误码或代表性日志片段，不要贴大段无关日志。
- 时间信息：首次发生时间、最近一次发生时间、持续时长。
- 处理入口：监控面板、日志查询、相关文档或 Runbook 的链接，让处理人一步到位。
内容模板应按告警类型分别设计，而不是所有告警共用一套字段。指标类告警突出当前值和阈值，日志类告警突出错误摘要和出现次数，健康检查类告警突出失败原因和影响实例。模板中的变量由通知服务在渲染时填充，业务侧只上报结构化字段，避免各团队自行拼接字符串导致格式混乱。另外，告警文案要避免歧义，比如"连接数过高"应写明是哪个连接池、当前多少、阈值多少，否则处理人无法判断严重程度。
持续优化：用数据评估告警质量
告警体系上线后不是一劳永逸的，规则会随着业务变化而过时，阈值可能不再合理，接收人也可能已经调整。需要定期用数据评估告警质量，找出该降级的、该删除的和该补充的。
可以关注几类指标：告警总量及按级别分布，判断是否整体过多；去重收敛比例，比例过低说明重复上报严重；确认率与平均确认时长，反映值班响应情况；误报率，由处理人标记的误报占该规则触发次数的比例；升级次数，频繁升级可能说明第一接收人不合适或规则定得过严；以及长时间未确认的告警清单，这类告警要么不重要，要么路由错了。把这些指标按规则维度统计，就能定位到具体哪条规则在制造噪音。
优化动作要有节奏。可以定期review触发次数最多但确认率最低的规则，考虑降级、合并或删除；对频繁误报的规则调整阈值或增加抑制条件；对从未触发过的规则也要检查，可能是阈值过松或监控本身失效。每次调整保留变更记录，观察调整后指标的变化，形成闭环。告警质量不是追求零告警，而是让每一条推送都值得接收人停下手上的事去看一眼。做到这一点，通知体系才真正成为企业稳定运行的支撑，而不是新的负担。