线上告警响起时，最怕一群人同时翻日志、改配置、重启服务，却没人确认用户影响和止血动作。告警处理要有顺序：先判断影响面，再恢复服务，再定位根因，最后复盘沉淀。
第一步确认影响面
先看告警类型：错误率、耗时、CPU、内存、磁盘、队列积压、连接池耗尽还是外部依赖失败。再看影响范围：单实例、单接口、单租户、全站，还是某个下游系统。
这一步不要陷入细节，目标是判断是否需要立即回滚、扩容、降级、切流或暂停任务。用户正在受影响时，优先恢复可用性。
第二步执行止血动作
常见止血动作包括回滚版本、关闭开关、限流降级、扩容实例、清理磁盘、暂停批任务、切换备用依赖。动作要有人负责，有开始时间和结果记录。
止血时不要做不可逆清理。比如大范围删除数据、重建库表、清空队列，都必须谨慎确认。能通过暂停、隔离、限流解决的，先不要把现场破坏掉。
第三步定位根因
服务恢复后，再回到日志、指标、链路追踪和发布记录。定位时按时间线看：告警前有没有发布、配置变更、流量变化、数据导入、第三方波动或定时任务启动。
根因要具体到可修复动作。不要停在“数据库慢”“服务异常”“依赖不稳定”这种泛泛描述，要说明是哪条 SQL、哪个接口、哪个配置、哪个数据分布导致的问题。
第四步复盘改进
复盘至少包含影响范围、发现时间、止血动作、根因、修复方案和预防措施。预防措施最好能落到监控、测试、发布清单、限流策略或代码改动。
告警处理的成熟度，不是永远不出问题，而是每次问题都能更快恢复、更准定位、更少复发。
正文完
