Compute Engine 故障排查与应急复盘：按证据链推进的处置手册

故障现场最稀缺的资源不是工具，而是判断力。人在压力下容易急着动手：先重启、先放开端口、先扩容，结果配置改了一堆，问题依旧存在，还丢掉了关键证据。更稳的做法是先把现象分清楚，再从可控的证据源获取信息，让每一步操作都能产生新的线索。这份手册按这个思路组织。

一、故障分级：先决定投入多少资源

接到告警的第一分钟，先判断影响范围：是单个实例、单个服务，还是整个区域或全部用户受影响。影响范围决定了响应等级与投入资源。把全站不可用当成单机问题处理，会延误通知与升级；把单机异常按最高等级响应，则会浪费注意力和人力。

分级标准应当提前写清楚，例如核心业务完全不可用为最高级，部分用户受到影响为中级，单个非核心实例异常为低级。分级之后还要明确对应的动作：谁负责指挥、多久同步一次进展、何时通知业务方。事前定义好规则，事发时就不需要讨论流程。

二、固定证据来源：日志、监控与串口输出

排查应当优先使用只读手段获取信息。日志记录应用与系统的运行轨迹，监控提供指标随时间的变化，串口输出在实例无法正常启动或无法通过网络访问时尤为关键。这三类信息组合起来，通常足以判断故障发生在哪一层。

要在平时就确认这些证据是可获取的：日志是否上报到集中平台、监控指标是否包含实例级与系统级数据、串口日志是否已经配置。等到故障发生时才申请权限或开启采集，往往会错过最关键的窗口期。

三、无法登录的五种可能与排查顺序

第一种是网络路径问题：管理端口未放行或来源范围不匹配。第二种是系统尚未完成启动或启动过程卡住，需要通过串口输出确认。第三种是凭证问题：密钥未正确绑定或权限设置导致无法登录。第四种是系统内部限制：本地防火墙或访问控制阻止了连接。第五种是实例本身异常，例如状态不是运行中。

排查顺序建议由外向内：先确认实例状态与网络规则，再看串口是否有启动错误，最后确认凭证与系统内配置。逐层排除的好处是每一步都有明确结论，不会在多个假设之间反复跳跃。

四、服务不可达：从监听地址到负载均衡

服务器能登录但服务访问不了，通常是四类问题之一：应用未监听预期端口、应用监听在仅本机可访问的地址上、系统或网络层限制未放行、以及负载均衡健康检查未通过导致实例被摘除。排查时按这个顺序逐项确认。

健康检查相关的问题尤其容易被忽略。检查路径、返回码要求、超时时间和检查间隔中任何一项配置不当，都可能让健康的实例被判为异常。建议在变更健康检查配置后，观察一段时间后端状态再结束变更。

五、磁盘与文件系统异常的处理

磁盘相关故障的典型表现包括：写入失败、系统响应变慢、无法挂载数据盘、以及重启后无法进入系统。排查时先确认磁盘的挂载状态与剩余空间，再查看系统日志中的磁盘错误信息。磁盘空间被日志占满是最常见的原因之一。

处理时要区分临时缓解与根治：清理日志或临时文件可以让服务先恢复，但如果没有调整日志轮转策略或扩容容量，问题很快会再次出现。对于疑似硬件层面的异常，应当优先保护数据，通过快照或备份再进行处理，而不是直接尝试修复。

六、性能骤降的定位方法

性能下降的原因可能来自计算、内存、磁盘、网络或应用本身。定位方法是观察同一时间段内各层指标的变化：如果 CPU 与内存正常但磁盘队列长期堆积，瓶颈可能在存储；如果实例指标正常但请求延迟上升，需要检查网络路径与依赖服务。

还要注意流量的形态变化，例如某个来源的请求量突然放大、某个接口被频繁调用、或者某个定时任务与业务高峰重叠。找到变化点之后，处理方式可能是调整资源配置，也可能是限流或优化查询，具体取决于根因。

七、配额与接口限制导致的异常

有些“故障”实际上是配额或接口限制触发的：无法创建新实例、扩缩容失败、负载均衡配置不生效、接口返回限流错误。这类问题的特点是错误信息往往明确，但排查时容易被忽略，因为大家习惯从系统和应用层找原因。

应对方式是提前梳理关键资源的配额，并把配额监控纳入日常巡检。对于存在明显高峰的业务，应当在业务活动前主动申请调整配额，而不是等到扩容失败时再补救。

八、复盘模板与改进项跟踪

复盘的目的不是追责，而是找出系统性缺陷。一份实用的复盘记录包含六项内容：故障现象与影响范围、时间线（发现、响应、缓解、恢复）、直接原因、根本原因、缓解与修复动作、以及需要跟踪的改进项。时间线要写到分钟，因为流程问题往往体现在时间差里。

改进项必须指定负责人和完成时间，并在后续例会上持续跟踪直到关闭。很多复盘做完就归档，问题在几个月后原样复现，原因正是改进项没有闭环。让每一次故障都留下一条真正被执行的改进，才是复盘的唯一价值。

九、把排障经验沉淀成值班手册

排障能力很难通过阅读文档获得，却可以通过结构化的记录不断累积。建议为每类高频故障建立一条标准处置记录，包含典型症状、需要采集的证据、建议的排查顺序、以及验证恢复的判定方式。内容不必长，但必须是团队真实执行过的步骤。

手册的写法要避免抽象描述。例如“检查网络配置”这样的表述没有执行价值，应当写成具体的检查项与观察点，例如查看哪一项状态、期望看到什么结果、如果不是这个结果说明什么。可执行的细节才是手册的价值所在。

手册需要有人维护。建议每次故障复盘后由参与处理的人补充一到两条经验，形成低成本、高频次的更新节奏。相比一次性编写一本厚厚的文档，这种渐进方式更容易持续，也更贴近实际环境的变化。

还可以把高频故障整理成值班前的自检清单，让接班的同事花十分钟确认关键监控、告警渠道与联系人是否可用。多数应急失手并非技术难题，而是信息缺失：不知道谁在处理、不知道去哪里看数据、不知道下一步该联系谁。

当手册积累到一定规模后，可以按故障分级重新组织，让不同场景下的人能快速找到对应章节。好的手册不是知识展示，而是在最紧张的时刻让人少想一步、快做一步的工具。

表 1：常见症状、证据来源与处置方向

如果需要更深入咨询了解可以联系全球代理上TG:@jinniuge  他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。