香港服务器上线前，最容易被忽略的故障征兆往往不是“机器已经宕机”，而是域名偶尔无法访问、接口响应忽快忽慢、磁盘持续增长，或者备份任务显示成功却无人确认能否恢复。上线检查不能只看服务器是否开机，应把检查对象限定到即将对外提供的域名、入口、应用和数据链路，并记录检查时间、访问来源及预期结果。否则，一次本机访问成功，不能证明外部用户也能正常使用。

建议按风险由低到高推进：先从服务器外部验证访问，再核对主机与应用的监控、告警；随后确认备份及隔离恢复能力，检查业务峰值下的容量余量；最后才执行发布或配置变更。每一步都要留下“正常意味着什么、异常应暂停什么、修复后怎样复测”的记录。只要关键检查尚无结果，就不要把“暂时没报错”当作上线条件。

先确认外部能否到达业务入口

第一步不要登录服务器改配置，而是使用不在该服务器上的测试环境，访问实际上线域名和一个已约定的只读检查地址。测试环境应能代表目标用户的访问方式；如果业务有不同入口，应分别检查，不能用其中一个入口的结果替代全部入口。

以下示例在安装了 curl 的测试机上运行。执行前将地址替换为真实域名和实际存在的检查路径；该路径不应触发写入、发送消息等业务动作。超时时间是检查示例，可按业务要求调整。

curl --silent --show-error --output /dev/null \
  --write-out 'HTTP=%{http_code} DNS=%{time_namelookup} TCP=%{time_connect} TLS=%{time_appconnect} FIRST_BYTE=%{time_starttransfer} TOTAL=%{time_total}\n' \
  --max-time 10 'https://your-domain.example/health'

预期结果是命令正常结束，返回约定的成功状态码，且各阶段耗时与此前同类测试相近。不能只凭总耗时判断问题位置：

• 域名解析失败或返回的目标与上线配置不符：先核对域名记录及生效情况，不要直接修改服务器内的应用。
• TCP 连接失败：检查入口地址、监听状态及访问控制；这只能说明连接未建立，不能直接认定应用故障。
• TLS 校验失败：核对证书覆盖的域名、有效期和入口配置。不要用跳过证书校验的测试结果宣布上线通过。
• 已建立连接但返回异常状态码，或首字节等待明显变长：沿入口向应用及其依赖排查，并结合相同时间段的日志定位。
• 检查地址成功、真实业务操作失败：说明基础入口可达，不代表登录、查询等业务链路正常，还需使用预先准备的测试账号完成授权范围内的只读验证。

同一检查应在预计使用的访问来源重复进行，并保存时间、状态码和失败现象。修复后重跑原命令及受影响的业务操作；只有原故障可复测消失，才能关闭该项异常。

核对监控：不仅要有数据，还要能发现故障

外部访问正常后，再检查香港服务器内部。监控至少应覆盖四类信号：外部可用性、应用错误与响应、主机资源、备份与任务状态。采集项是否足够，要由业务依赖决定：例如应用依赖数据库，就不能只监控网页入口而完全看不到数据库连接失败。

上线前逐项核对：

1. 数据是否连续、时间是否一致。 打开监控图表，确认指标持续更新，服务器、应用日志和监控平台的时间可对应。图表长期空白或采集延迟时，“没有告警”不等于正常。
2. 告警是否能送达值班人员。 确认接收人、通知渠道和失联后的升级方式。使用平台提供的测试告警功能，验证触发、送达、确认的完整过程；测试结束后关闭测试状态，避免持续误报。
3. 告警条件是否对应可处理的风险。 外部探测连续失败、错误率上升、资源余量持续下降、备份失败，应有明确负责人。阈值应结合业务峰值、历史基线和允许的恢复时间设定，不能仅复制一组通用数值。
4. 日志能否支持定位。 抽查一次测试请求，确认能按时间和请求标识关联入口与应用日志，同时避免在日志和告警消息中暴露密码、令牌等敏感内容。

如果外部探测报错而主机指标正常，应优先检查域名、入口及应用返回；如果主机指标异常而外部请求暂时成功，也不能忽略，因为余量耗尽可能发生在上线后的流量增长阶段。修复采集或告警规则后，应重新触发一次受控测试，确认图表恢复更新、告警正确送达，且测试结束后能够恢复。

备份要以“能恢复”为验收标准

