能力域 D
交付执行与持续运营
如何把目标变成可靠行动，并运行、纠偏、闭环。
查看这个能力域如何映射到阶段要求。 打开能力模型
先选一项能力。每类只预览三题，进入后按考察重点分批阅读；预览不代表重要性排名。
162 道问题 · 5 项能力
问题拆解26
把模糊目标拆成可估算、可验证的任务。
- 连续三个季度，多个团队的项目都低估了集成与验收时间。你会怎样用已有预测和实际记录判断偏差来自估算方式、范围变化还是排期机制，并改进下一轮预测？
- 业务要求“改善客户体验”，但没有明确痛点或期限。你会怎样把目标拆成可验证的问题、工作流和阶段性结果？ 追问：如果关键依赖延期一个迭代，你会如何重排关键路径、更新承诺并减少等待？
- 提出者已经指定了重写服务作为方案，但故障数据指向多个可能原因。你会如何回到问题定义并确定验证顺序？
- 业务方提出的问题还不清楚。你会先查找哪些资料、找谁核实，并怎样区分已确认的事实和推测？最后如何把结论整理成可执行的方案？
- 不同团队对同一个业务问题给出了相反的数据和解释，而项目已经排进本季度。你会怎样决定先查什么、暂缓什么？
- 说一个你负责过的最复杂的功能。你怎样把一个模糊的业务诉求，一步步拆成没有逻辑漏洞的需求文档？遇到断网、账户异常这类边缘情况，你怎样设计容错和交互？
- 项目过半时可用人力突然减少一半，但目标日期不变。你会如何重排工作并与相关方重新约定结果？
- 客户要求“给我一个实时大屏”，但访谈中提到的问题可能只是每天晚些时候才发现库存错误。你会如何推进讨论？
- 接到一个你从没做过的需求，你怎样拆分任务，并给出一个之后可以被检验的估算？
- 一项身份字段变更涉及客户端、API、数据仓库和外部合作方，初始计划只列出服务端开发与前端改版。你会如何拆解依赖图并识别迁移、回滚和验收中的遗漏工作？
- 需求只写了“减少用户填写时间”，没有说明哪些字段可选、数据错误后果或不同用户的流程差异。你会如何拆解研究、交互方案、技术验证和结果验收？
- 目标是提高购买转化，但流量质量、页面理解、支付方式和库存都可能影响结果；团队希望每周汇报进展。你会如何把最终目标拆成诊断任务、先行信号和阶段性决定？
- 团队准备把订单数据迁移到新存储，读取路径先切换，写入路径稍后改造；计划只包含开发和上线，没有明确数据差异校验或回退条件。你会如何补全迁移分解？
- 产品认为功能上线即完成，运营认为培训和监控到位才算完成，客户则要求旧流程迁移成功。你会如何澄清结果、交付物和各方验收责任？
- 新系统依赖尚未验证的第三方能力，团队无法准确估算完整实施；管理层要求给出可信时间范围。你会如何安排技术探针、风险验证和后续交付阶段？
- 业务要减少用户投诉，但投诉来源包括应用、电话和合作方转接；现有数据无法统一识别同一问题。你会如何拆解埋点、身份关联、流程改进和结果评估？
- 一项监管要求有固定生效日期，产品团队希望同步优化流程体验；两者共享同一后端改造，但体验需求仍在调研。你会如何拆分不可变合规范围与可迭代体验工作？
- 一个交付目标涉及客户端、服务端、数据和运营，且最终效果依赖各方同时就绪。你会如何拆分工作流，识别关键路径并安排集成验证？
- 一个跨团队项目每周都会收到新的业务反馈，已拆分的任务不断失效。你会如何区分稳定目标与变化假设，并设计能吸收变化的工作切片？
- 新系统需要逐步替换旧系统，迁移期间两边都要服务真实用户，且数据和功能按批次切换。你会如何拆解迁移、验证点和回退条件？
- 团队认为返工过多，但有人统计缺陷修复，有人统计需求变更，还有人统计代码重写。你会如何定义问题并制定改进目标？
- 领导要求下季度提升研发效率，但没有定义效率。团队有人提议提高提交数，有人要减少会议。你会怎样建立改进方向？
- 多个产品团队都以减少客户抱怨为目标，但投诉分类、渠道和责任范围不同。你会怎样拆出共同指标与团队行动？
- 团队把发布质量列为季度重点，但有人关注回滚次数，有人关注缺陷，有人关注上线速度。你会如何定义共同目标？
- 身份服务、前端登录和客服操作台分别按期交付，但新客户仍无法完成开户。你会怎样确定由谁负责整合并验收完整流程？
- 公共组件已有多种变体，新增业务希望再增加特殊状态。你会怎样比较复用价值、复杂度、可访问性和未来维护成本？
当前目标在这里暂无匹配题。 ·
容量与依赖34
容量、依赖、承诺与资源冲突。
- 一次严重线上事故要求原项目团队中的两位专家连续一周参与恢复，原定里程碑因此面临变化。你会怎样更新预测、划分事故与项目责任，并让相关方作出取舍？
- 项目依赖另一个团队提供接口或数据契约，但交付责任不清、计划持续变化，下季度能否排入仍不确定。你会如何建立可兑现的承诺、准备替代方案、管理关键路径风险，并决定何时升级或调整范围？
- 面对一个还不清晰的大问题，你怎样规划需要多少人和资源？在不确定的情况下怎样给出估计，怎样分阶段投入，又怎样向上申请？
- 团队连续几个月靠加班守住交付，你怎样判断这是个人问题还是容量缺口，并怎么处理？
- 团队每个迭代都被事故和恢复任务打断，路线图连续延期；管理层要求保持既定日期，同时不希望增加人手。你会如何提出容量和目标调整？
- 团队连续几个季度都因线上支持、客户升级和跨团队求助偏离路线图。有人建议统一预留 20% 容量，但团队间中断频率差异很大。你会怎样确定预留方式？
- 你怎样算出团队下个周期真正能承诺的容量，而不是“人数乘以工作日”？
- 做这个决策时，你手上有哪些资源，协作的范围有多大？这些限制对你的选择产生了什么影响？
- 三个项目都把同一平台团队列为关键依赖，缓冲时间已被计划填满。新出现的监管需求又必须在季度末前上线。你会怎样重新安排资源和承诺？
- 一位负责人同时承担四个高优先级项目，状态汇报仍正常，但风险处理、跨团队决定和复盘都开始延迟。你会如何判断需要增加支持、重新分工还是缩减项目组合？
- 多个团队都把同一位领域专家列为关键路径资源，且各自的计划都假设其能全职支持。你会如何建立容量事实、比较依赖风险并协商可兑现的安排？
- 季度组合中每个项目都被标为最高优先级，但产品、数据和安全团队的容量不足以同时支持。你会如何统一优先级定义、暴露依赖和形成资源取舍？
- 项目计划把设计工作压缩到开发前一周，实际却需要用户研究、无障碍校验和多轮交互验证；设计师同时服务多个产品。你会如何重新估算设计容量和依赖顺序？
- 一个团队负责产品迭代，也承担客户支持轮值；旺季支持量会明显上升，但历史排期仍按固定比例预留。你会如何用工作量数据建立弹性容量和服务优先级？
- 移动版本依赖应用商店审核，审核时长不稳定；后端和 Web 已可先行发布，但营销活动有固定日期。你会如何建立发布窗口、功能开关和故障时如何保留核心功能的方案？
- 多个团队共用一条发布流水线和固定维护窗口，彼此的变更规模和回滚能力不同；一个团队延期会挤占其他团队的验证时间。你会如何规划发布容量和冲突处理？
- 核心服务由多个团队轮值，但各团队排期只计算项目工时；事故调查和演练常挤占计划工作，且不同服务的负荷差异很大。你会如何建立容量预测和跨团队公平机制？
- 项目估算只有两周实际开发，却常因设计评审、法务审批和数据接入排队拖到两个月。你会如何区分工作时间与等待时间，并协商减少队列的容量方案？
- 一个核心模块只有一位资深工程师掌握，团队希望他同时交付路线图功能并带两名同事接手；业务负责人担心短期产出下降。你会如何估算知识转移容量和长期风险收益？
- 年度项目预算已批准，关键岗位招聘持续失败，外包又受安全要求限制；其他团队已有可用人力但需要调整职责。你会如何比较延期、缩小范围、内部转岗和重新分配预算？
- 项目启动后发现关键领域专家离职，替补人员尚未到位；团队既可以等待，也可以改变顺序或缩小首期范围。你会如何评估容量和依赖并更新承诺？
- 团队连续三个季度被未计划支持工作打断，承诺完成率下降。领导要求把所有人排满以提高利用率。你会如何提出更可靠的计划？
- 外部供应商承诺的处理量低于旺季预测，替代供应商迁移需要两个月。你会如何制定容量与业务限制方案？
- 共享平台团队每周被新业务需求插队，原有可靠性和迁移承诺持续延期。你会如何设计接单、容量和优先级机制？
- 招聘冻结后，团队下季度可用工时减少三成，但业务目标和发布日期没有调整。你会怎样提出可选承诺而不是简单要求加班？
- 团队每季度计划全部用于新功能，线上问题和客户升级不断打断交付。你会怎样用历史数据决定支持容量并复核预留是否合适？
- 一个迁移任务需要平台团队连续两周协作，但对方只能每周抽半天。你会怎样比较等待、并行、接口冻结和缩小范围的成本？
- 新增人员后团队吞吐量不变，评审等待和跨团队协调时间上升。你会怎样区分学习成本、任务分配和系统瓶颈？
- 战略项目连续两个季度吸收资深工程师，另有维护工作和安全升级延期。你会怎样呈现机会成本并提出可选容量方案？
- 项目假设每周有三天共同工作时间，但实际存在本地假期和支持轮班。你会怎样建立真实的日历与响应约定？
- 一名核心运营负责人离职后，团队想将其任务平均分给现有人手，但有些工作需要特定权限和经验。你会怎样分流、暂停和升级？
- 过去四次计划都低估评审和返工时间，负责人要求个人估算更准确。你会怎样调整估算流程、记录不确定性并避免指标变成问责工具？
- 两个事业部都向客户承诺同一时间交付，合并资源后只能满足一个承诺。你会怎样提供范围、时间、质量和客户风险的选择？
- 团队有五个渠道，成熟度各不相同，短期回报率不能直接比较。你会怎样分配保底投入、探索预算和复核时间？
当前目标在这里暂无匹配题。 ·
项目与 PMO35
节奏、风险、变更与跨项目协调。
- 项目申请通常由高层发起人直接推动，缺少高层背书的合规和基础设施工作则反复延期。你会怎样建立透明的项目入口和排序过程？
- 组织要求所有项目采用同一套周报、评审会和审批门槛，小型探索项目因此花在汇报上的时间超过执行。你会怎样设计分层治理，同时确保高风险项目不会漏报？
- 一个依赖平台接口的项目已进入集成期，上游团队通知字段语义将在本季度改版，但无法长期同时支持两种格式。你会怎样判断兼容策略、迁移顺序和各项目的发布边界？
- 项目交付后四个月，成本下降目标没有体现在财务报表中；发起人认为系统仍在学习期，财务则认为项目已结束。你会怎样厘清收益责任和验证窗口？
- 一个新服务按计划上线，但负责项目的团队即将转去其他目标；值班、知识库、成本监控和后续改进都还没有明确接手人。你会如何判断项目是否具备交接条件？
- 公司调整年度方向后，多个在途项目不再支持新目标，但已有团队投入和外部承诺。你会怎样决定哪些立即停止、哪些完成收尾，并组织知识、合同与资源交接？
- 中途加入监管要求后，原计划无法全部实现，但不同团队仍引用旧里程碑。你会如何更新计划、依赖和对外承诺？
- 项目长期被标为绿色，直到上线前才暴露关键数据迁移没有演练。你会如何改造状态信号和决策节奏？
- 三个项目分别建设相似的权限和通知能力，单项目看都合理。你会如何发现组合层重复投入并调整治理？
- 五个项目都报告同一平台依赖可能延期，但各自仍显示绿色。你会用什么证据判断应该调整项目组合，而不是继续逐项跟进？
- 上线前两周，业务方要求再加一个需求，你怎样决定接受、推迟还是拒绝，并留下什么记录？
- 这个项目里最大的挑战是什么？它为什么难，你当时是怎么推进的，最后怎样了？
- 业务负责人认为变更审批拖慢市场机会，要求团队在评审外直接插入需求。过去紧急项后来多次引发返工。你会如何设计例外流程？
- 发布日期已对外承诺，但多个团队仍提出新需求和缺陷修复。你会如何决定何时冻结范围、允许哪些例外，以及谁承担重新排期的后果？
- 研发告诉你，你提的这个功能因为底层架构原因要延期两周才能上，而业务方明天就要。你怎样在很短时间里砍掉一半功能，留下一个能上线的最小可行版本？你依据什么决定留什么、砍什么？
- 你怎样度量研发效能？选哪些指标，怎样避免被刷出好看的数字，度量之后又怎样把它变成真正的改进？
- 你推动一个需要研发、设计、运营一起完成的项目，怎样让大家明确共同目标和分工？各方的成功标准不一样时怎么办？
- 关键供应商连续两次推迟接口交付，但项目计划仍沿用最初日期，内部团队开始并行开发临时适配层。你会怎样更新计划、处理新增工作量，并判断哪些承诺仍可信？
- 两个项目的排期撞在了一起，都需要同一批人。你怎么处理？怎样把冲突变成可以讨论的选项，并让双方接受结果？
- 项目进入第三周，你发现有两个风险没有人认领，你会怎样让它们变得可以管理？
- 五个项目按各自价值排序都合理，但共享三个串行依赖团队，整体交付周期远超季度窗口。你会如何识别组合瓶颈、重新排序和决定是否拆分交付？
- 项目尚未完成时，最初提出收益目标的业务负责人离职；新负责人关注不同指标，团队仍继续按原计划投入。你会如何重新确认收益假设、责任归属和继续投资的条件？
- 项目计划列出多个依赖团队，但没有具体交付负责人或确认日期；每个项目单独看都可行，组合层面却可能争抢同一产能。你会如何建立依赖承诺和风险视图？
- 多个项目都按计划消耗预算和工时，但关键业务结果没有可观察变化；状态汇报主要统计已完成任务数。你会如何重新设定项目组合的进度衡量方式，并支持资源调整？
- 项目设置了需求、设计、测试和上线评审，但材料齐全不代表关键假设已验证；团队常在评审会上才暴露风险。你会如何把阶段门改成真实的决策检查？
- 关键项目因供应商故障受阻，业务、工程、法务和财务都需要信息；现有升级流程要经过多轮状态会议，错过了解决窗口。你会按什么顺序向谁提供哪些信息，尽快明确决策人和行动？
- 项目进行到一半，多个重要利益相关者持续提出新增需求，但上线日期和团队容量没有变化。你会如何建立变更决策机制，并让范围、风险和承诺保持透明？
- 项目计划要求在季度末完成全面发布，但核心数据授权和合规评审仍未确认。你会如何设置阶段门，使团队可以推进准备工作，同时避免在关键条件未满足时作出难以撤回的投入？
- 项目由多个部门共同推动，没有一个负责人能单方面分配所有资源；问题常停留在会议纪要里，没人确认最终决定。你会如何明确决定权、升级路径和后续跟进？
- 项目已交付主要功能，但低频场景、运营文档和一个下游系统的整合仍未完成。团队希望结项释放资源，业务方担心遗留事项没人负责。你会如何判断结项条件并安排后续责任？
- 项目即将完成，但业务发起人离职，接收团队也没有明确负责人。你会怎样处理验收、交接和未决风险？
- 三个项目都需要一套不能并行使用的集成环境，发布日期接近且依赖同一测试团队。你会如何制定使用规则和应急方案？
- 项目已冻结范围并进入验收，合规团队发现一项必须满足的新要求，按原计划发布会产生审计风险。你会怎样处理？
- 工程团队按周报显示风险，业务仪表盘按月更新且仍是绿色，管理层据此做了资源承诺。你会怎样统一报告语义？
- 团队按计划完成了功能，但审批晚于招生季，实际使用要等半年。你会怎样复盘承诺、关键路径和阶段交付？
当前目标在这里暂无匹配题。 ·
运营执行43
策略落地、实验执行与持续运营动作。
- 一个新手引导实验没有改变注册到激活的总体转化率，却让已激活用户更快完成首次关键任务。你会如何决定是否推广，并如何修订对成功的定义？
- 大促期间活动页访问量达到预期，但商品加购和下单明显偏低。你会如何快速区分流量质量、页面信息、价格规则、库存或履约问题？
- 限时促销上线后，热门商品的库存不足，部分渠道已经收到展示承诺，其他渠道仍在持续引流。你会如何调整投放、页面承诺、补货和客户沟通？
- 一项品牌活动的总曝光已完成计划，但核心目标人群实际看到广告的比例低于预期，预算也只剩三分之一。你会如何决定继续投放、调整媒介组合或修改目标？
- 一项社区活动报名和互动数据很好，但活动结束后参与者几乎没有继续使用产品或贡献内容。你会如何判断活动与产品价值的连接在哪里断开，并设计下一轮运营？
- 一个合作渠道为了达成季度目标，要求临时扩大促销投放范围；初步检查发现新增人群可能超出原先约定的授权和品牌边界。你会如何在时限内推进判断？
- 一项活动创意在社交渠道的互动很高，却在搜索和门店渠道几乎没有转化；另一个版本互动一般但成交较好。你会如何决定创意迭代和渠道分配？
- 一次全量优惠让总体成交达到目标，但高价值老客认为优惠不公平，部分用户还因此延迟原计划购买。你会如何调整后续客群和优惠策略？
- 一次降价促销短期提高了销量，竞品随后跟进，品类整体价格和毛利都下降。你会如何判断应继续匹配、改变价值表达还是退出促销？
- 新品上市首周销售低于计划，但试用者使用较深、推荐意愿较强。你会如何判断目标用户还没看到产品、购买周期较长、价格门槛过高，还是定位不合适？你会据此决定下一阶段投入吗？
- 一项新客优惠带来大量注册，但多数人没有完成首次关键行为，优惠成本已经发生。你会怎样决定是否继续联系这些用户、提供什么帮助，以及哪些用户值得继续投入？
- 一个渠道在小规模测试时获客成本很低，扩大预算后线索质量和成交率持续下降。你会如何判断渠道饱和、受众变化或销售承接能力不足，并决定追加预算的边界？
- 一次活动带来大量新用户，但客服、内容审核和后续联系用户、引导其完成关键行为的安排都没有准备好。你会如何设计活动前后的责任与容量？
- 运营人员会直接修改客户状态，后续无法解释谁在何时因何修改。你会如何在效率、权限和审计之间设计流程？
- 说一次你以工程师身份参与的用户促活或裂变活动。你负责哪些系统、数据或交付工作，如何与运营确认预算及关键用户行为，并核验活动的增量和自己的实际贡献？
- 促销活动的策略已经确定，由你负责执行。上线前你会确认哪些目标、规则、资源、风险和验收条件？
- 销售、客服和工程都能把客户问题标为最高优先级，值班队列因此无法区分业务中断和一般不满。你会怎样设计分级与升级机制？
- 在管理一个大型平台生态时，常伴随刷单、黑产薅羊毛、低俗内容打擦边球这类灰色地带。你怎样建立一套不伤害正常生态繁荣的治理机制？你怎样与风控、法务和技术团队一起筑起防线？
- 你要在线上跑一个增长实验，开跑前会准备哪些检查点和停止条件？
- 你怎样从单纯做活动、拉新用户，升级为建立自动化、策略化的用户生命周期管理？请讲一个用数据记录和算法，把过去人工运营整理成自动化规则的案例。
- 双边平台在某地出现供需失衡：高峰期订单多但运力不足，或新城市有供给却缺少用户。你会如何定位主要瓶颈，并调整价格、补贴或供给安排，同时控制成本和长期影响？
- 公司战略调整要求你立刻砍掉一项获客多、但长期亏损的业务。你怎样在最短时间里安抚成千上万受影响的合作伙伴，合规平稳地完成业务清退，并防止出现群体性的公关危机？
- 一份关键运营手册仍被多个地区依赖，但原作者已离职，最近的系统和政策变化也没有同步进去。你会怎样判断哪些步骤仍安全、如何安排临时控制和更新责任，并验证新版本能被一线正确执行？
- 一个自动审批服务停摆后，运营团队临时改用表格处理，用户影响暂时得到控制。两周后服务仍未恢复，表格流程的权限和记录方式也不一致。你会如何管理临时人工流程、恢复自动审批，并确定何时关闭临时流程？
- 新的人工审核策略已部署到多个地区，但各班组对边界案例的处理不同，结果指标又有延迟。你会如何建立培训、现场反馈、抽样复核和策略调整流程？
- 大型活动和节假日重叠，客服、审核和供应团队预计容量不足；营销活动已经对外公布。你会如何安排值班、控制新请求进入、告知用户并升级异常？
- 运营仪表盘每天产生大量低价值告警，值班人员开始忽略通知；一次关键履约失败也未被及时发现。你会如何分级信号、建立处置责任并验证告警质量？
- 一次获客活动在部分渠道超额投放，另一些渠道素材未按计划上线；运营团队希望立即统一调整，但增长团队仍需保留对照。你会如何协调止损、记录偏差和继续评估？
- 外部服务商的响应时长和一次解决率连续恶化，但合同只规定月度平均服务承诺；内部团队每天都在补救。你会如何设计分层监控、例会、整改和合同调整机制？
- 运营团队通过手工补发权益解决用户投诉，解决时间很快，但每周补偿量持续增加且原因分类不一致。你会如何保障当前用户，同时把补偿数据转成产品修复信号？
- 某业务流程的成功率连续两周下降，但数据没有明显异常报警，客服反馈也较零散。你会如何组织运营诊断、临时处置和后续验证？
- 运营团队采用多班次覆盖，重要问题常在换班时遗漏，记录格式也不统一。你会如何设计交接信息、责任确认和异常升级机制？
- 最近一个月客户升级数量明显上升，前线同事认为是少数复杂客户，管理层认为是处理流程失效。你会如何区分个案与系统性问题，并安排验证？
- 公司更新了退款处理规则，但客服、财务和地区运营使用的说明不一致，已有少量客户得到不同处理结果。你会如何推动各团队按新规则处理，并验证实际执行？
- 一个人工运营试点在两个地区有效，扩展到十个地区后处理时长和错误率都上升。你会如何判断规模化瓶颈，并调整运营方式？
- 团队花两周集中清理积压问题，指标短暂恢复后又逐月恶化。你会如何把专项行动中有效的做法融入日常流程，同时控制持续成本？
- 多个渠道的数据结果相互矛盾时，怎样找出它们采用的统计规则、时间范围和数据来源有何不同？
- 同一处置命令在两个区域的影响不同，手册只描述了默认拓扑。值班人员可能按错环境执行。你会如何修订和防止再发？
- 灾备演练提前一周通知所有团队，大家准备专门脚本，演练顺利但真实恢复仍然失败。你会如何调整演练设计？
- 月度云账单低于总预算，但每笔交易成本连续增长，业务量暂时下降掩盖了效率退化。你会如何建立成本治理？
- 监控系统会自动重启异常服务，但本次问题来自共享数据层，批量重启可能加剧连接风暴。你会如何设计自动化边界？
- 一项促销活动提高下单率，却导致退货咨询和人工审核同时增加。活动预算尚有余量。你会怎样判断扩大活动、限制新增流量还是先改进流程？
- 新审批流程缩短了平均处理时间，但员工开始通过私聊获得例外，审计记录也变少。你会怎样判断流程改进是否真实？
当前目标在这里暂无匹配题。 ·
可靠性与事故24
观测、事故处置、止损与复盘动作。
- 一次数据写入事故已停止，服务指标也回到常态，但仍有用户报告缺失记录。你会怎样组织恢复验证与后续沟通？
- 一个发布项目的容量、供应商交付和数据质量风险分别都低于各自升级阈值，但三者可能在同一周叠加。你会怎样判断组合风险，并决定采取什么行动？
- 支付风控依赖变慢后，结账整体超时。业务要求尽量保留转化，同时不能绕过关键安全检查。你会如何决定哪些结账功能可以暂时关闭、哪些检查必须保留？
- 一次大促在夜间上线后因请求过多而卡住，大量用户无法领取优惠券并开始投诉。作为参与活动的工程师，在恢复系统的同时，你会怎样与运营和客服协同，评估并落实临时业务措施？
- 一个系统总是反复出问题，补一次又出一次。你怎样找到根本原因，怎样让团队从救火转向真正的修复，又怎样证明它不再复发？
- 线上服务突然大面积失败，你在第一个小时里会按什么顺序行动？
- 一次重大事故产生 18 条改进行动，涉及架构、监控、培训和流程；各团队已有季度承诺。你会如何筛选真正降低复发风险的行动？
- 怎样避免同类的个人失误再次发生？你改进的是流程和工具，还是只是提醒自己以后小心？怎么知道改进有效？
- 生产事故中，技术负责人要求关闭功能，业务负责人要求继续接单，客服团队又承诺了恢复时间。现场成员收到相互冲突的指令。你会如何组织响应？
- 移动端新版本先向 5% 用户发布，崩溃率看起来翻倍，但活跃设备数少且主要来自一种旧机型；营销活动即将开始。你会如何止损、补证据并决定继续、暂停或回退？
- 一次线上事故已恢复，复盘会列出监控补充、容量验证和手册更新等十余项行动；类似问题过去也开过行动项但无人验收。你会如何给改进事项定负责人和期限，并验证它们是否有效？
- 新版本发布后移动端网络失败率上升，服务端指标正常；受影响用户集中在旧系统版本和弱网环境。你会如何划定事故范围、减缓影响并决定暂停发布或回退？
- 核心服务部分不可用，原因尚未确认，客户、管理层和合作方都要求更新时间；团队担心过早说明会造成误解。你会如何区分已知事实、假设、行动和下次更新时间？
- 一个高危依赖漏洞需要尽快修复，但补丁与当前发布候选存在兼容风险；推迟会延长暴露窗口，立即发布又可能引发服务中断。你会如何安排验证、临时缓解和发布授权？
- 队列因消费者故障积压数小时，修复后大量旧消息即将重新处理；下游包含计费、通知和分析系统，处理能力与重复操作风险各不相同。你会如何安排恢复速度并保护下游？
- 核心依赖服务故障后已经恢复大部分功能，但错误率仍高于故障前水平；上游积压持续增长，业务方要求尽快恢复全部流量。你会如何确定恢复条件和流量节奏？
- 一次故障因为监控没有覆盖关键用户路径，团队直到客服升级后才发现。复盘决定增加监控，但团队还需要证明新机制能更早发现问题且不会制造大量噪声。你会如何设计验证？
- 发布后，登录、支付和通知服务接连出现异常，多个团队各自认为自己的故障最紧急，且部分告警可能来自同一个根因。你会如何协调响应、确定优先级并避免互相干扰？
- 一次故障没有达到客户承诺的重大事故门槛，但影响了少量客户并暴露流程缺口。你会如何决定是否公开复盘及公开到什么程度？
- 上游事件延迟数小时，下游报表仍显示正常完成，客户据此做了错误决策。你会如何设计数据新鲜度状态和通知？
- 业务依赖一个没有书面服务承诺的第三方接口，供应商支持响应不稳定。你会如何定义内部连续性目标和备用方案？
- 第三方服务已经恢复，但故障期间的回调可能丢失。客户看到的状态与平台记录不一致。你会如何确认影响并沟通？
- 服务中断已解除，少量客户仍有错账，客服承诺的补偿也未兑现。你会怎样定义事故关闭条件和持续跟进责任？
- 一次版本导致查询失败，回滚旧版本可能无法读取新格式数据。你会怎样止损并比较回滚、前向修复和兼容层？
当前目标在这里暂无匹配题。 ·