软技能系列第 6 章。线上稳定性讲的是「怎么少出故障」，这一章讲故障出了之后怎么说话——因为事故对团队的伤害，一半来自技术损失，另一半来自沟通失当造成的信任损失。
故障沟通的三条底线（先记住）
- 早说比说全重要：故障发生后第一时间同步「发生了什么、影响多大、正在做什么」，别等查清根因再说——查清根因可能要两小时，业务等不了两小时。
- 说影响，不说细节：对外（业务方、管理层）讲「影响面 + 恢复预期」，技术细节只对技术同事讲。
- 事实与猜测分开：同步里明确标注「已确认」和「疑似」，别把猜测说成结论——猜错一次，后续所有同步都要打折扣。
对内对外，两套节奏
对内（技术团队）：
- 用故障复盘模板的时间线格式同步进展，避免信息在群里散落。
- 值班人状态要清楚：谁在定位、谁在止血、谁在和外部沟通——事故中最怕的是「一群人一起查同一个问题」。
对外（业务/管理层/用户）：
- 模板化首报：「XX 服务出现故障，影响 XX 范围，预计 XX 恢复，正在处理」。三句话讲完，别让人从碎片里拼。
- 恢复后主动补一条「根因 + 影响 + 改进计划」的总结，别让业务从别人那里听说「出了大事」。
- 对用户，宁可报「我们遇到问题」也不报「我们很好」——用户发现你撒谎的代价，远大于你承认故障。
踩坑记录：一次事故里，技术群里已经聊了一小时，业务才从监控里发现异常来问。从那以后我们立了规矩：事故超过 5 分钟没恢复，必须主动同步业务，不管根因查没查到。
复盘怎么开：不甩锅，也不和稀泥
复盘会最容易变成两种：甩锅会（技术怪产品、产品怪测试）和和稀泥会（「大家都不容易，下次注意」）。都不对。复盘的目标只有一个：找到系统性的漏洞，让同类问题不再发生。
- 只问「为什么」，不问「谁」：追问链条是「为什么当时没发现→为什么告警没响→为什么预案没执行」，追到流程和机制，不追到个人。
- 人的失误是系统设计的一部分：值班同学漏看了告警，复盘该问的是「告警为什么会漏看」，而不是「他为什么不细心」——把人放在会犯错的位置上设计系统，是复盘的高级形态。
- 改进项要有 owner 和期限：复盘输出 3–5 条改进，每条绑定负责人，下个迭代检查——复盘的结尾不是「散会」，是「谁在什么时候交付什么」。
复盘不甩锅的沟通技巧
- 会前先给「时间线」，让所有人基于事实说话，而不是基于记忆和情绪。
- 让最接近事故的人先讲，别让 leader 先定调——先定调了，下面全是附和。
- 用「如果重来一次，什么能阻止它」代替「当时为什么没做对」——前者指向未来，后者指向审判。
落地清单
- 5 分钟内首报（影响 + 进展），不等人问
- 事实与猜测分开标注
- 复盘只问「为什么」，不追「谁」
- 改进项绑定 owner 与期限
- 对外「早说、说影响、不撒谎」