门店故障发现与响应复盘模板：一次故障，应该追问什么？

很多门店故障处理完以后，复盘会变成一句话：某某系统异常，已恢复，后续优化。

这类复盘基本没用。它没有说清楚故障什么时候开始、谁最早发现、为什么告警没有提前暴露、影响了多少门店、谁负责推进、为什么恢复用了这么久、下一次如何更早发现。

对连锁零售企业来说，故障复盘不只是研发或运维团队内部的技术动作。门店故障往往会影响收银、支付、会员、库存、履约、外卖、医保、电子价签、报表和区域运营。一次看似很小的异常，如果发生在高峰期，可能就是门店排队、顾客流失、店员手工处理、区域电话不断。

所以，复盘模板应该围绕一个目标设计：下次同类故障能不能更早发现、更快定位、更明确地响应，并且少影响一点门店。

下面这套模板可以作为门店故障复盘的检查清单。

一、故障摘要

先用五句话把事情讲清楚。

项目	填写内容
故障名称	例如：华东区域部分门店支付失败率升高
发生时间	开始时间、发现时间、恢复时间、完全关闭时间
影响范围	影响门店数、区域、系统、业务链路
业务影响	收银、支付、会员、库存、履约是否受影响
当前状态	已恢复、观察中、临时绕过、仍待根治

注意，故障摘要不要写成“某服务异常”。连锁门店的复盘要用业务语言写：哪些门店、哪些业务、持续多久、谁受影响。

二、时间线

时间线是复盘的骨架。没有时间线，后面讨论 MTTA、MTTR、告警质量、响应效率都没有依据。

时间点	事件	备注
T0	最早异常信号出现	来自监控、日志、交易指标、门店反馈还是客户投诉
T1	第一个告警触发	告警是否准确、是否打到正确的人
T2	第一位处理人认领	是否有人明确负责推进
T3	影响面确认	是否知道影响多少门店、哪些区域、哪些系统
T4	临时缓解措施执行	切换、重启、回滚、降级、供应商介入等
T5	服务恢复	业务指标恢复，不只是技术指标恢复
T6	故障关闭	复盘完成、改进项明确负责人和截止时间

Atlassian 的故障复盘资料里，把 leadup、fault、detection、root causes、mitigation and resolution、lessons learnt 作为重要问题。放到门店场景，可以翻译成：故障前发生了什么、哪里坏了、怎么发现的、根因是什么、怎么恢复的、下次怎么避免。

三、发现：谁先知道故障？

这是门店故障复盘里最值得追问的问题。

问题	为什么重要
最早信号来自哪里？	监控先发现，还是门店/顾客先反馈，代表主动发现能力差异。
监控是否在门店反馈前已经出现异常？	如果有信号但没人看见，问题在告警和响应；如果没有信号，问题在监控覆盖。
是否有更早的业务指标异常？	交易量下降、支付失败率升高、会员查询变慢，往往比系统宕机更早。
是否只有技术告警，没有业务影响判断？	CPU、端口、日志错误不等于门店业务受影响。
告警是否被噪声淹没？	说明需要去重、聚合、抑制、分级和路由。

Google SRE 的监控原则强调，真正打断人的告警应该是需要人工立即处理的问题。对门店企业来说，最值得优先发现的不是所有底层异常，而是顾客和门店会感知到的业务症状：支付失败、收银变慢、会员不可用、库存同步失败、多门店同时异常。

复盘时可以直接问一句：如果门店没有打电话，这次故障总部多久会知道？

四、影响：到底影响了什么？

很多复盘只写“部分门店受影响”，这不够。

需要拆成四层：

层次	要记录什么
门店影响	影响门店数、门店类型、区域、是否集中在某个网络或供应商。
业务影响	收银、支付、会员、库存、订单、外卖、医保、报表等。
顾客影响	排队、支付失败、无法核销、无法积分、订单取消。
运营影响	门店手工处理、区域介入、客服投诉、对账补录、供应商工单。

