告警分级与响应时间

RPC调用失败。积分没有到账。Telegram立即发送告警。

日志中出现可疑的邮箱不匹配。系统15分钟后检查。

支付成功。系统记录。没有告警。

三个事件，三种响应策略。这不是随意的，而是设计的结果。

一切紧急的代价

早期的监控系统对所有事情一视同仁。一条日志，一次计数增加，如果发生足够多次，可能发个告警。

这带来一个问题：当一切都触发告警时，没有任何事情能得到适当的关注。

RPC失败需要立即干预。用户支付了但没有收到积分。这是影响金钱和信任的业务关键失败。15分钟后响应太慢了——用户可能已经联系了客服，或者更糟，要求退款。

邮箱不匹配可能是安全隐患，但它已经被拒绝了。交易没有完成。系统是安全的。15分钟后响应是可以的——你需要时间来判断这是模式（攻击）还是一次性的错误（用户输错）。

支付成功根本不需要人工关注。这是按设计工作的。记录它对分析和调试有用，但对它发告警就是噪音。

关键洞见：不同的问题需要不同的响应时间。

三个级别，三种含义

告警级别不是抽象的严重程度。而是所需的响应时间。

Critical：立即响应

用于延迟会直接造成损害的情况：

• RPC调用失败（客户损失金钱）
• 数据库连接丢失（系统无法运行）
• 支付处理错误（收入损失）

这些会在凌晨3点叫醒人。它们应该很罕见。如果不罕见，说明系统从根本上坏了。

规则：Critical意味着必须在几分钟内采取行动。

Warning：监控模式

用于需要关注但不紧急的情况：

• 安全事件（邮箱不匹配、可疑模式）
• 速率限制接近（尚未超出）
• 性能下降（慢但仍在工作）

这些不需要立即行动。它们需要模式分析。

一个邮箱不匹配不是危机。一小时内十个可能意味着攻击。一个慢查询不是问题。所有查询都在变慢意味着负载问题。

系统每15分钟检查一次这些。这个间隔是经过深思熟虑的：

• 足够频繁以快速捕获问题
• 足够稀疏以将相关事件批量处理
• 足够长以区分模式和噪音

规则：Warning意味着需要在几小时内审查。

Info：仅记录

用于正常操作：

• 支付成功
• Webhook处理成功
• 常规健康检查
• 预期的验证

这些不需要人工关注。它们存在的目的是：

• 出错时调试
• 分析和商业智能
• 审计轨迹
• 成功率计算

规则：Info意味着记录以供后续分析，不告警。

为什么安全检查是15分钟

选择15分钟作为安全事件检查间隔不是随机的。它平衡了多个因素。

太频繁（每分钟）：

• 每天1440次检查
• 持续查询带来的数据库负载
• 重复检查产生的日志噪音
• 瞬时问题造成的虚假紧急感

太稀疏（每小时）：

• 每天24次检查
• 对攻击的响应延迟
• 一次性处理大批事件
• 更难关联时间

15分钟（最优）：

• 每天96次检查
• 在合理时间内捕获问题
• 自然地批量处理相关事件
• 最小的系统负载

更重要的是，15分钟符合安全分析的自然节奏。你不是在响应单个事件——你在寻找模式。一次攻击在第5分钟检测到与在第15分钟检测到并没有变得更严重。重要的是在模式成功之前捕获它。

告警疲劳与信号保存

监控系统最常见的失败模式不是错过重要告警——而是淹没在不重要的告警中。

当你每天收到50个告警，其中45个不需要采取行动时，你会停止认真对待告警。这就是告警疲劳。这是一种防御机制。大脑学会了大多数告警都是误报，并开始忽略它们。

然后当真正的危机发生时，告警到达，没有人快速响应，因为他们已经被训练成认为告警无关紧要。

这就是为什么告警级别必须映射到实际响应时间。如果某事触发了Critical告警，最好有人在几分钟内响应。如果没有发生，要么：

1. 告警级别错了（应该是Warning或Info）
2. 响应流程错了（需要更好的值班程序）
3. 系统从根本上不可靠（需要架构修复）

