简洁的故障应急处理方案.docxVIP

简洁的故障应急处理方案

一、场景设定

某中型互联网公司核心支付集群部署在两地三中心，主库位于A城机房，备库在B城，异地冷备在C城。凌晨02:17，值班工程师收到Prometheus告警：A城主库CPU飙至98%，QPS从1.8万骤降到300，订单接口超时率100%，用户支付失败。同时，Zabbix报告A城核心交换机端口CRC错误激增，丢包率12%。客服系统涌入2000+客诉，舆情监测显示“无法付款”关键词10分钟冲上热搜。

二、第一响应（0-3分钟）

1.值班工程师立即在作战群发出“P0故障”口令，@DBA、@网络、@应用、@SRE、@客服、@公关，所有人禁言，仅允许结构化信息。

2.自动语音电话同时拨给技术负责人、运维总监、CTO，响铃不超过15秒必须接听。

3.工程师本地执行`kubectltopnode`，确认CPU瓶颈在db-primary-0节点；同时`mtr-n-c10010.1.7.1`发现第6跳丢包，定位到交换机SW-A01。

4.在作战群发出第一条结构化消息：

`[时间]02:17:33|[级别]P0|[现象]支付超时100%|[指标]CPU98%|[定位]db-primary-0+SW-A01|[owner]张三`

三、故障隔离（3-8分钟）

1.网络组登录SW-A01，发现端口Eth1/5光模块收光-18dBm，低于临界值；立即执行`shutdown`关闭该端口，流量瞬间切换到Eth1/6，丢包率降到0.1%，QPS回升到1.2万。

2.DBA确认主库仍CPU98%，判断为异常SQL引发。通过`showprocesslist`抓到一条缺少索引的`SELECT…FORUPDATE`全表扫描，每秒锁行30万。DBA立即`kill连接ID`，CPU降到42%，QPS恢复到1.6万。

3.应用组在API网关层面对`/pay`路径开启降级，返回静态“支付通道繁忙，请稍后重试”，避免用户重复点击放大流量。

4.客服组在工单系统打上“P0支付故障”标签，自动回复模板切换为“技术正在紧急处理，预计10分钟恢复”，降低人工进线。

四、快速恢复（8-20分钟）

1.网络组更换光模块后，Eth1/5重新`noshutdown`，CRC错误清零，链路回切，流量负载均衡。

2.DBA对问题SQL添加联合索引`(user_id,status,create_time)`，执行时间从3.8s降到6ms；同时把慢查询阈值从1s调到100ms，防止同类SQL再次击穿。

3.应用组灰度重启支付微服务pod-8，逐步放开流量，观测P99延迟从2.3s降到180ms；错误率从12%降到0.2%。

4.风控组临时下调支付限额，单笔最高5千元，降低数据库写入压力。

5.02:26，监控大屏全部变绿，作战群发出“支付恢复”口令，客服把自动回复改为“已全面恢复，可重新支付”。

五、深度复盘（20-60分钟）

1.网络组提取SW-A01日志，发现光模块温度在7天内从45℃阶梯上升到73℃，触发误码；根因是机柜空调送风被新上架GPU服务器遮挡，形成热点。

2.DBA提取慢查询日志，发现该SQL在上周灰度发布的新营销活动中首次出现，研发未走SQL评审，索引遗漏。

3.应用组检查熔断配置，Hystrix超时设定3s，但数据库已无法支撑，导致线程池快速打满；后续改为动态超时，根据P99实时调整。

4.公关组监测微博负面情绪，02:40热度开始下降；通过官方账号发布“凌晨支付短暂异常已修复，无资金损失”，点赞1.2万，负面占比从62%降到9%。

六、长期治理（60分钟-7天）

1.网络：

a.机柜级温度传感器接入Prometheus，65℃自动开ticket；

b.光模块统一换为工业级，MTBF从50万小时提到100万小时；

c.每月执行`showinterfacecounterserrors|includeCRC`巡检脚本，异常立即更换。

2.数据库：

a.所有DDL必须走GitLabMR，自动关联表大小、QPS、索引覆盖率，评分80分拒绝合并；

b.引入Vitess分片，把热点用户表按`user_id%64`拆分，单片数据量500G；

c.在线改表使用`gh-ost`，峰值延迟不超过30ms，失败自动回滚。

3.应用：

a.支付链路接入Sentinel，按UID限流，每秒令牌桶1万，超量返回“请稍后再试”；

b.核心接口增加自适应超时，算法：`b