陌生环境的故障为什么不一样
自己团队的服务出故障，身体知道往哪看：仪表盘地址、日志位置、最近的部署记录都在脑子里。客户现场的故障，是在这些前提全部消失的状态下开始的。监控是什么、日志堆在哪、昨天改了什么，一概不知——而客户就在旁边问什么时候能修好。
这种条件下需要的不是过人的直觉，而是固定的顺序。本文就是把这套顺序写成六步的手册。全文只用一个案例贯穿：下午起支付 API 间歇性返回 504 的报告——不是真实事件，而是为本文构造的示例；出现的命令只用 kubectl、curl、grep 这类公开的通用工具。
第 1 步 — 确认访问与权限
本能说先开日志，但在陌生环境里，第一步是确认访问。能通过什么路径进入哪些环境？手里的权限是只读还是可写？这是生产还是预发？理由有二。其一，诊断进行到一半才发现缺权限，申请加审批的整段时间就全浪费了。其二，越权操作本身就是事故。在客户的生产环境里敲下一条越权命令，损失的信任比故障本身更大。
要确认的清单很短：访问通道是否通畅；这个账号的权限边界在哪里；只读能否完成诊断；需要写权限时找谁审批。把这四行写在故障工单最顶端，然后再开始。
第 2 步 — 复现症状
「有时候很慢」没法诊断，能诊断的只有测量值。所以第二步是把上报的症状固定成一条命令。
# 把症状固定成一条命令（构造的示例）
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" \
https://api.customer.example/v1/payments/health
# 重复 20 次，测出失败率
for i in $(seq 1 20); do
curl -s -o /dev/null -w "%{http_code}\n" https://api.customer.example/v1/payments/health
done | sort | uniq -c
如果 20 次里有 3 次是 504，故障就从传闻变成了数字。复现不出来也是信息：说明问题只发生在特定用户、特定时段或特定路径上，问题随之收窄。这条复现命令在后面的每一步都会被复用，作为判定「修没修好」的标尺。
第 3 步 — 切分层级
找原因之前，先找到原因住的街区。对网络、认证、应用、数据四层各问一个问题：DNS 和 TLS 正常吗？错误里混着 401 或 403 吗？Pod 是否存活且没有重启？数据层的延迟是否在向应用层传导？
# 每层只问一个问题（构造的示例）
kubectl -n payments get pods -o wide # 应用层：状态与重启次数
kubectl -n payments describe deploy/api | grep -A3 Limits # 资源上限
kubectl -n payments get endpoints api # Service 与 Pod 的连线
kubectl -n payments logs deploy/api --since=30m | grep -ciE "timeout|refused|pool"
在构造的示例里，Pod 没有重启，没有 401，日志里聚集着超时一族的字符串。于是网络层和认证层退出嫌疑名单，范围收窄到应用与数据之间的某处。切分层级的目的不是猜中答案，而是确定哪些地方从此不必再看。
第 4 步 — 建立原因假设
从这里开始，你要对抗的是乱翻日志的诱惑。陌生环境的日志是海，不带假设进去只会消耗时间。在剩下的嫌疑区里，把假设明确写成两三条。构造的示例是这样：第一，数据库连接池耗尽——与日志里的 pool 字符串和间歇性吻合；第二，某条查询变慢——数据量增长可能翻转了执行计划；第三，下午的部署或配置变更——需要核对时间是否重合。
好假设的条件只有一个：看到什么就能推翻它，必须一目了然。想不出反证方法的假设不是诊断，是猜测。假设清单原样写进工单——之后它会变成报告的一半。
第 5 步 — 验证假设
对每条假设，只去取足以推翻或确证它的最少证据。
# 假设 1：连接池耗尽 — 发生频率与时间分布（构造的示例）
kubectl -n payments logs deploy/api --since=2h \
| grep -c "connection pool exhausted"
kubectl -n payments logs deploy/api --since=2h \
| grep "connection pool exhausted" | cut -c1-16 | sort | uniq -c
# 若只聚集在 14:05 之后 → 向客户询问那个时刻的变更记录
构造示例的结局是：错误只出现在 14 点 05 分之后；一问客户，那个时刻有一次配置部署；部署的 diff 里连接池被调小了。回滚配置后，重跑第 2 步的复现命令，确认 20 次 0 失败。验证的关键在两个方向：确证原因的证据，以及修复后用同一把标尺重测得到的正常值。没有后者，就不能说修好了。
第 6 步 — 写报告
FDE 的故障响应不是终结在系统里，而是终结在报告里。技术上修得再完美，报告迟到或含糊，客户记忆里留下的只有不安。第一段写影响和当前状态，原因分析放在后面。
[故障报告 — 构造的示例]
影响 ：支付 API 5xx 比率 平时 0.1% → 峰值 7%（14:10–15:40）
当前状态：缓解措施已生效，错误率确认回到平时区间
初步原因：14:05 的配置部署将数据库连接池调小
下一步 ：已回滚。拟提议在部署前增加配置 diff 检查环节以防复发
不点名的原则在客户现场尤其重要。写下「客户方管理员改错了配置」的那一刻，下次故障时那位管理员就会隐瞒信息。只写系统是如何失败的。无责报告不是礼貌，而是为下一次诊断的速度所做的投资。
亲手练习
这套手册，亲身经历比阅读快一百倍。
- FDE 工程师养成 RPG — 「太慢了」「连不上」「监控先挂了」这些 31 个任务全是这六步的变奏。在时间与信任不断流失的压力下，练习守住顺序。
- FDE 课程路线图 — 用清单核对切分层级所依赖的各领域技能。
FDE 完全指南系列
현재 단락 (1/38)
自己团队的服务出故障，身体知道往哪看：仪表盘地址、日志位置、最近的部署记录都在脑子里。客户现场的故障，是在这些前提全部消失的状态下开始的。监控是什么、日志堆在哪、昨天改了什么，一概不知——而客户就在旁...