排障的核心不是记住更多命令，而是知道每个命令回答了哪个问题。 当一个问题同时出现 DNS、证书、网关和后端报错时，真正的第一步通常是： 确认故障发生的准确时间与准确层级。
01 · EVIDENCE CHAIN
先把日志读成时间线，而不是一行行猜测
打开日志后，先找四个要素：时间、请求标识、组件和错误。很多看似不同的错误， 其实是同一个上游失败造成的连锁反应。例如后端连接超时会导致网关返回 502， 浏览器再把它表现为“页面无法访问”。
时间：用户反馈、浏览器、网关与应用日志是否落在同一时间窗口？
请求标识：是否能通过 Request ID 串起网关和后端日志？
首个异常：忽略后续级联错误，先找时间线上第一次偏离正常状态的记录。
变化：故障前是否发布了新版本、修改了证书、配置、网络或数据？
保留原始错误文本和时间戳。不要只截取“看起来像原因”的半句话，也不要覆盖故障现场。
02 · REQUEST PATH
沿着请求路径排障：每一层只验证一个事实
一个 HTTPS 请求通常要经过域名解析、网络连接、TLS 握手、反向代理、应用处理， 最后才访问数据库或外部服务。按顺序验证，可以避免在错误的层级浪费时间。
域名是否解析到正确地址？
证书、域名与握手是否匹配？
Nginx 是否命中正确站点与上游？
应用是否能收到请求并完成处理？
一个高效的记录格式
每次只记录三项：执行了什么命令、看到了什么原始输出、 由此排除了哪一层。这样即使换人接手，也能沿着证据继续排查。
| 现象 | 优先检查 | 不要急着做 |
|---|---|---|
| 域名完全无法解析 | 权威 DNS、A/AAAA 记录、TTL | 重启应用或重建数据库 |
| HTTPS 证书告警 | SNI、证书域名、完整证书链、有效期 | 关闭证书校验后上线 |
| Nginx 返回 502 | 上游地址、端口、健康状态、错误日志 | 反复 reload 但不查看 upstream 错误 |
| 接口偶发失败 | 同一 Request ID、耗时、线程池与依赖延迟 | 只凭单次成功结果下结论 |
03 · READ-ONLY DIAGNOSIS
诊断阶段优先使用只读命令
只读检查能快速建立事实，同时避免二次破坏。下面的命令只展示常用检查顺序， 实际执行前仍需确认主机、域名和输出中不包含凭据或个人敏感信息。
# 1. 域名解析
dig +short example.com A
# 2. TLS 与响应头
curl -vkI --max-time 10 https://example.com/
# 3. Nginx 配置与最近错误
sudo nginx -t
sudo tail -n 100 /var/log/nginx/error.log
# 4. 容器服务状态与日志
docker compose ps
docker compose logs --tail=100 service-name
注意命令的“边界”：nginx -t 只验证配置语法，不代表域名解析或上游服务正常；
docker compose ps 显示容器运行，也不代表应用已经完成初始化。
分享日志或远程提交问题前，先移除密钥、Token、Cookie、手机号、邮箱、内网凭据和用户内容。
04 · SAFE CHANGE
修复时，让每一次改动都可解释、可回滚
排障进入修复阶段后，最大的风险往往不是技术难度，而是一次同时修改多个变量。 正确的顺序是：先明确假设，再选择最小改动，验证结果，最后记录是否能解释原始证据。
- 写清假设：“我认为问题出在证书链不完整，因为客户端在握手阶段失败，而 HTTP 层尚未收到请求。”
- 备份现状：保存配置、版本、数据和当前日志；明确回滚路径。
- 只改一个变量：先修复最上游、最接近首个异常的那一层。
- 验证原始场景：使用与用户相同的域名、路径和请求方式复测，而不是只测内网端口。
- 记录结论：如果问题再次出现，下一位值班者应该从哪里开始？
数据库、密钥、账户权限和人工配置不可随意覆盖。变更前备份，变更后校验，并确认旧数据仍可恢复。
05 · REVIEW
复盘不是写经过，而是让下一次更快
一份有价值的复盘至少要回答：故障影响是什么、首个异常在哪里、为什么没有更早发现、 哪个改动让系统恢复，以及如何验证同类问题不会再次发生。
是否能从外部复现？记录域名、URL、时间范围和请求方式。
是否有关键日志？保留失败与成功各一份，便于对比。
是否有自动检查？把配置语法、证书有效期、服务健康加入巡检。
是否能安全回滚？确认备份可读、审批明确、回滚步骤经过验证。
从概率预测、上下文到检索增强，建立一套能解释、能验证的 AI 使用框架。