发生生产事故时须按“先止血、再定位、后复盘”节奏沟通：初报需结构化陈述事实；60 秒内启动响应并指定 ic；强制 15 分钟同步进展且附依据；恢复 30 分钟后发布终报并 24 小时内轻量复盘。
发生生产事故时，快速、准确、有序的沟通是止损和复盘的关键。核心原则是：先止血、再定位、后复盘，所有沟通围绕这个节奏展开。
事故发现与初步通报
任何人员发现异常（如监控告警、用户反馈、服务不可用），需立即在指定应急群（如“XX 平台 - 事故响应”）发送结构化初报，包含：
• 服务名称与影响范围（例如：“订单中心 API 超时率升至 95%，影响全量 C 端下单”）
• 发现时间（精确到分钟，用北京时间）
• 当前现象（如“503 响应激增”“MySQL 主从延迟超 30 分钟”）
• 已确认的关联服务（如有）
不猜测原因，不发“好像”“可能”，只陈述可观测事实。
响应升级与角色就位
初报发出后 60 秒内，值班 SRE 或 Tech Lead 需确认并启动响应流程：
• 指定 1 名事故指挥官（IC），全程统筹信息同步与决策
• 通知相关方：开发负责人、DBA、中间件运维、安全接口人（按影响面判断）
• 启动共享文档（如腾讯文档 / 语雀），标题格式为“[事故]YYYYMMDD-HHMM_服务名_简要现象”，实时记录时间线、操作、结论
若 10 分钟内无响应，自动触发二级升级（通知技术总监）。
进展同步与信息闭环
事故处理中，强制执行“15 分钟同步机制”：
• 每 15 分钟在应急群更新一次进展，格式统一为：“【T+ X 分】当前状态：XXX；下一步动作：XXX；阻塞点（如有）：XXX”
• 所有结论性判断（如“确认是 Redis 连接池耗尽”“回滚 v2.4.1 已生效”）必须附带依据（日志片段、监控截图、命令输出）
• 用户侧影响变化（如“影响范围从 100% 降至 30%”）需单独说明，避免技术术语
收尾与轻量复盘
服务恢复正常并稳定运行 30 分钟后，进入收尾阶段：
• IC 发布终报：含故障起止时间、根因简述（一句话）、影响统计（错误请求数、持续时长、业务指标损失）、临时措施与后续改进项
• 共享文档锁定，标注“终版”，归档至事故知识库
• 24 小时内由 IC 组织 15 分钟站会复盘：聚焦“哪里可以早 10 分钟发现 / 拦截”，不追责，只记可落地的动作（如“增加连接池使用率告警阈值”“上线前加压验证脚本”）
沟通不是传递消息，而是对齐认知。每一次通报，都在降低团队的不确定性。
