主题
可靠性
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
129 道问题
本页为第 101–129 题，共 129 题。
A · 专业解题与实现12
- 用户看到响应时间翻倍，但模型推理耗时指标没有明显变化。你会怎样拆解请求处理的各个阶段，定位瓶颈并确定止损措施？
- 为降低推理成本，团队按问题文本缓存答案。但用户权限、知识库版本和地区规则可能不同。你会如何确定缓存键与失效机制？
- 一笔跨数百万记录的迁移无法放进单个事务。业务要求用户不能看到半完成状态。你会如何设计分批写入、可见性和恢复？
- 托管模型没有提前通知就升级，常规健康检查仍通过，但分类边界和输出长度发生变化。你会如何建立保护？
- 你要为异步函数增加重试与超时，最终失败时调用方仍需知道每次尝试的错误和是否已产生副作用（重复执行、越权等额外影响）。会如何设计返回值？
- 服务 CPU 平均使用率只有 35%，但请求队列持续增长，部分线程等待外部 I/O。你会怎样识别真实容量瓶颈？
- 数据库存储膨胀，清理任务反复扫描却无法回收空间；同时存在运行数小时的报表事务。你会如何定位与治理？
- 实例的健康检查只验证进程存活，但用户请求因关键依赖超时而失败。若把依赖检查都加进探针，又可能导致全量摘除。你会如何设计？
- 多个区域独立接收同一请求，请求去重记录会在一段时间后过期，机器时钟可能偏差数秒。你会怎样确保临近过期时重试不会产生重复写入？
- 线上索引需要改变分片键，数据量增长很快且写入不能停止。你会如何规划新旧索引并判断何时切换？
- 多租户查询平台使用共享数据库连接池，某个租户提交大量复杂报表后，其他租户请求延迟明显增加。你会如何隔离和计量？
- 产品信息同时存在于应用缓存、CDN 和客户端缓存，价格更新后不同用户看到不同值。你会怎样定义刷新、版本和失效语义？
当前目标在这里暂无匹配题。 ·
D · 交付执行与持续运营12
- 一个高危依赖漏洞需要尽快修复，但补丁与当前发布候选存在兼容风险；推迟会延长暴露窗口，立即发布又可能引发服务中断。你会如何安排验证、临时缓解和发布授权？
- 队列因消费者故障积压数小时，修复后大量旧消息即将重新处理；下游包含计费、通知和分析系统，处理能力与重复操作风险各不相同。你会如何安排恢复速度并保护下游？
- 核心依赖服务故障后已经恢复大部分功能，但错误率仍高于故障前水平；上游积压持续增长，业务方要求尽快恢复全部流量。你会如何确定恢复条件和流量节奏？
- 一次故障因为监控没有覆盖关键用户路径，团队直到客服升级后才发现。复盘决定增加监控，但团队还需要证明新机制能更早发现问题且不会制造大量噪声。你会如何设计验证？
- 发布后，登录、支付和通知服务接连出现异常，多个团队各自认为自己的故障最紧急，且部分告警可能来自同一个根因。你会如何协调响应、确定优先级并避免互相干扰？
- 一次故障没有达到客户承诺的重大事故门槛，但影响了少量客户并暴露流程缺口。你会如何决定是否公开复盘及公开到什么程度？
- 上游事件延迟数小时，下游报表仍显示正常完成，客户据此做了错误决策。你会如何设计数据新鲜度状态和通知？
- 业务依赖一个没有书面服务承诺的第三方接口，供应商支持响应不稳定。你会如何定义内部连续性目标和备用方案？
- 监控系统会自动重启异常服务，但本次问题来自共享数据层，批量重启可能加剧连接风暴。你会如何设计自动化边界？
- 第三方服务已经恢复，但故障期间的回调可能丢失。客户看到的状态与平台记录不一致。你会如何确认影响并沟通？
- 服务中断已解除，少量客户仍有错账，客服承诺的补偿也未兑现。你会怎样定义事故关闭条件和持续跟进责任？
- 一次版本导致查询失败，回滚旧版本可能无法读取新格式数据。你会怎样止损并比较回滚、前向修复和兼容层？
当前目标在这里暂无匹配题。 ·