解决方案不是更好的告警工具。而是更好的告警纪律。

每个告警应该回答两个问题：

1. 什么出错了？
2. 我应该采取什么行动？

如果你无法回答这两个问题，就不应该告警。

相关阅读：what-monitoring-systems-see 讨论了日志级别以及监控系统应该记录什么。monitoring-observation-period 介绍了如何验证监控改进是否真正有效。

全面记录，选择性告警

记录和告警之间有微妙的区别。

记录意味着写入日志，存储在指标数据库中，使数据可供分析。这应该是全面的。每个重要事件，每个决策点，每个状态转换。

告警意味着向人类发送通知。这应该是选择性的。只有需要人工行动的事件。

Telegram告警系统展示了这一点：

记录但不告警：

• 每个接收到的webhook
• 每次签名验证
• 每次RPC调用持续时间
• 每次支付成功

Warning级别告警：

• 邮箱不匹配（需要模式分析）
• 速率限制接近（预防性行动）
• 订阅取消（商业智能）

Critical级别告警：

• RPC失败（涉及金钱）
• 系统配置错误（阻塞操作）
• 认证失败（安全漏洞）

这种分离意味着你有完整的数据用于调试，而告警频道中没有噪音。调查问题时，你可以重建发生的一切。但在日常工作中，你只听到需要采取行动的事情。

时间指标优于布尔标志

Telegram告警系统的另一个关键洞见：记录时间，而不仅仅是成功/失败。

传统监控跟踪二元状态：

• 成功了吗？是/否
• 多少次？计数
• 多久一次？频率

这忽略了一个关键维度：性能下降。

一个系统可以有99%的成功率，同时正在死亡。如果每个请求需要10秒而不是100毫秒，用户正在离开。但成功率看起来很好。

这就是为什么每个记录的事件都应该包含持续时间指标：

• duration_ms - 这一步花了多长时间
• rpc_duration_ms - 外部调用花了多长时间
• total_duration_ms - 整个流程花了多长时间

这些指标揭示了成功率隐藏的问题：

• 渐进性能下降（查询越来越慢）
• 瓶颈识别（哪一步慢）
• 超时风险预测（接近超时阈值）

时间序列数据将监控从被动变为预测性。你在问题成为故障之前就看到它们正在形成。

为正确的响应而设计

告警设计的根本问题不是"什么出错了？"——而是"接下来应该发生什么？"

RPC失败应该触发立即调查和可能的回滚。这就是为什么它是Critical。

安全事件应该在工作时间作为模式分析的一部分进行审查。这就是为什么它是Warning并每15分钟检查一次。

支付成功应该记录用于分析，但不需要人工关注。这就是为什么它是Info并且从不告警。

每个告警级别意味着一个响应时间。每个响应时间意味着组织承诺。如果你无法承诺对Critical告警在5分钟内响应，就不要使用Critical告警。

这不是关于技术。而是关于将系统设计与运营现实对齐。

你的监控系统应该反映你实际做的事情，而不是你希望做的事情。如果没有人在凌晨3点响应告警，就不要在凌晨3点发送Critical告警。要么修复你的值班流程，要么降低告警级别。

最好的监控系统是这样的：

• Critical告警很罕见，总是被处理
• Warning告警定期审查并推动改进
• Info日志全面且对调试有用
• 没有人经历告警疲劳
• 真正的问题得到适当的响应

这不是通过更好的工具实现的。而是通过更好的告警纪律实现的。

系统告诉我们的

Telegram告警部署揭示了一些重要的事情：我们认为需要告警的大部分事情实际上不需要。

Webhook流程中的七个事件。只有两个条件触发告警：

• RPC失败（Critical）
• 安全事件（Warning，批量处理）

其他一切都被记录但保持沉默。这是设计使然。

系统每天处理数百个webhook。如果每个都生成告警，频道将无法使用。通过只对需要响应的条件告警，信噪比保持高水平。

当告警到达时，它意味着某事。人们响应。问题得到修复。

这就是良好监控的样子：全面记录，选择性告警，以及与实际紧急程度匹配的响应时间。