深色模式
故障定界话术
摘要：故障中沟通失误比技术失误更容易放大损失。本文给出故障各阶段的信息结构、可直接套用的对内/对外模板，以及三条硬性纪律：不报猜测、不乱承诺、统一出口。
适用环境
bash
# 沟通前先把客观事实取齐，避免口头描述失真
date && date -u
kubectl get pod -n <ns> | grep -v Running
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://<域名>/health1
2
3
4
2
3
4
排障步骤
第 1 步：先明确"定界"结论
定界回答四个问题，不回答"根因是什么"：
- 哪个服务/接口受影响
- 影响面多大（用户比例、功能范围、地域）
- 严重程度（完全不可用 / 部分失败 / 变慢）
- 当前状态（仍在持续 / 已止血 / 恢复中）
第 2 步：对内通报模板
text
【故障通报 - 第 N 次更新】时间：<HH:MM>
现象：<接口/服务> 返回 <错误表现>，起始时间 <HH:MM>
影响面：<xx% 请求失败 / 影响 xx 功能 / 影响 xx 区域>
当前动作：<已回滚 / 已限流 / 正在切换备用>
下一步：<动作> + 预计 <时间> 出结论
需要协助：<需要谁做什么>
指挥人：<姓名> 记录人：<姓名>1
2
3
4
5
6
7
2
3
4
5
6
7
第 3 步：对外通报模板
text
尊敬的客户：
<时间> 起，<服务名称> 出现 <现象>，目前 <已恢复 / 正在恢复中>。
影响范围：<具体功能>，<是否影响数据>。
我们正在 <措施>，预计 <时间> 完成。
给您带来不便，深表歉意。1
2
3
4
5
2
3
4
5
对外不要写根因猜测
未确认的根因一旦写错，后续更正会严重损害信任。对外只陈述现象、影响面、进展与预计时间。
第 4 步：升级时机
出现以下情况立即升级：
- 影响核心业务且 15 分钟内未定位
- 需要跨团队协同（网络、数据库、云厂商）
- 可能存在数据丢失或安全风险
- 已止血但根因未明，存在复发风险
第 5 步：恢复后的收尾通报
text
【故障恢复通报】
恢复时间：<HH:MM>，持续时长：<xx 分钟>
根因：<一句话>
处置：<做了什么>
后续改进：<改进项 + 责任人 + 计划完成时间>1
2
3
4
5
2
3
4
5
第 6 步：全程维护时间线
text
HH:MM 监控告警触发
HH:MM 值班确认并开始排查
HH:MM 定界为 XX 服务
HH:MM 执行止血（限流/回滚）
HH:MM 业务指标恢复
HH:MM 对外通报恢复1
2
3
4
5
6
2
3
4
5
6
不要承诺没有依据的恢复时间
"5 分钟就好"一旦做不到，会引发反复追问与信任崩塌。不确定时应说"正在处理，每 15 分钟同步一次进展"。
验证
- [ ] 每次通报都包含时间、现象、影响面、当前动作、下一步
- [ ] 对外渠道有唯一信息出口，无多人发布不同说法
- [ ] 时间线完整可回溯，能支撑后续复盘
常见坑
多头对外发声
不同人给出不同说法会让信息失去可信度。应指定唯一对外出口。
只说"在查了"没有进展感
即使没有结论，也要同步"已排除什么、正在查什么"，让相关方感知进度。
故障结束后不通报恢复
用户以为仍在故障中，会持续产生咨询压力。恢复后必须显式通报。
为了安抚而隐瞒数据影响
数据丢失或不一致必须如实告知，隐瞒会导致更严重的次生问题与合规风险。