学完这一课，你可以
- 找出分歧究竟来自事实、资源、目标还是决定权。
- 写出说明影响、保护措施、未知和下次更新的事故消息。
- 把修复承诺变成有人负责、可实际验证的行动。
开始之前
- 带上第 9 课的任务统计和支持安排，以及第 7、8 课的停止条件与授权。
- 阅读本课北辰版本错配情景。它不同于此前的旧会话越权事件；相似的沟通方法不能把两个事故混成一个。
先说明今天需要决定什么
第 9 课已经表明，扩大使用需要支持和工作流程配合。现在业务负责人要保住已经汇报的时间点，运行负责人说没人接得住，销售关心续约。你不需要证明谁最懂技术，而要明确今天决定的是保持白班范围、增加支持后再扩大、改用演示，还是暂停。
开场可以这样说：“今天需要确认两周后的展示采用什么范围，以及期间是否继续真实试用。先核对影响和支持，再比较选项。”这给不同角色一个共同问题，也避免会议变成对过去项目经历的长篇解释。
决定权也要先确认。业务负责人可以批准业务范围和资源；数据负责人负责资料用途与访问；运行负责人确认值班、暂停和恢复条件。一个人的赞同不能代替其他人的权限。如果决定人不在场，写清谁需要什么时候确认，期间采用什么已获授权的保守安排。
把立场还原成具体后果
“必须下周全量”和“绝不允许”是立场，不一定是最终需求。分别问：“如果不这样做，你最担心什么？”再用对方能纠正的话复述：“你要守住展示时间，但并非要求无人支持的夜班立即使用，对吗？”不要假定这个解释一定正确；对方纠正你，本身就是有用的新信息。
把事实分歧、原因解释、资源或利益冲突、风险接受和决定权分开。不同报表需要对齐任务与时间窗；不同原因需要补记录；人手不够需要资源或范围选择。更多准确率数据不解决夜班无人接手，也不能替业务负责人决定可以接受什么代价。
如果此前作出过夸大承诺，先明确承认哪一句超出了证据，再讨论新的选择。解释工程过程可以稍后补充，不能代替回答对方受到什么影响。下面的对照表适合会前把问题写下来，也适合自学时检查自己是否只是在重复“我理解”。
| 听到的话 | 要确认的问题 | 更合适的下一步 |
|---|---|---|
| “你们的完成率不对” | 是否统计同一任务和时间窗 | 并列原始记录与计算方法 |
| “我这边没人接得住” | 哪些时段、任务或异常缺人 | 缩小范围或确认新增支持 |
| “董事会已经知道日期” | 需要真实运行还是展示进展 | 比较合成演示与受限试用 |
| “上次不是说解决了吗” | 旧结论依据覆盖了哪些型号 | 纠正旧说法并补缺失验证 |
| “风险你们承担就行” | 谁有权接受对客户的后果 | 交还授权负责人决定 |
事故发生时，保护和协调一起开始
本课情景中，上月说“版本错配问题已解决”，实际只检查了新型号。现在已确认 37 个任务使用错误版本，范围可能到 60，其中 2 个涉及高温处理。这是教学事件给出的当前事实，不是入门 JSON 的二十条事件，也不是新的真实事故。37 是确认值，60 是待核查的可能范围，两者不能互换。
先根据已获授权的停止规则限制受影响功能，保存必要记录，把仍在处理的任务转给能接手的人，同时通知业务、数据与运行负责人。暂停什么要对应风险：错误手册引用与越权访问是不同问题。不能为查根因让用户继续暴露，也不能未经确认把所有任务都称为安全。
Google SRE 的事故响应资料将协调与技术处置分开。本课借用这一思路：有人协调当前行动，有人查系统与任务记录，有人维护对用户的更新；小团队可以一人兼任，但职责不能漏。记录每次操作、时间和结果，避免两个人各自恢复或重复执行外部动作。
写一条用户知道该怎么做的更新
一条首次更新应说明已确认的影响、已采取的保护、仍不知道什么、用户目前应做什么和下次更新时间。只写“正在积极排查”无法帮助工程师选择下一步。时间承诺可以是“下次何时更新”，不必是尚无依据的“何时修好”。如果涉及正式对外通知，由有相应职责的人确认内容和渠道。
为了练习，假设运行负责人已经确认暂停受影响的版本建议，并将未完成任务转入人工队列。你可以写：“已确认 37 个任务使用了错误版本，其中 2 个涉及高温处理；可能影响到的其余任务仍在核查。受影响的建议功能已暂停，未完成任务转由值班人员处理。请不要继续使用旧建议。恢复条件仍待验证，今天 16:00 再更新。”这里的保护措施与时间是假设，真实更新必须换成已经确认执行的动作和时点。
把旧承诺另加一句说明：“上次只验证了新型号，却说整个版本问题已解决，结论过宽；我们正在补查其他型号。”删除“只是”“少量”“应该没事”等无法支持的修饰。没有证据证明发生某件事，不等于已经证明没有发生。
把选项与代价放到同一页
提供真正不同的选项，而不只是完整版、简化版和加班版。针对这次情景，可以暂停真实使用并保留合成演示；只保留已经重新验证且有人支持的范围；或者推迟展示并集中修复。重新验证尚未完成时，第二个选项只能列为有条件的方案，不能写成已经获准。
每个选项写清影响谁、需要多少支持、放弃什么、由谁确认，以及什么情况需要重新讨论。让会议形成“批准合成演示，真实建议继续暂停，运行负责人提交恢复验证后再评审”这类具体记录。日期和负责人应来自实际授权或标为练习拟定，不能由学习者替客户作出真实决定。
并非每次会议都能达成一致。不同意的原因、临时范围和升级对象也可以清楚记录。没有资源解决时，持续暂停是一个选择。不要用“大家原则同意”把尚未接受的风险藏起来。
修复信任，要改变出错的机制
这次失信来自验证范围过窄、承诺范围过宽，因此修复应补上型号覆盖、撤回资料检查、版本变化后的重测和说明范围的审批。增加周会或说“已经吸取教训”并不能证明这些缺口已经消失。把每一项改进写成负责人、完成条件和验证人。
Google SRE 的复盘资料重视从系统条件和改进行动学习。本课据此建议你整理时间线：何时发现、谁知道、当时有哪些信息、作了什么决定、哪条控制没有发挥作用。复盘不是寻找一个可以背锅的人，也不是承诺永远不出错。让受影响人员检查修复是否改变了他们实际遇到的问题。
沟通给高管、一线和运行团队时，详略可以不同，确认任务数、可能范围、未知和暂停状态必须一致。保存同一份事实记录，并注明更新时间。你承认旧结论有误，可以帮助对方判断新的承诺；是否重新信任你，仍需要对方通过后续行动来评价。
检查自己有没有用术语躲开问题
常见误区包括：先解释系统复杂，迟迟不说影响；把可能 60 写成确认 60；把拟采取措施写成已经完成；为了保住关系承诺明天修好。每一项都让用户无法判断当前工作是否应继续。检查更新中的每个数字、动作和时间是否有记录支持。
自学时可以把自己的开场读出来，圈出防御、讨好或空泛保证的句子，再改为事实、选择和待确认条件。与同伴练习时，请对方复述批准范围；两个人说法不一致，先修正理解。短而准确的消息需要取舍细节，但不需要隐去不利事实。
动手练习
按本课版本错配情景写一次事故更新和选择说明。可以独自完成；如果有同伴，再请对方分别从业务与运行角度追问。不要调用真实系统或联系真实客户。
- 01
先列已知：37 个确认任务、可能至 60、2 个涉及高温；再列未知：最终范围、后果、原因、恢复条件。保留“上次只测新型号”的不利事实。
- 02
提出保护动作，注明这是待授权的建议；若用已经执行的口吻写练习消息，先明确对应的演练假设。
- 03
写一条九十秒内能读完的更新，包含用户当前应做什么和下次更新时间，不承诺无依据的恢复日期。
- 04
比较暂停加合成演示、条件满足后受限试用、延期修复三个选择，列出权限、支持和验证要求。
- 05
写两项针对验证缺口的修复，给出谁检查、怎么检查；最后对照全部材料，确认各版本数字与状态一致。自学时把真实批准和执行结果留为“待验证”。
把确认、待核对和联系状态分开
核对 60 条可能受影响任务，写清已确认、仍未知、已经联系与保护状态，再起草一次坏消息更新。
37 条确认与 2 条高温情景沿用公开摘要；逐行分配与联系进度是独立扩展，已联系不等于影响解除。
先读字段说明，完成计算或走查，再核对指南中的自检要点。文件可下载后用表格软件或文本编辑器阅读，无需运行代码。
检查你的理解
先写下自己的回答，再展开解析，看看还需要补充什么。
“可能到 60 个”应该怎样写？
写成待核查的可能范围，同时保留已确认 37。不能用 60 替代确认数，也不能只报 37 而隐去已知的范围不确定性。
尚未暂停，更新中可以写“已暂停”吗？
不能。真实消息只描述确认执行的动作。练习可以先声明暂停已完成这一演练假设，再写示例，但不能冒充案例原有事实。
增加会议频率能否证明版本错配修复？
不能。需要覆盖遗漏型号、版本选择和撤回传播的实际检查。沟通安排可以支持修复，但不代替测试。
本课记录与下一步
一份分歧说明、一次事故更新，以及具体的修复行动计划。
未知没有写成事实；需要知道情况的人已经被通知；每项修复都有负责人和可检查的结果。
第 11 课会把实际完成、复核负担和事故处理成本一起算入价值。保留本课的不利事实与修复安排，它们会影响下一笔投资是否值得。