云上事件响应实战：从发现故障到快速恢复，建立应急响应机制
凌晨三点，手机又响了。
你迷迷糊糊摸到手机，屏幕上是一条告警：“订单服务响应时间超过5秒”。你揉了揉眼睛，打开笔记本电脑，VPN连上，登录Grafana。CPU看起来正常，内存也够，但错误日志在疯狂滚动。
你开始翻日志，一条一条看。十五分钟后，你发现是数据库连接池爆了。你重启了连接池，服务恢复了。但你不知道为什么会爆，也不知道还会不会爆。你盯着屏幕，不敢再去睡。
这是大多数运维人员的真实写照：出了问题，手忙脚乱地救火，救完了也不知道火是怎么烧起来的。
今天聊聊云上事件响应。不是那种“应急预案很重要”的废话，而是帮你理清楚：从发现故障到恢复服务，每一步该做什么、谁来做、怎么做，才能从“救火队员”变成“火情指挥官”。
01 先认清一个现实：出事是常态，不出事才奇怪
很多人做系统设计时，总假设“系统不会出问题”。这是最大的幻觉。
云服务商会挂，光缆会被挖断，代码会有bug，人会误操作。不是会不会出事的问题，是什么时候出事的问题。
认清这个现实后，你的心态会变：从“怎么避免故障”变成“故障来了怎么扛得住”。这两个心态的差别，决定了你是被动救火还是主动响应。
反常识观点：响应计划不是文档，是演练出来的肌肉记忆。 花两周写的应急预案，如果没演练过，真出事的时候没人会翻开看。
02 响应五阶段：从发现到恢复
把一次完整的事件响应拆成五个阶段，每个阶段的目标不同，做的事也不同。
第一阶段：发现
故障怎么被发现的？监控告警、用户投诉、还是自己刷后台时偶然看到？
好的响应机制，不依赖“谁恰好看到”。应该是监控系统主动告诉你：什么服务、什么指标、什么时候开始异常。
这一阶段的目标是：快速确认是不是真故障，避免告警疲劳。
第二阶段：遏制
确认是故障后，第一反应不是找原因，是止损。
流量切走：把出问题的服务从负载均衡里摘掉
回滚版本：怀疑是新代码导致的，立刻回滚
限流降级：关掉非核心功能，保住核心业务
快照恢复：数据出问题，从最近的备份恢复
这一阶段的目标是：让用户尽快能用，哪怕功能不全。
很多人在这里犯错误：先花半小时查原因，再想办法修。正确的顺序是先恢复服务，再查根因。用户不关心你代码哪里写错了，只关心能不能下单。
第三阶段：根因分析
服务恢复了，开始查为什么出问题。
看监控：CPU、内存、网络、IO，哪个指标异常？
看日志：错误日志、访问日志，有没有线索？
看变更记录：最近谁改了代码、改了配置、发了新版本？
看依赖：下游服务、数据库、缓存，有没有故障？
这一阶段的目标是：找到根本原因，而不是表面现象。
第四阶段：恢复
找到原因后，彻底修复。
如果是代码bug，改代码、测试、上线
如果是配置错误，修正配置、验证
如果是容量不足，扩容、调整阈值
如果是依赖故障，联系依赖方、切备用通道
这一阶段的目标是：让系统回到正常状态，且不会再因为同样原因出问题。
第五阶段：复盘
这是最容易被跳过的阶段，也是最重要的。
写复盘报告：故障时间、影响范围、根因、处理过程、改进措施
开复盘会：不追责，只找改进点
跟改进措施：哪些要改代码？哪些要加监控？哪些要优化流程？
这一阶段的目标是：不让同一个坑踩两次。
03 角色分工：谁在什么时候做什么
事件响应最怕的是：一群人围着屏幕，都在看，没人指挥。
一个标准的响应小组应该有这几个角色：
事故指挥官：负责总体协调，决定什么时候切流量、什么时候回滚、什么时候对外通报。不需要懂技术细节，但要能拍板。
技术负责人：负责查根因、出修复方案。通常是熟悉该系统的资深工程师。
沟通负责人：负责对内对外沟通。给老板汇报、给客户发通知、给客服同步话术。让技术专心修故障，别被“好了没”的问题打断。
小团队可能一个人兼多个角色，但职责要分清楚。最怕的是“大家都在查，没人管用户”。
04 云上常见故障及处置预案
不同的故障类型，处置方式不同。提前准备好预案，出事时按流程走，比现场想快得多。
场景一：应用响应慢或超时
先看监控：CPU高？内存高？IO高？
快速止血：重启实例、扩容节点、切流量
根因排查：慢SQL、死锁、依赖超时、代码bug
场景二：数据库连接池爆满
快速止血：重启应用、临时扩大连接池
根因排查：连接未释放、慢查询堆积、突发流量
场景三：数据误删
快速止血：停写操作、从备份恢复
根因排查：谁删的？为什么有权限？为什么没备份？
场景四：权限失控
快速止血：禁用问题账号、收紧权限
根因排查：IAM配置错误、密钥泄露、离职账号未清理
场景五：云服务商区域故障
快速止血：切流量到其他可用区或区域
根因排查：云厂商故障公告、等待恢复
05 工具链：云上快速止血的武器
云厂商提供了很多“快速止血”的工具，关键是平时要配好。
负载均衡：可以一键摘掉不健康的节点
弹性伸缩：可以快速扩容新实例
快照和备份：可以快速回滚数据
基础设施即代码：可以快速重建环境
流量管理：可以切流、限流、降级
这些工具不只是在架构设计时考虑，还要在应急演练时验证。确保关键时候能点得动、跑得通。
06 一个真实案例：从手忙脚乱到从容应对
去年帮一个电商客户做应急响应体系。他们之前出过两次大故障：一次是数据库被误删，恢复花了8小时；一次是促销期间流量暴涨，扩容没跟上，系统雪崩。
我们帮他们做了三件事：
第一，明确角色分工。指定了事故指挥官、技术负责人、沟通负责人。贴墙上，大家都认识。
第二，整理故障预案。把常见故障场景的处置步骤写清楚，包括：怎么判断、怎么止血、谁负责、工具在哪。
第三，定期演练。每季度选一个周末，模拟一次故障，按真实流程走一遍。第一次演练，从发现到恢复用了2小时。第三次演练，只用了25分钟。
上个月他们又遇到一次数据库连接池爆满。从告警到恢复，只用了15分钟。技术负责人说：“以前出事手忙脚乱，现在知道第一步做什么、第二步做什么，心里不慌了。”
写在最后
事件响应这件事，说复杂也复杂，说简单也简单。复杂在技术细节多、依赖链条长，简单在核心只有一条：出事时，有人知道该做什么，有人知道该找谁，有人知道怎么止血。
与其等到出事再手忙脚乱，不如今天就开始准备。写一份应急预案，哪怕只有一页纸。指定谁是指挥官、谁是技术负责人。每季度跑一次演练，哪怕只跑30分钟。
那位客户后来跟我说了一句话，我记了很久：“以前觉得应急响应是‘万一出事怎么办’，现在觉得是‘出了事也不怕’。”
你的团队，现在属于哪一种？
