先给结论
排查顺序是：先把现象和影响范围确认清楚，能快速恢复的先恢复（止血），再按网络与解析、服务器资源、服务与证书、应用代码、数据的顺序分层定位，用监控与日志交叉验证，最后记录时间线并复盘。
排查六步流程
- 确认现象：谁报告的、能否复现、从什么时候开始，别基于传言下结论。
- 评估影响：是全站不可用、部分功能异常，还是个别页面问题；影响哪些用户与业务。
- 先止血：如果故障前刚做过发布或配置变更，优先回滚这次变更，恢复优先于定位。
- 分层定位：按外到内的顺序排查，缩小范围后再深入。
- 交叉验证：监控曲线、错误日志、访问日志三方对照，确认定位是否成立。
- 记录与复盘：恢复后整理时间线、根因与改进项，补上缺失的监控或流程。
分层定位的顺序
| 层级 | 排查问题 | 典型线索 |
|---|---|---|
| 网络与解析 | 域名解析是否正常、能否连通 | 解析记录异常、访问超时 |
| 服务器资源 | CPU、内存、磁盘是否异常 | 磁盘占满、进程崩溃 |
| 服务与证书 | Web 服务是否运行、证书是否有效 | 服务未启动、证书过期 |
| 应用代码 | 最近的变更是否引入错误 | 错误日志中的报错与堆栈 |
| 数据层 | 数据是否损坏或被锁 | 查询超时、写入失败 |
几条现场纪律
- 故障中不做高风险大改动，比如大规模重构或随意升级组件；
- 明确一名指挥者，避免多人同时操作互相覆盖；
- 每一步操作都留记录，方便回退与事后复盘；
- 恢复后先观察一段时间，确认稳定再收尾。
建立这样的排查流程，也是运维托管服务的价值所在。
常见问题
网站打不开，第一步做什么？
先确认是所有人都打不开还是个别人的问题，再看是全站还是单页。能复现就立刻检查最近是否有发布或配置变更，多数故障与最近一次变更有关。
为什么应该先恢复再找原因？
业务中断的时间越长损失越大。先用回滚等手段恢复，再从容定位根因，比在故障现场边查边改更安全，也避免了在压力下引入新问题。
故障恢复后还需要做什么？
要做复盘：还原时间线、找到根因、列出改进项并落实，比如补监控、改流程、加备份。不复盘的故障往往会以同样的方式再发生一次。
小问题要不要也走这套流程？
影响面小的可以简化，但确认现象、记录处理过程这两步不应省略。积累的记录会成为判断趋势和定位复发问题的依据。