备份任务显示“完成”，只能说明任务报告了结果，不能证明数据完整，也不能证明恢复时间符合业务要求。上线前先列清恢复范围：数据库、用户上传文件、必要配置及部署所需信息是否都已覆盖；密钥等敏感材料应通过受控方式保管，不应为了方便恢复而散落在明文备份中。

对每项关键数据，确认最近一次可用备份的完成时间、存放位置、保留方式和失败通知。若备份与生产数据位于同一故障域，或只能依赖同一套容易同时失效的权限访问，应评估故障时是否仍能取回。数据库还需核对备份方式是否能获得一致的数据状态；仅复制正在写入的数据文件，不能未经验证就视为可恢复备份。

更重要的是做一次隔离恢复验证：在不会覆盖生产数据的环境中，按实际流程取回备份，恢复应用所需的数据和配置，检查关键记录、文件引用及应用版本兼容性。测试环境应隔离对外发送、支付等副作用，避免恢复后的任务误触发真实业务。记录最近可恢复到的时间点和实际恢复耗时，再与业务允许的数据丢失范围、恢复时间比较。

若备份无法读取、缺少关键文件、恢复后应用无法使用，或恢复耗时超出业务可接受范围，应先修复备份链路并重新演练。不要通过覆盖生产数据来“试一下能否恢复”。修复后的通过标准，是重新生成或取得一份备份，在隔离环境完整恢复，并留下可复核的验证记录。

用峰值和增长趋势检查容量

容量检查不是看某一刻 CPU、内存、磁盘“还没满”。应对照预计上线流量、已观察到的业务峰值，以及数据增长趋势，判断资源是否能覆盖下一次可预见的高峰；缺少历史数据时，应明确这是未验证项，采用受控的小范围放量观察，不能凭空推断余量。

在已确认运行 Linux、且有相应只读查看权限的香港服务器上，可先运行以下命令。它们用于发现线索，不会自行给出业务容量结论；若某命令未安装，使用系统或监控平台已有的等效指标核验。

uptime
nproc
free -h
df -hP
df -iP
ss -s

查看结果时重点区分：

• uptime 的负载持续走高，应结合 nproc 显示的处理器数量、CPU 使用情况和业务延迟判断；单次负载值不能单独证明 CPU 已成为瓶颈。
• free -h 不能只看“空闲”一列。若可用内存持续减少，并伴随内存不足记录或应用进程退出，应先定位占用来源，而非直接重启掩盖问题。
• df -hP 显示文件系统空间，df -iP 显示 inode 使用情况。检查时要找到数据库、日志、上传目录实际所在的挂载点；根目录有空间，不代表数据盘也有空间。
• ss -s 可辅助观察连接状态变化，但连接数增加本身不等于故障。应结合入口报错、应用连接池和系统限制，判断是否出现连接耗尽。

还应通过监控核对磁盘读写等待、网络流量和应用连接池等指标，重点看高峰时是否同时出现排队、超时或错误。若已有指标显示容量接近已验证的承载边界，应先处理增长原因、调整资源或控制放量，再复测。清理数据、修改限制或扩容都可能影响业务；执行前要确认备份、影响范围和回退方式，不能把有风险的改动当成检查动作。

变更前设定停止条件和回滚路径

监控、备份、容量均通过后，才进入发布变更。记录本次要改的应用版本、配置和数据库结构，明确执行人、观察人、影响入口以及出现什么现象就停止放量。发布前保留当前可用版本和配置，并核对回滚所需权限、文件及操作步骤确实可用。

特别注意数据库结构与应用版本的兼容性：回退应用代码，不一定能回退已经执行的数据变更。若变更会删除或覆盖数据，应先确认备份与恢复演练结果，单独评估停机窗口和恢复路径；无法安全回滚时，不应把“重新部署旧版本”写成完整预案。

发布后不要只检查进程是否运行。先用与上线前相同的外部测试入口复测，再完成关键业务只读操作，并比较错误、延迟、资源和日志。若达到预设停止条件，暂停后续放量，按事先确认的方案回滚或恢复；回滚后同样需要重复外部访问、业务操作及数据一致性检查。

最终验收应能回答三个问题：用户入口是否持续可用，故障能否被及时发现，数据能否在业务允许的范围内恢复。上线后的首个实际业务高峰还需持续观察这些指标；高峰结果与上线前判断不一致时，及时调整告警和容量预案，而不是等故障发生后再补检查。