主题
可靠性
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
129 道问题
本页为第 51–100 题，共 129 题。
A · 专业解题与实现31
- 用户更新后偶尔加载到新 HTML 和旧 JavaScript，页面因此报错。你会怎样设计静态资源命名、缓存策略和发布顺序来降低不一致？
- 一个请求启动了多个异步任务；客户端断开或请求超时后，部分下游工作仍占用线程和连接。你会怎样让取消信号传到相关任务，并释放资源？
- 产品要向数千万用户发送事务通知和可选营销通知，用户可以随时调整渠道偏好。你会如何设计通知发送流程？
- 一次跨时区交接期间，关键告警已发送，但原值班人以为新值班人会处理，新值班人又没有收到确认；故障因此延迟升级。你会怎样还原责任链，修复告警确认与交接机制，并验证改动有效？
- 一次下游抖动后，上游流量没有明显增加，但请求数和队列长度翻倍，多个服务开始超时。你会怎样判断是否出现重试放大？
- 一个搜索服务需要调整分词和排序特征，同时不能让重建过程造成长时间结果缺失或明显增加写入延迟。你会怎样安排索引演进？
- 一个多租户平台要向客户系统发送事件通知（Webhook）。你会如何设计发送和重试流程，并处理客户端长期不可用的情况？
- 更换嵌入模型后，新旧向量不可直接比较，但重建全量向量需要数天。你会怎样设计迁移和查询切换？
- 团队发现模型可能在公开语料或微调数据中见过部分内部评测题。你会如何判断离线成绩还能说明什么，并重建可信评测？
- 新模型离线评测提升，但少数高价值用户的回答质量可能下降。你会怎样安排小范围发布、观察结果，并判断何时扩大使用？
- 产品依赖外部模型接口，供应商可能限制调用频率或调整可用模型。你会如何设计切换规则和非核心功能的临时关闭方式，让切换后的质量变化可以被发现？
- 平均耗时稳定，但最慢 1% 请求的响应时间逐步变长，且不同租户差异明显。你会怎样区分排队、锁竞争、下游调用和资源隔离问题？
- 高峰时入口记录了请求，但下游没有对应事件，重试还会放大流量。你会如何沿着请求经过的服务逐段查找丢失和重复的位置？
- 多个客户共享异步作业平台，有的租户会提交大量长任务。你会怎样设计调度、隔离、配额，以及用日志、指标和调用记录了解队列运行情况？
- 某些对象成为热点，读取延迟恶化而写入又必须保持顺序。你会怎样划分缓存、分区和写入协调策略？
- 业务要求追溯每次状态变化，并在必要时安全地重新处理历史消息；但部分旧事件格式不完整。你会怎样设计事件版本、保留期限和重新处理范围？
- 跨区域服务需要在区域故障时维持关键功能，但部分数据不能接受冲突覆盖。你会怎样选择故障期间保留哪些功能、如何复制数据，以及如何恢复？
- 实时协作服务有大量长连接，慢客户端会积压更新。你会如何选择丢弃、合并、限制慢客户端接收和重新同步策略？
- 服务刚发布时耗时正常，运行数小时后最慢 1% 请求逐步变慢，重启后暂时恢复；CPU 平稳，但连接数和堆内存缓慢增长。你会怎样拆解假设并设计低风险验证？
- 一个入口服务同时调用多个下游，其中一个非核心依赖偶尔变慢，导致请求线程耗尽并拖累其他功能。你会如何设计超时、并发隔离、必要时关闭非核心功能和恢复策略？
- 一个 AI 助手在少数请求上会反复调用搜索、数据库和外部 API，最终耗时和费用远高于平均值。你会如何设计单次任务的预算、停止条件、避免重复操作的保护和审计记录？
- 核心服务的月度可用性仍达到目标，但故障额度消耗速度突然加快，且错误集中在一个新发布的功能。你会如何判断是否暂停发布或回滚？
- AI 功能依赖的模型服务耗时波动很大，导致用户请求超过整体时限。你会如何为检索、模型调用和后处理分配时间，并设计超时后的核心功能保障方案？
- 页面默认语言下布局正常，切换到另一种语言后少数按钮溢出、表格错位；错误只出现在窄屏和系统字体放大时。你会如何缩小问题范围并建立回归验证？
- 新安装设备正常，但升级过多个版本的用户报告本地草稿消失；问题无法稳定复现，服务端没有对应删除记录。你会如何保护现场并调查迁移、缓存清理和生命周期回调？
- 移动端上传大文件时网络可能中断，用户会重复点击重试；系统还按成功处理量计费。你会如何设计分片、校验、续传状态、最终提交和计费时点？
- 一次业务规则修正要求重算多个服务产生的历史记录，但部分消费者已经发送通知或执行外部动作。你会如何列出影响范围，决定哪些历史数据需要重新处理，并防止重复触发外部操作？
- 某依赖服务变慢后，多个调用方同时增加重试，流量反而翻倍并使故障范围扩大。你会如何设计重试预算、退避、抖动和跨服务协调？
- 用户提交长时间运行的 AI 分析后关闭页面，稍后又从另一设备查看进度；任务可能触发多个工具并产生部分结果。你会如何设计任务状态、取消、重试和结果可见性？
- 模型已经向用户流式输出部分内容，随后连接中断或安全校验失败；客户端可能误以为答案完整。你会如何设计完成标记、撤回或补充提示和重试行为？
- 用户可上传压缩包供系统解析，历史事故显示恶意文件会耗尽资源或越权访问路径。你会如何设计隔离、解压限制、内容检测和安全失败策略？
当前目标在这里暂无匹配题。 ·
B · 业务理解与领域建模1
C · 价值判断与方向规划1
D · 交付执行与持续运营15
- 一次数据写入事故已停止，服务指标也回到常态，但仍有用户报告缺失记录。你会怎样组织恢复验证与后续沟通？
- 支付风控依赖变慢后，结账整体超时。业务要求尽量保留转化，同时不能绕过关键安全检查。你会如何决定哪些结账功能可以暂时关闭、哪些检查必须保留？
- 团队每个迭代都被事故和恢复任务打断，路线图连续延期；管理层要求保持既定日期，同时不希望增加人手。你会如何提出容量和目标调整？
- 一次大促在夜间上线后因请求过多而卡住，大量用户无法领取优惠券并开始投诉。作为参与活动的工程师，在恢复系统的同时，你会怎样与运营和客服协同，评估并落实临时业务措施？
- 一个系统总是反复出问题，补一次又出一次。你怎样找到根本原因，怎样让团队从救火转向真正的修复，又怎样证明它不再复发？
- 线上服务突然大面积失败，你在第一个小时里会按什么顺序行动？
- 一次重大事故产生 18 条改进行动，涉及架构、监控、培训和流程；各团队已有季度承诺。你会如何筛选真正降低复发风险的行动？
- 怎样避免同类的个人失误再次发生？你改进的是流程和工具，还是只是提醒自己以后小心？怎么知道改进有效？
- 生产事故中，技术负责人要求关闭功能，业务负责人要求继续接单，客服团队又承诺了恢复时间。现场成员收到相互冲突的指令。你会如何组织响应？
- 一份关键运营手册仍被多个地区依赖，但原作者已离职，最近的系统和政策变化也没有同步进去。你会怎样判断哪些步骤仍安全、如何安排临时控制和更新责任，并验证新版本能被一线正确执行？
- 一个自动审批服务停摆后，运营团队临时改用表格处理，用户影响暂时得到控制。两周后服务仍未恢复，表格流程的权限和记录方式也不一致。你会如何管理临时人工流程、恢复自动审批，并确定何时关闭临时流程？
- 移动端新版本先向 5% 用户发布，崩溃率看起来翻倍，但活跃设备数少且主要来自一种旧机型；营销活动即将开始。你会如何止损、补证据并决定继续、暂停或回退？
- 一次线上事故已恢复，复盘会列出监控补充、容量验证和手册更新等十余项行动；类似问题过去也开过行动项但无人验收。你会如何给改进事项定负责人和期限，并验证它们是否有效？
- 新版本发布后移动端网络失败率上升，服务端指标正常；受影响用户集中在旧系统版本和弱网环境。你会如何划定事故范围、减缓影响并决定暂停发布或回退？
- 核心服务部分不可用，原因尚未确认，客户、管理层和合作方都要求更新时间；团队担心过早说明会造成误解。你会如何区分已知事实、假设、行动和下次更新时间？
当前目标在这里暂无匹配题。 ·
E · 协作沟通与影响1
当前目标在这里暂无匹配题。 ·