模拟三面：故障排查与系统设计

原创故障演练，不代表本人经历过真实生产事故。建议 60 分钟，每题先问清影响范围，再给止损、定位、修复和验证，避免直接报一个中间件名字。

1. 用户已经退出，旧 JWT 为什么还能访问？

先澄清： 是浏览器本地退出、IdP 退出还是管理员撤权？接口使用本地会话还是离线验 JWT？影响哪些应用？

推理： 删除会话不改变已签发 JWT 的签名和过期时间。检查会话映射、注销事件、JWT TTL 和资源服务器是否在线检查状态。

处理： 高风险操作先通过可信撤权状态拒绝；根据架构选择短期 token、内省或撤权版本检查。不要直接关闭验签，也不要未经评估轮换全局签名密钥使所有用户掉线。

追问： 注销通知重放、丢失怎么办？

回答： 验证 Logout Token 并按会话幂等清理；重放不能造成非目标用户退出。通知丢失靠补偿与会话期限兜底。issuer 与 sid 联合定位，不能全局只用 sid。协议参考：OIDC Back-Channel Logout。

验收： 在线检查点之后的访问被拒绝，残留离线接受窗口被量化记录。

2. Redis 不可用，权限系统要不要全部放行？

先澄清： Redis 存的是缓存、唯一会话状态，还是安全决策的唯一来源？数据库能否承受回源？

处理： 不能统一 fail-open。写操作或无法确认授权的请求拒绝；缓存场景可受限回源，增加超时、并发限制与熔断，避免把数据库打垮。若会话只存在 Redis，缓存丢失不能靠客户端声明恢复身份。

追问： 可用性和安全怎么平衡？

回答： 按操作风险定义降级：公开内容可继续，敏感写入拒绝；经批准的只读缓存可允许有限陈旧窗口，但必须记录策略。安全与可用性取舍由业务明确，不由异常处理临时决定。

验收： 故障注入下无越权，回源负载受控，用户收到可理解且不泄露内部信息的错误。

3. IdP 换了签名密钥，新 token 突然全部失败？

推理： 检查 issuer、kid、算法、JWKS 更新、缓存期限、网络错误和系统时间。token 里的 jku 等地址不能成为任意可信密钥来源。

处理： 从预配置的可信发行者获取密钥，针对未知 kid 做受限刷新，防止攻击者制造大量随机 kid 导致请求风暴；保留合法重叠期所需旧密钥。绝不为了恢复服务跳过签名验证。

追问： JWKS 服务不可用，但本地有旧 key 呢？

回答： 按明确缓存策略验证已知 key 的合法 token；未知 key 不能凭空验证，应拒绝并告警。密钥被撤销与正常轮换的应急策略不同，不能无限信任旧缓存。

验收： 正常轮换、未知 kid 洪泛、密钥源不可用、错误 issuer 四组测试。

4. 工单接口超时，重试后出现两张工单？

推理： 超时说明本地没拿到结果，不说明对方没执行。检查同一次业务动作是否复用幂等键、数据库约束是否生效、下游是否支持幂等。

处理： 为不确定操作设置 UNKNOWN，优先根据业务标识查询；能确认则补记结果，不能确认则人工对账。只有明确可重试条件才自动重试。外部已重复写入的清理需要业务授权，不能默默删单。

追问： 把 Redis 锁设长一点能解决吗？

回答： 不能证明端到端只写一次，锁与下游结果不原子。持久业务唯一约束、下游幂等能力及对账路径才是关键。

验收： 模拟“下游提交成功后断响应”，检查只形成一个最终业务动作或明确转人工，不用纯失败桩代替。

5. 审计怎么帮助定位一次越权报告？

回答主线： 先根据 trace/task/operation 找到用户、已认证执行应用、租户、委托版本、工具动作、资源与策略决策原因，再对照当时授权变更和执行时间。区分网关拒绝与下游真正提交。

追问： 为了方便排查，能记录完整 token 和文档吗？

回答： 不应。记录安全标识与脱敏元数据，限制日志访问和保留期；敏感内容按必要性审批取证。日志不是天然不可篡改，应有访问控制、集中收集与完整性措施。

验收： 用一条脱敏请求完整还原过程；扫描日志、异常和追踪属性确认无凭证泄露。不要虚构“故障定位缩短 80%”。

6. 旧登录体系迁移到 OIDC，如何发布？

回答主线： 先明确旧用户与新身份的可靠绑定方式，处理重复邮箱与绑定冲突；测试环境完成回调、会话和权限对照，再选择小范围应用/用户验证。保持可回退的登录入口与数据迁移记录，不能以关闭权限校验作为回滚方式。

追问： 能直接按邮箱自动合并吗？

回答： 不能假设邮箱唯一且可信。需要验证身份源、邮箱验证状态和原账号控制权；敏感账号采用人工复核。回滚代码不意味着已经修改的账号映射自动恢复，迁移要独立可追踪。

验收： 身份冲突、重复回调、旧会话兼容、回滚演练都有记录；本项目未做迁移时，应明确这是方案推演。

7. 你会设哪些生产指标？

回答主线： 登录成功率按错误原因拆分；会话刷新失败与竞争次数；授权拒绝原因；工具网关自身 P95；下游耗时；UNKNOWN 操作积压；审计缺失与撤权传播延迟。模型延迟与身份链路分开统计，防止平均值掩盖问题。

追问： 你说 99.9% 可用，是怎么来的？

回答： 没有长期观测就不宣称达到。先定义请求分母、排除项、观测窗口和错误预算，再测量。实验压测只报告对应环境结果；被策略正常拒绝的越权请求不应简单算作服务错误。

验收： 每个指标有定义、采集点、标签基数约束和实际样本，不在监控标签中放无限增长的 user_id/task_id。

评分与改进

每题 0–4 分：澄清范围、正确推理、安全止损、可验证恢复，各 1 分，总分 28 仅用于练习。答题时特别检查：有没有将“不知道结果”误判为“没有执行”，有没有为了可用性取消鉴权。

下一轮：项目深挖与综合面。