可靠性与事故

• 一次数据写入事故已停止，服务指标也回到常态，但仍有用户报告缺失记录。你会怎样组织恢复验证与后续沟通？
• 一个发布项目的容量、供应商交付和数据质量风险分别都低于各自升级阈值，但三者可能在同一周叠加。你会怎样判断组合风险，并决定采取什么行动？
• 支付风控依赖变慢后，结账整体超时。业务要求尽量保留转化，同时不能绕过关键安全检查。你会如何决定哪些结账功能可以暂时关闭、哪些检查必须保留？
• 一次大促在夜间上线后因请求过多而卡住，大量用户无法领取优惠券并开始投诉。作为参与活动的工程师，在恢复系统的同时，你会怎样与运营和客服协同，评估并落实临时业务措施？
• 一个系统总是反复出问题，补一次又出一次。你怎样找到根本原因，怎样让团队从救火转向真正的修复，又怎样证明它不再复发？
• 线上服务突然大面积失败，你在第一个小时里会按什么顺序行动？
• 一次重大事故产生 18 条改进行动，涉及架构、监控、培训和流程；各团队已有季度承诺。你会如何筛选真正降低复发风险的行动？
• 怎样避免同类的个人失误再次发生？你改进的是流程和工具，还是只是提醒自己以后小心？怎么知道改进有效？

当前目标在这里暂无匹配题。 切换目标 · 查看全部题目

• 生产事故中，技术负责人要求关闭功能，业务负责人要求继续接单，客服团队又承诺了恢复时间。现场成员收到相互冲突的指令。你会如何组织响应？
• 移动端新版本先向 5% 用户发布，崩溃率看起来翻倍，但活跃设备数少且主要来自一种旧机型；营销活动即将开始。你会如何止损、补证据并决定继续、暂停或回退？
• 一次线上事故已恢复，复盘会列出监控补充、容量验证和手册更新等十余项行动；类似问题过去也开过行动项但无人验收。你会如何给改进事项定负责人和期限，并验证它们是否有效？
• 新版本发布后移动端网络失败率上升，服务端指标正常；受影响用户集中在旧系统版本和弱网环境。你会如何划定事故范围、减缓影响并决定暂停发布或回退？
• 核心服务部分不可用，原因尚未确认，客户、管理层和合作方都要求更新时间；团队担心过早说明会造成误解。你会如何区分已知事实、假设、行动和下次更新时间？
• 一个高危依赖漏洞需要尽快修复，但补丁与当前发布候选存在兼容风险；推迟会延长暴露窗口，立即发布又可能引发服务中断。你会如何安排验证、临时缓解和发布授权？
• 队列因消费者故障积压数小时，修复后大量旧消息即将重新处理；下游包含计费、通知和分析系统，处理能力与重复操作风险各不相同。你会如何安排恢复速度并保护下游？
• 核心依赖服务故障后已经恢复大部分功能，但错误率仍高于故障前水平；上游积压持续增长，业务方要求尽快恢复全部流量。你会如何确定恢复条件和流量节奏？

当前目标在这里暂无匹配题。 切换目标 · 查看全部题目

• 一次故障因为监控没有覆盖关键用户路径，团队直到客服升级后才发现。复盘决定增加监控，但团队还需要证明新机制能更早发现问题且不会制造大量噪声。你会如何设计验证？
• 发布后，登录、支付和通知服务接连出现异常，多个团队各自认为自己的故障最紧急，且部分告警可能来自同一个根因。你会如何协调响应、确定优先级并避免互相干扰？
• 一次故障没有达到客户承诺的重大事故门槛，但影响了少量客户并暴露流程缺口。你会如何决定是否公开复盘及公开到什么程度？
• 上游事件延迟数小时，下游报表仍显示正常完成，客户据此做了错误决策。你会如何设计数据新鲜度状态和通知？
• 业务依赖一个没有书面服务承诺的第三方接口，供应商支持响应不稳定。你会如何定义内部连续性目标和备用方案？
• 第三方服务已经恢复，但故障期间的回调可能丢失。客户看到的状态与平台记录不一致。你会如何确认影响并沟通？
• 服务中断已解除，少量客户仍有错账，客服承诺的补偿也未兑现。你会怎样定义事故关闭条件和持续跟进责任？
• 一次版本导致查询失败，回滚旧版本可能无法读取新格式数据。你会怎样止损并比较回滚、前向修复和兼容层？

当前目标在这里暂无匹配题。 切换目标 · 查看全部题目