定义一个可观察的故障
“停止”可能意味着 HTTP 错误、超时、未完成的任务或已退出的进程。写下一个 URL 或操作、其最后已知正常时间、首次故障时间和您的时区。包括是所有人都受影响还是只有一个客户端。调查期间保持当前的 SSH 会话打开；更改访问规则不是应对应用程序错误的必要第一反应。
本指南假设使用 systemd 的 Linux 主机、名为 first-api.service的应用程序服务，以及位于 127.0.0.1:3000/healthz的本地健康端点。这些默认值与第一个 API 部署指南匹配。请替换为您的实际名称。检查其他用户的进程或日志可能需要管理员权限。以下命令和输出仅为示例；本指南未测试任何提供商实例。
将笔记保存在故障应用自身目录之外。先记录观察，再记录解释：“09:18 UTC 连接被拒绝”是事实；“VPS 需要更多 CPU”仍是假设。如果服务器本身不可达，请使用您既定的恢复访问方式并收集连接详情，而不是假设可以重启应用。
读取进程状态及其近期历史
systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts状态视图描述当前或最近一次调用，并包含最近的日志消息。所选属性为您提供了一份简洁的记录，以便日后比较。失败状态或持续增加的重新启动次数值得调查；处于活动状态的进程仍需要一次请求测试。这些是不同的检查，如以下所述： 上游 systemctl 参考.
如果缺少该单元，首先核实其名称和部署方式。在交互式终端中启动的应用、容器和 systemd 服务具有不同的所有者和日志。立即创建新服务可能会导致两个副本争用同一端口。在更改之前，先确定现有的安排。
检查监听器并进行本地请求
sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz查找预期的地址和端口，然后确定拥有该进程。监听另一个端口的进程可能健康，但配置的代理无法访问。另一个进程可能已占用预期端口。 ss 手册 定义了监听器和进程选项。
如果本地请求成功而公共 HTTPS 请求失败，请继续检查 DNS、TLS 和代理检查。如果监听器不存在，请检查启动失败。如果连接成功但应用返回错误，请调查该路由及其依赖项。不带 --fail 的 Curl 可以成功完成 HTTP 错误响应，因此请阅读响应，而不是仅依赖其退出代码。参见 curl 的响应和失败选项.
阅读首次故障前后的内容，而不仅仅是最后一行
sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100第一个查询选择服务；第二个选择内核消息。调整时间范围，使其包含最后一次正常工作的请求以及中断之前发生的变更。访问和保留策略决定了哪些内容仍可用。 上游 journalctl 参考 解释了单元、时间和内核筛选器。在分享摘录之前，请脱敏令牌、客户数据和连接字符串。
来自另一个具有上传功能的应用的示例摘录（仅作说明）：
09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted这表明服务用户对特定路径的访问存在问题。根据发布说明检查文件和父目录的所有权。不要授予对整个文件系统的广泛写入权限。后续代理的“上游不可用”消息在此场景中是结果，因此先修复代理会错过根本原因。
将资源与最近的发布进行比较
free -h
df -h / /opt/first-api
df -i / /opt/first-api这些快照可帮助您判断内存压力、文件系统空间或 inode 耗尽是否与故障同时发生。它们的解读属于 内存和磁盘指南；单次繁忙读数并不能确定原因。服务也可能在主机其余部分仍有容量时触及自身资源限制。
将已部署的发布标识符、启动命令、所需环境变量名称和数据路径与上次正常工作的发布进行比较。不要将机密环境值转储到报告中。查找重命名的目录、缺失的运行时依赖项、端口更改或不兼容的数据库迁移。说明发生了什么变更，以及错误预示您应该发现什么。
进行一项有依据的纠正并验证恢复
选择有证据支持的最小修正。对于说明性的权限失败，这意味着恢复服务账户的预期访问权限，然后进行一次受控的启动尝试。如果您改用已知可用的代码版本，请先确定其数据库架构是否仍然兼容。代码回滚无法自动撤销数据迁移。
修正后，重复相同的服务、本地端点和公共请求检查。确认有代表性的应用操作正常工作，新错误已停止，并且进程在接下来的正常工作负载中保持稳定。重启策略可以帮助恢复进程，但无法让持续损坏的程序变得健康；请查阅 systemd 服务参考 以了解实际策略。
在事件记录中写明症状、第一条有用线索、所做的更改和验证结果。如果原因仍不确定，请用脱敏证据报告该不确定性，而不是将临时重启标记为永久修复。改进 发布检查清单 ，加入本应更早发现此故障的检查项。
使用的文档
本页的主要参考资料。检查您自己环境中安装版本的文档。