A · 专业解题与实现
调试与定位
从现象出发缩小范围、提出假设、验证并修复。
分类边界
收录: 收录从异常现象定位原因、验证假设并修复的问题。
相邻分类判断: 预先设计容量与故障策略归系统设计;构建测试和发布门禁归质量、安全与防护。
这项能力可能会在不同阶段标准中以不同深度出现。 查看阶段要求
24 道问题
按需要了解的证据选择分组。分组依据现有题型,不代表难度或必经顺序。每批最多八题。
判断与方案10
比较目标、约束、方案与取舍依据。
第 1–8 题
- 你的接口本地测试正常,联调时前端同学坚持说接口报错或没返回数据。你会用哪些手段去定位,又怎样拿出让对方信服的证据?
- 缓存失效后,大量请求同时回源,服务恢复时又出现第二次流量尖峰。你会怎样定位并抑制缓存击穿与预热风暴?
- 线上偶尔出现同一订单被提交两次,你在本地无法复现。你会怎样缩小范围,并决定先止血还是先补观测?
- 把一个很大的前端包拆成多个小包以后,首屏反而更慢了。你会怀疑哪些原因,怎样验证?
- 缓存键已失效,应用日志显示重新读取数据库,但部分用户仍看到旧资料;切换到主库后问题减少却没有消失。你会怎样沿缓存、副本和客户端定位?
- API 延迟升高时数据库 CPU 很低,但应用日志出现等待连接。你会如何区分连接泄漏、池容量不足和慢事务占用?
- 对账任务发现同一业务对象的事件时间顺序偶尔倒置,日志又分布在多个区域。你会如何判断是时钟偏差、异步延迟还是业务排序规则的问题?
- 一次跨时区交接期间,关键告警已发送,但原值班人以为新值班人会处理,新值班人又没有收到确认;故障因此延迟升级。你会怎样还原责任链,修复告警确认与交接机制,并验证改动有效?
当前目标在这里暂无匹配题。 ·
实现与验证14
检视方案如何执行、验证和纠偏。
第 1–8 题
- 一个接口从昨天开始变慢,但没有任何发布记录。给你日志、监控和数据库慢查询记录,你会按什么顺序排查?
- 一个列表页面滚动卡顿,但网络指标正常、内存也未明显增长。你会如何判断是主线程计算、布局/绘制还是锁等待导致?
- 数据库字段变更完成后,只有部分下游任务间歇性失败。你会怎样找出仍在使用旧接口约定的消费者,并确定回滚还是兼容修复?
- 月度汇总与明细报表最初一致,几周后差异逐渐扩大。你会如何把问题缩小到规则变更、迟到数据、重复处理或历史回补?
- 一个关键依赖只在某个区域间歇性超时,整体健康检查仍显示正常。你会如何判断影响面,并安全地隔离或临时关闭非核心功能?
- 消息积压经常在扩容后下降,几小时后又反弹。你会检查哪些生产者、消费者和消息特征,以判断真正瓶颈在哪里?
- 服务平均耗时基本不变,但最慢 1% 的请求连续一周变慢,投诉集中在少数大客户。你会如何定位问题并决定先验证什么?
- 某页面服务端 HTML 正常,但水合后出现内容闪动并伴随控制台警告。你会如何定位服务端与客户端渲染结果的差异来源?
当前目标在这里暂无匹配题。 ·
第 9–14 题
- 一次下游抖动后,上游流量没有明显增加,但请求数和队列长度翻倍,多个服务开始超时。你会怎样判断是否出现重试放大?
- 服务刚发布时耗时正常,运行数小时后最慢 1% 请求逐步变慢,重启后暂时恢复;CPU 平稳,但连接数和堆内存缓慢增长。你会怎样拆解假设并设计低风险验证?
- 某功能在公司网络和多数家庭网络正常,但在特定运营商或弱网环境下请求经常超时;服务端错误率没有同步上升。你会如何定位客户端、网络路径、协议和重试策略之间的原因?
- 客户端只看到一次提交,但服务端偶尔出现两条相同记录;问题通常发生在请求超时后重试,且日志没有明显异常。你会如何重建调用时间线并验证重复写入发生在哪一层?
- 页面默认语言下布局正常,切换到另一种语言后少数按钮溢出、表格错位;错误只出现在窄屏和系统字体放大时。你会如何缩小问题范围并建立回归验证?
- 新安装设备正常,但升级过多个版本的用户报告本地草稿消失;问题无法稳定复现,服务端没有对应删除记录。你会如何保护现场并调查迁移、缓存清理和生命周期回调?
当前目标在这里暂无匹配题。 ·
当前目标在这项能力中暂无匹配题。 ·