一、先定边界，比先动手重要
1、一台还是一批
同时挂掉的实例如果集中在同一宿主机、同一可用区、同一批次，方向完全不同。先看范围，再谈原因。
2、机器挂了还是服务不正常
控制台能登上、ping 能通、端口不通，说明机器活着，是服务层的问题。反过来，控制台登不上、ping 不通，才是实例层面的问题。
3、外部不通还是内部异常
从外网访问失败，可能是安全组、负载均衡、DNS，也可能是应用自己。别一上来就把问题归到 “云服务器坏了”。
4、几个快速判断动作
看监控曲线有没有断点、看同类实例是否正常、看近期有没有变更、看云侧有没有事件公告。这四条能在几分钟内把范围缩小一大半。
二、保住现场，再动手
1、能连就先取证
负载、内存、磁盘、进程、最近的系统日志、内核日志，能导的都导出来。故障发生时的现场，是唯一一份。
2、不要条件反射地重启
业务优先的场景可以重启止损，但要知道代价：内存里的状态、崩溃瞬间的调用栈、内核日志，全都没了。
3、记下时间点
故障开始时间、发现时间、第一次动作时间。事后复盘时，这三个时间点比任何描述都有用。
三、按层往下查
1、平台层
云侧是否有故障公告、实例是否被迁移、账号是否欠费、配额是否触顶、是否触发了资源限制。这一层最容易被忽略，因为它 “不归你管”。
2、系统层
内存耗尽被 OOM 杀掉、磁盘写满、inode 用尽、文件系统变只读、内核崩溃、时钟漂移。这几项在日志里都有明确痕迹。
3、网络层
安全组和防火墙规则变更、路由异常、DNS 解析失败、带宽打满、连接数耗尽、丢包。表现为 “能连但很慢” 或 “时通时不通” 的，多半在这一层。
4、应用层
进程退出、端口被占、依赖服务超时、配置改错、证书过期、连接池耗尽。发布后立刻出问题的，优先怀疑这一层。
5、依赖层
数据库、缓存、对象存储、消息队列、第三方接口。这类故障的特点是 “本机一切正常，但请求全部超时”。
四、恢复：两种优先级，两条路
1、业务优先
目标是尽快恢复可用。动作包括切流到健康实例、扩容顶上去、回滚上一次变更、从镜像快速重建。这时候不追根因，先止血。
2、根因优先
目标是查清为什么会挂。前提是能接受更长停机，且现场已保全。这条路适合非核心业务和可复现的问题。
3、恢复要有顺序
先恢复入口、再恢复核心链路、最后补次要功能。别一上来就把所有服务一起拉，容易互相拖死。
4、重建往往比修复快
云上的机器是 “可抛弃” 的。配置即代码、镜像化部署的环境里，重建一台比在故障机上折腾更省时间。
五、让它下次更快：几件提前做的事
1、告警分层
可用性告警（打不开）、资源告警（快满了）、业务指标告警（下单掉了）。三层分开，值班的人才知道先看哪个。
2、值班手册
第一动作清单：确认范围、拉监控、查变更、通知相关方。写成一页纸，比临时凭记忆靠谱。
3、把回滚当能力建设
多数线上故障和变更有关。回滚快，比排查快更有价值。发布流程里应该包含 “怎么退”。
4、定期演练
拿非核心业务做故障注入，演练切换、重建、恢复。真出事的时候，肌肉记忆比文档管用。
