远程服务器故障排查指南

当生产服务器出问题，你需要的是分钟级的诊断，不是几小时。OpenCode 能读相关日志、交叉对照近期变更，并在你保持对服务器控制权的同时给出修复建议。

何时使用此案例

准确描述症状

用一段话讲清楚：什么坏了、什么时候开始的、你已排除的可能。

今日 14:00 UTC 起，结账服务大约 3% 的请求返回 504。p99 延迟从 800ms 涨到 6s。过去 6 小时没有部署。应用节点 CPU 和内存正常。我还没重启过任何东西。
拉取相关日志

让 OpenCode 拉取合适时间段的日志并暴露异常。

SSH 到 prod-app 集群（凭据在 1Password）。拉取结账服务最近 2 小时的 stdout 和 stderr。暴露错误模式、堆栈跟踪、异常的延迟尖刺。不要包含正常流量。
与近期变更做关联

即使没有部署，基础设施变更依然可能相关。

检查过去 24 小时的基础设施变更（Terraform、ingress、DNS）。把每项变更与延迟上升的时间点做交叉对照。
形成假设

让 OpenCode 给出最可能的根因和验证方法。

基于日志和基础设施变更，给我一个排名前 3 的延迟上升假设列表。每个给出支持证据和一个可执行/排除的命令。

在不打挂的前提下验证

始终先走影响最小的验证路径。绝不直接跳到重启。

# 示例：检查下游是否超时
curl -w '%{time_total}\n' -o /dev/null -s https://internal.api/ping

执行最小、安全的修复

验证后，做能解决问题的最小改动。如果修复有风险，先和同事确认。

假设假设 #2 已确认，请提出最小、最安全的改动。给我精确的命令、接下来 10 分钟要监控什么、回滚方案。
写一份事后记录

即使是小事，也要把发生了什么、为什么、该改什么记下来。

写一份 1 页的事后记录到 incidents/2026-06-27-checkout-504.md，包含：时间线、根因、缓解措施、一条预防措施（告警、runbook、测试或重构）。

用 [vault path] 里的凭据 SSH 到 [host]。拉取 [service] 最近 [N hours] 的日志并暴露错误模式、堆栈跟踪、延迟异常。再检查同窗口的基础设施变更。给出 [symptom] 排名前 3 的假设——每个给出支持证据和一个验证命令。不要执行任何破坏性操作。