凌晨两点，微信群突然炸了。值班的李工刚摸到手机，就看到一堆截图和@全体成员。公司官网打不开，用户投诉电话已经接不过来。他没敢多想，直接连上跳板机，开始排查。
事件触发：监控报警与人工上报
这类问题通常有两个入口：一个是监控系统自动告警，比如Zabbix或Prometheus发现Web服务502错误率飙升；另一个是业务方人工上报，比如客服群里发来的用户反馈截图。这次是后者先冒头，但三分钟后，监控平台也弹出了红色预警。
初步定位：分层排查法走起
李工第一反应不是重启服务，而是分层查。先看网络层通不通：
ping www.example.com能通。再查端口：
telnet www.example.com 443超时。说明服务器虽然在线，但HTTPS服务挂了。接着登录负载均衡器，发现后端节点全部被标记为“异常”。问题大概率出在应用层。
深入排查：日志与资源状态双线并进
他切到应用服务器，用top命令一看，CPU跑满，Java进程占了98%。顺手抓一下当前线程堆栈：
jstack <pid> > /tmp/thread_dump.log同时翻Nginx访问日志，发现大量来自某个固定IP段的POST请求，路径集中在/api/submit这个接口。请求频率高得不正常，明显是爬虫或者恶意刷单。
应急处置：临时封禁+服务恢复
情况清楚了，先保服务。他在防火墙加了一条规则：
iptables -I INPUT -s 116.204.0.0/16 -j DROP然后重启Java服务，负载很快恢复正常。网站重新可访问，客服那边也收到反馈说用户能下单了。
后续动作：日志留存与策略加固
天亮后团队开会复盘。安全组把那个IP段加入黑名单，运维把类似请求频率监控写进Prometheus，开发也在接口加了限流中间件。一周后，同样的攻击又来了两次，都被自动拦截，没再出事。
标准流程不是纸上谈兵
很多人觉得流程文档看着复杂，实际干起来还是凭感觉。但真遇到半夜告警，有流程在，每一步做什么心里有底。从事件上报、分类定级、定位分析、应急响应到事后复盘，每个环节都对应具体动作。比如这次的处理，其实就套用了ITIL里的事件管理框架，只是大家平时不说术语罢了。
真正的网络事件处理，不是背流程，而是在压力下把流程变成肌肉记忆。你可能记不住所有命令，但得知道先查什么、再问谁、最后留什么证据。这才是运维的日常。