为什么要这么细？因为技术团队容易低估影响。一个接口错误率 2% 看起来不高，但如果集中在高峰期、集中在支付环节、集中在几十家核心门店，它就不是小问题。

影响面也是决定故障优先级的基础。ITIL 的事件优先级一般会结合影响和紧急度：影响代表范围和损害，紧急度代表需要多快恢复。门店场景同样适用。单店打印机异常和多区域支付失败，不应该走同一个升级流程。

五、响应：告警有没有进入责任流程？

复盘不能只看技术恢复，也要看组织响应。

问题	判断点
告警通知到了谁？	总部应用、网络、区域支持、门店人员、供应商是否有人收到。
谁是第一责任人？	有没有一个人明确负责推进，而不是群里多人旁观。
是否有升级规则？	多久无人认领升级，多久未恢复升级，影响扩大如何升级。
是否有协同记录？	供应商、门店、区域、总部之间的沟通是否可追踪。
是否有关闭标准？	是技术指标恢复，还是业务指标恢复，还是门店确认恢复。

对连锁企业来说，故障经常跨团队。POS 系统、支付通道、门店网络、总部服务、云资源、第三方接口、区域支持可能都相关。如果没有统一响应流程，群聊会很热闹，但推进责任并不清晰。

好的响应记录至少要留下四类数据：谁认领、何时认领、做了什么、何时恢复。没有这些数据，就无法谈响应效率。

六、根因：不要只写直接原因

根因分析容易写浅。

例如：

直接原因：支付接口超时。

这句话没有告诉我们为什么会超时、为什么没有提前发现、为什么影响扩大、为什么恢复慢。更好的写法是分层记录：

层次	示例问题
直接技术原因	哪个服务、接口、网络、设备、配置、供应商异常？
触发条件	是否有发布、配置变更、活动流量、网络割接、第三方异常？
扩散原因	为什么从单点变成多门店、多系统、多告警？
检测缺口	为什么监控没有提前发现，或告警没有到人？
响应缺口	为什么认领慢、定位慢、升级慢、协同慢？
管理缺口	是否缺少标准、演练、容量评估、供应商 SLA、门店巡检？

5 Whys 可以用，但不要机械。门店故障通常不是一个“根因”能解释完，而是一组技术原因、流程原因和组织原因叠加。

七、改进项：每一条都要能执行

复盘最后一定要落到改进项，而且每条改进项都要有负责人和截止时间。

类型	示例
监控补齐	为支付失败率、会员查询耗时、库存同步延迟增加业务指标。
告警优化	对门店网络抖动告警做聚合，避免一店多告警刷屏。
响应流程	多门店支付失败自动升级到总部值班负责人和支付系统负责人。
门店治理	将反复出现网络质量问题的门店纳入低质量门店清单。
供应商协同	明确第三方支付/网络供应商故障升级联系人和响应时限。
演练	对高峰期支付异常、区域网络异常做桌面演练。

改进项最怕写成“加强监控”“优化告警”“提升响应效率”。这类话没有执行对象，也无法验收。好的改进项应该能被检查：某个指标上线了吗？某条规则调整了吗？某个升级策略配置了吗？某个低质量门店清单建立了吗？

八、一页版复盘模板

下面是一页版模板，可以复制到飞书、企微文档或 Confluence。

故障名称：
发生时间：
恢复时间：
影响门店：
影响业务：
业务影响描述：

一、时间线
- T0 最早异常信号：
- T1 第一个告警：
- T2 第一位处理人认领：
- T3 影响面确认：
- T4 临时缓解：
- T5 业务恢复：
- T6 故障关闭：

二、发现
- 谁最早发现：
- 监控是否先于门店反馈：
- 是否存在漏报：
- 哪些告警是噪声：

三、响应
- 第一责任人：
- 参与团队：
- 是否按规则升级：
- 是否有供应商/区域/门店协同：

四、根因
- 直接原因：
- 触发条件：
- 检测缺口：
- 响应缺口：
- 管理缺口：

五、改进项
- 动作：
- 负责人：
- 截止时间：
- 验收标准：