发生生产事故时须按“先止血、再定位、后复盘”节奏沟通：初报需结构化陈述事实；60秒内启动响应并指定IC；强制15分钟同步进展且附依据；恢复30分钟后发布终报并24小时内轻量复盘。
发生生产事故时，快速、准确、有序的沟通是止损和复盘的关键。核心原则是：先止血、再定位、后复盘，所有沟通围绕这个节奏展开。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
事故发现与初步通报
任何人员发现异常（如监控告警、用户反馈、服务不可用），需立即在指定应急群（如“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分钟发现/拦截”，不追责，只记可落地的动作（如“增加连接池使用率告警阈值”“上线前加压验证脚本”）
