现场先看哪些信号
某项目组准备把pg平台接进夜间值班链路，场景并不复杂：白天有人盯，夜里只留一名值班同学。约束也很明确——不能因为一个新平台把原本稳定的巡检节奏打乱，出问题要在十分钟内回到旧流程。 pg平台使用指南
这类场景下，先别急着讨论pg平台功能介绍里写了多少能力，而是先看现场有哪些信号值得记录。pg平台使用指南里提到的配置项，落到一线往往变成几个具体观察点。
- 值班同学能否在不查文档的情况下说出入口位置和常用操作。
- pg平台常见问题里被反复提到的报错，是否在本地环境里也出现过。
- 旧流程和新流程并行时，两边数据是否会出现对不上的情况。
- 夜间网络波动时段，平台响应是否明显变慢。
现场经验：凡是需要“临时想起来再查”的步骤，都不算真正接入完成。
容易踩到的故障模式
推演阶段最容易忽略的不是大故障，而是小偏差累积。以下模式在类似场景里反复出现，值得提前标记。
- 权限边界模糊：某位同学能看但不能改，误以为平台故障，实际是角色没配对。
- 通知链路断裂：平台侧有提醒，但值班群没收到，问题被延迟发现。
- 状态不一致：旧流程标记完成，pg平台里仍是处理中，交接时产生分歧。
- 依赖单点：只在一台设备上验证过，换设备后操作路径不熟。
这些模式单独看都不致命，但在夜间低人力场景下会互相放大。
排查顺序怎么排
遇到异常时，顺序比工具更重要。建议按由外到内、由简到繁的方式推进，避免一上来就怀疑平台本身。
- 先确认网络与登录状态，排除环境问题。
- 再核对账号角色与权限，确认不是配置遗漏。
- 接着检查通知链路，确认提醒是否真的发出。
- 最后才对比pg平台功能介绍中的预期行为，判断是否为功能理解偏差。
这个顺序的好处是，大部分问题在前两步就能定位，不必进入复杂排查。
边界情况怎么处理
有些情况不属于故障，而是边界。例如并发操作、跨时段交接、临时账号启用等。遇到这类情况，先记录现象和时间点，再决定是否需要回退，而不是现场临时改配置。
回退与恢复动作
回退不是失败，而是接入前的必要准备。某项目组的做法是保留旧流程至少一个完整值班周期，确认新链路稳定后再逐步切换。
- 明确回退触发条件，例如连续两次通知未达或状态长时间不一致。
- 回退动作写成短步骤，控制在三步以内，避免夜间操作出错。
- 回退后仍保留pg平台的观察记录，用于后续复盘。
- 恢复时先小范围验证，再放开到全体值班同学。
交接前的核对清单
接入前做一次完整核对，比事后补救更省力。以下清单可直接用于交接会。
- 值班同学是否都能独立完成一次完整操作。
- pg平台常见问题是否已有本地化答案，而不是只指向外部文档。
- 通知、权限、状态同步三项是否都验证过。
- 回退步骤是否写清、放到位、有人确认过。
- 是否有专人负责接入后第一周的观察记录。
把这份备忘放在值班入口处，比任何功能介绍都更贴近现场。