现场先看哪些信号
某团队第一次把星空入口放进真实流量里，是在一个工作日的上午。上线前他们只做了功能验证，没做现场观察计划，于是首个小时里所有人都在盯同一个页面，却没人说得清“正常”长什么样。这是场景推演里最常见的第一个约束：没有可对照的基线，任何异常都会被当成噪音。
星空入口作为入口层，本身不产生业务结果，它只负责把请求送到该去的地方。所以现场信号要分三层看，而不是只看一个总览数字。
- 入口层：请求是否被正确分发，有无明显偏向某一分支。
- 链路层：各分支的响应节奏是否一致，是否存在单点拖慢整体。
- 结果层：用户最终到达的页面是否符合预期，而不是停在中间态。
这三层要同时记录，缺一层就会在复盘时说不清因果。建议上线前就固定观察窗口，比如每十五分钟记一次，连续记满两小时。
现场最容易犯的错，是把“页面能打开”当成“入口工作正常”。能打开只是结果层的一个粗信号。
首周常见的故障模式
把多个团队的现场记录放在一起看，星空入口首周的故障模式其实相当集中，且大多不是代码缺陷，而是配置与预期错位。
- 分流倾斜：某条分支被分到远超预期的流量，原因往往是规则优先级写反或默认分支未设。
- 静默降级：某分支不可用时入口自动跳过，用户无感知地落到备用页，看起来一切正常。
- 缓存错位：入口层缓存了旧的分发结果，规则已改但现场仍走老路径。
- 重试放大：上游重试叠加入口重试，短时故障被放大成持续压力。
- 观测缺口：只监控入口总量，分支级异常被平均值掩盖。
这五类里，静默降级和观测缺口最危险，因为它们不制造报错，只制造错误的结果。推演时要专门为它们设计识别手段，比如给备用分支加独立计数，而不是依赖告警。
按顺序排查的推演路径
现场出问题时，最忌讳同时改三处配置。某团队的做法是固定一条排查顺序，从外到内逐层收敛，每一步只验证一个假设。 星空入口资讯
- 先确认现象范围：是全部用户还是特定分支，是持续还是间歇。
- 再核对规则快照：当前生效的分发规则与预期版本是否一致。
- 然后看分支级指标：哪条分支的计数与基线偏离最大。
- 接着验证缓存状态：入口层与下游缓存是否同步刷新。
- 最后才动配置：每次只改一项，改完立即回到第一步复测。
这条路径的价值在于约束了改动节奏。很多现场事故的二次伤害，来自排查过程中顺手改了不相关的东西，导致原问题被掩盖、新问题被引入。
回滚与恢复的边界
回滚不是失败，而是边界内的正常动作。关键是提前定义清楚：什么情况下必须回滚，回滚到什么状态，回滚后如何确认恢复。
- 触发条件：分支级错误持续超过约定窗口，且定位不到单一原因。
- 回滚目标：回到上一个已验证的规则快照，而不是临时修补的中间态。
- 恢复确认：回滚后重跑同一组观察信号，确认三层指标都回到基线。
- 记录要求：把回滚时间点、触发依据、恢复结果写进同一份记录。
边界之外还有一类情况：入口本身正常，但下游某分支已不可用。这时回滚入口没有意义，应走分支摘除而不是整体回退。区分这两种边界，能避免把局部问题升级成全局动作。
留一份可交接的一线备忘
首周结束后，某团队把现场记录整理成一页备忘，交接给下一班人。备忘不写结论口号，只写可复用的核对项。
- 观察窗口与记录频率是否已固定。
- 三层信号是否都有对应的对照基线。
- 静默降级是否有独立计数而非只靠告警。
- 规则快照版本是否可追溯、可回退。
- 回滚触发条件与恢复确认步骤是否写清。
- 本次场景推演中哪些假设被证伪，记下来。
这份备忘的作用不是防止所有故障，而是让下一个人在同样约束下少走一遍弯路。星空入口的现场判断，本质上是一次次把模糊现象收敛成可核对项的过程，复盘写清楚，比结论漂亮更重要。