星空入口的排障，最怕的不是没有日志，而是不知道先看哪一条。现场压力大、时间紧，如果只凭印象翻监控，很容易在无关指标上耗掉窗口期。这份清单按一线备忘的节奏整理，从信号观察开始，到回滚收尾，每项都可以直接对着当前环境打勾。
适用范围：已接入或正在接入星空入口的团队，需要在故障现场快速判断影响面、定位方向并决定是否回滚。不涉及具体厂商对比，也不替代正式变更流程。
现场先看哪些信号
先确认入口是否真的不可用，还是只是某个下游路径变慢。以下信号按优先级排列，逐项核对：
- 入口首页或主路径的可用性探测是否连续失败，失败是单点还是多地域同时出现。
- 入口到聚合层的请求量是否骤降，降幅是否与探测失败时间点吻合。
- 聚合层到各下游的调用量是否同步下降，还是只有入口侧下降而下游仍在正常处理。
- 错误码分布是否集中在某一类，例如超时、连接拒绝还是鉴权失败。
- 入口侧最近一次配置变更、证书更新或路由调整的时间，是否落在故障窗口内。
- 用户侧反馈是否集中在特定入口地址、特定网络环境或特定客户端版本。
把这几项写在同一张纸上，比在多个监控面板之间来回切换更快形成判断。
常见故障模式
现场遇到的多数问题，可以归到下面几类。每类都给出可观察的迹象，方便对号入座：
- 入口可达但聚合层不可达：入口探测正常，但聚合层健康检查失败，常见于内部网络策略调整后未同步。
- 聚合层可达但下游超时：入口和聚合层都正常，下游调用耗时上升，错误码以超时为主。
- 鉴权或令牌过期：错误码集中在鉴权失败，且发生在固定时间点之后，通常与密钥轮换或时钟偏差有关。
- 证书或域名问题：入口探测在部分地域失败，浏览器侧提示证书错误，常见于证书更新后未覆盖全部节点。
- 配置漂移：某台或某组节点的路由规则与其他节点不一致，表现为部分请求失败、部分正常。
- 容量瓶颈：请求量并未突增，但响应时间随并发上升而恶化，需要检查连接池和限流阈值。
现场最容易被忽略的是“部分正常”：只要还有请求成功，就容易误判为局部抖动而推迟处理。先确认失败比例和影响面，再决定动作。
诊断顺序
按从外到内、从近到远的顺序推进，避免同时改动多个变量：
- 确认影响面：是全部入口不可用，还是特定地域、特定路径或特定用户群。
- 确认时间线：故障开始时间、最近一次变更时间、监控告警时间三者对齐。
- 确认入口层：探测结果、证书状态、路由配置是否一致。
- 确认聚合层：健康检查、连接数、队列深度是否异常。
- 确认下游：逐个下游调用耗时和错误码，找出最先恶化的那一个。
- 确认变更：如果时间线与某次变更吻合，优先考虑回退该变更，而不是继续深挖。
- 保留现场：在动手恢复前，先保存关键日志、配置快照和监控截图，避免恢复后无法复盘。
每一步只回答一个问题，不要跳步。跳步的代价通常是恢复后仍然不知道根因，下一次故障重演。 星空入口
恢复与回滚
恢复动作要分级，先做可逆的、影响面小的操作：
- 第一级：重启异常节点或摘除故障节点，观察失败比例是否下降。
- 第二级：回退最近一次配置变更，确认变更回退后入口是否恢复。
- 第三级：切换备用入口地址或备用聚合路径，注意切换后要同步更新探测目标。
- 第四级：降级非核心功能，保住主路径可用，同时记录降级范围。
- 回滚前确认：回滚目标版本是否可用、回滚后配置是否与当前环境兼容、回滚是否需要同步下游。
- 回滚后确认：入口探测恢复、错误码回到基线、下游调用量回到正常区间。
- 恢复后动作：补齐变更记录、更新监控阈值、把本次触发条件写入下一次核对清单。
带走这份核对清单
把下面这些项打印出来，贴在排障工位旁。每次故障后逐项打勾，缺哪项补哪项：
- 入口探测覆盖了主要地域和主要路径，不是只探一个点。
- 错误码分类清晰，能区分超时、拒绝和鉴权失败。
- 最近变更记录可查，且能快速定位到具体配置项。
- 回滚预案写明目标版本、操作步骤和验证方式。
- 关键日志和配置快照在恢复前已保存。
- 下游依赖清单完整，知道先看哪一个。
- 备用入口或备用路径经过验证，不是纸面方案。
- 故障复盘有固定模板，能沉淀为下一次的检查项。
这份清单不追求一次写全，而是每次排障后补一条。星空入口的稳定性，往往就藏在这些被反复核对的细节里。