3. 告警阈值概念与意义
告警阈值这东西，听起来好像只是个数字，但在我带过的几个密码迁移项目里，它往往是整个监控系统最容易被忽视、又最能“坑人”的环节。说白了，阈值就是你给系统划的一条线——线这边算正常，线那边就告警。但这线划在哪，学问可不小。
3.1 阈值到底在说什么
咱们先聊定义。告警阈值，就是触发告警的边界值。在密码迁移的场景里，我习惯把阈值分成两类：
- 单次阈值：比如一次登录失败的次数、一次校验的耗时上限。
- 统计阈值：比如5分钟内失败率超过多少，或者连续3次出现超时。
你想想看，如果没有阈值，系统要么每件小事都报警，要么死到临头了才通知你。两种都不行。
我的经验：有一次给某金融平台做密码迁移，他们把所有失败的校验都告警了。结果一天收到2万条告警，运维直接麻木了，连真正的攻击都没看见。
3.2 密码迁移中阈值的特殊角色
跟常规的服务器监控不一样，密码迁移的阈值有几个独特的作用：
- 区分“正常失败”和“异常失败”——用户在迁移过程中输错一两次密码是正常的，但连续失败50次就不对了。
- 控制迁移节奏——阈值设得太高，迁移速度会慢得像蜗牛；设得太低，大批用户会被锁住。
- 辅助判断回滚时机——我记得在一个政府项目中，我们就靠一个“单小时失败率超过15%”的阈值决定停止迁移，那个阈值救了我们整个上线窗口。
我个人建议，初始阈值不要拍脑袋定，可以先根据历史数据的P95或者P99来算。比如过去一周的失败率分布，取第95百分位作为上限阈值。
3.3 误报与漏报：跷跷板的两端
做阈值设置最头疼的就是平衡误报和漏报。我经常跟团队说：“你不可能两头都占便宜。”
- 误报（False Positive）：该报的没报？哦对不起，是不该报的报了。比如用户只是输错一次密码，你发了一个高危告警，运维人员白白消耗精力。
- 漏报（False Negative）：真正的攻击或者系统故障发生了，但阈值太宽没捕获到。这个更可怕，可能数据全被盗了你都不知道。
为什么会这样？因为阈值就是一个切分点。切得太紧，误报多；切得太松，漏报多。我管这叫“阈值三难困境”——你永远要在准确性、敏感度和稳定性之间取舍。
我曾经踩过的坑：有一次把告警延时阈值设成200ms，结果大量正常用户因为网络抖动被误报。后来改成“连续3次超过500ms”才告警，误报率从40%降到了2%。
3.4 常用阈值类型速查
下面这个表是我自己整理的一个对照，你可以参考着用：
| 阈值类型 | 典型值（示例） | 主要风险 |
|---|---|---|
| 单次登录失败次数 | 3次/分钟 | 误报：用户输错密码；漏报：暴力破解 |
| 连续登录失败次数 | 10次/5分钟 | 漏报：低频攻击可能绕过 |
| API响应延迟 | 500ms（单次）/ 1s（平均） | 误报：网络波动；漏报：后端慢查询被掩盖 |
| 密码重试间隔 | 小于1秒 | 可能把正常用户脚本误报为攻击 |
| 迁移失败率 | 5%（5分钟内） | 漏报：如果基数大，5%可能已经很大了 |
嗯，这里要注意：上表里的数值只是示例，不同业务场景差得很远。我建议你先跑一周的模拟数据，再调参。
3.5 核心知识体系：一张图看懂
下面这张SVG图把阈值概念、作用、误报漏报平衡串起来了。你可以用它跟团队讲解：
3.6 怎么找到你自己的平衡点
说了这么多，到底怎么设？我的做法是三步走：
- 收集基线数据——在迁移前跑一段“影子模式”，把所有密码操作都记录但不阻断，算出正常情况下的失败率分布。
- 设定初始阈值——我习惯把初始阈值放在P95和P99之间。比如95%的失败都低于1%，那我就把阈值设在1.5%。
- 逐步收紧——上线后每天看误报率，如果误报太高，就放宽一点；如果漏报明显，就收紧。这个过程大概要持续一周才能稳定。
特别提醒：千万别在迁移进行中大规模改阈值——我见过一次，因为误报太多，运维直接把阈值改成无限大，结果攻击成功了都没发现。改阈值一定要走变更流程，有审批，有回滚方案。
最后说句实在话：阈值没有一劳永逸的。你的用户行为在变，攻击手段也在变。我建议每个季度重新评估一次，或者每次密码策略变更后都复查。做好告警阈值，才能让密码迁移真正“安全平稳”。