门店健康度最容易被做成一个好看的分数。
大屏上每家门店一个红黄绿状态，旁边再放一个 0-100 分。看起来很直观，但如果点进去不知道为什么扣分、不能看到影响业务、不能触发告警、不能分派责任人，这个分数就只是装饰。
真正有用的门店健康度，应该是总部 IT 管理门店稳定性的一套对象模型。它要能回答四个问题：
- 这家门店现在是否影响营业？
- 问题更像网络、设备、应用、业务链路，还是响应流程异常？
- 这个问题是单店、区域、系统性，还是供应商相关？
- 谁已经在处理，处理结果有没有沉淀为规则？
下面这张指标参考表，可以作为连锁零售、餐饮、便利店、药房、商超、服务门店建设门店健康度的起点。
第一层：网络健康
门店网络是很多故障的起点。POS、支付、会员、库存、外卖、医保、电子价签、摄像头、边缘设备都依赖网络。
| 指标 | 说明 | 建议观察方式 |
|---|---|---|
| 门店出口连通性 | 门店是否能访问总部、云服务、支付通道、DNS。 | 黑盒探测、心跳、探针。 |
| 延迟和丢包 | 网络质量是否变差，是否影响交易体验。 | 按门店、区域、运营商聚合。 |
| DNS 解析成功率 | 很多“系统慢”其实是解析异常或解析路径问题。 | 解析耗时、失败率、异常域名。 |
| VPN/专线状态 | 门店到总部或云资源链路是否稳定。 | 隧道状态、抖动、断连次数。 |
| 多线路切换状态 | 主备线路是否真的可用。 | 切换次数、切换耗时、备线质量。 |
网络层指标不能只看“断没断”。门店更常见的是抖动、慢、间歇性失败。总部需要看趋势，也要看区域聚合。例如某城市多家门店延迟同时升高，和单店宽带异常是两类完全不同的问题。
第二层：设备健康
设备层看的是门店本地可运行性。
| 指标 | 说明 | 建议观察方式 |
|---|---|---|
| POS/收银设备在线状态 | 设备是否在线、应用是否运行。 | 心跳、进程、客户端上报。 |
| 边缘服务器/网关健康 | 本地缓存、同步、代理、边缘计算是否正常。 | CPU、内存、磁盘、服务状态。 |
| 打印机/扫码枪/钱箱/读卡器状态 | 外设异常会直接影响门店操作。 | 设备状态、错误码、使用频次。 |
| 本地数据库/缓存状态 | 离线营业、同步补偿依赖本地组件。 | 连接数、复制延迟、错误日志。 |
| 设备版本和配置一致性 | 门店设备版本不一致会制造隐性问题。 | 版本分布、配置漂移、补丁状态。 |
POS 监控资料里常强调一个区别：设备管理和交易监控不是一回事。知道 POS 终端在线，不等于知道支付是否成功、授权是否变慢、结算是否正常。设备健康是基础，但不能等同于门店健康。
第三层：应用健康
应用层关注门店系统是否真正可用。
| 指标 | 说明 | 建议观察方式 |
|---|---|---|
| 接口成功率 | POS、会员、支付、库存、订单、报表接口是否正常。 | 按接口、门店、区域、系统聚合。 |
| 响应时间 | 慢比挂更常见，也更容易被忽视。 | P95/P99、慢请求、超时率。 |
| 错误码分布 | 区分业务失败、系统失败、第三方失败。 | 错误码、失败原因、通道维度。 |
| 日志异常 | 发现异常堆栈、重试、限流、连接池耗尽。 | 关键字、模式、异常趋势。 |
| 链路追踪 | 从门店请求到总部服务、数据库、第三方接口的路径。 | Trace、Span、依赖拓扑。 |
Google SRE 提出的“四个黄金信号”包括延迟、流量、错误和饱和度。放到门店系统里，这个思路很有价值：不要只看机器资源，要看请求有没有变慢、错误有没有增加、业务流量是否异常、系统是否接近容量边界。
第四层：业务健康
业务健康是门店健康度最关键的一层。它把技术指标翻译成门店经营语言。
| 指标 | 说明 | 建议观察方式 |
|---|---|---|
| 交易量 | 门店交易是否异常下降。 | 与历史同期、同区域、同类型门店对比。 |
| 支付成功率 | 支付失败是否集中在某通道、某区域、某类门店。 | 成功率、失败码、通道延迟。 |
| 会员查询/核销成功率 | 会员登录、积分、权益是否影响收银体验。 | 成功率、响应时间、失败门店数。 |
| 库存同步延迟 | 库存、调拨、补货、前置仓数据是否积压。 | 同步耗时、失败队列、重试次数。 |
| 订单/外卖履约异常 | 线上订单和门店履约是否断链。 | 接单率、取消率、超时率。 |
| 异常门店数 | 用门店数表达影响面，而不是只看告警数。 | 按区域、系统、链路聚合。 |
全渠道零售越深入，业务健康越重要。中国连锁经营协会的《便利店数字化转型指南》把便利店数字化定义为从总部到店面、从商品到供应链、从单一卖场到线上线下一体化运营的系统性变革。既然经营已经系统化，稳定性也必须系统化。
第五层：响应健康
很多企业忽视这一层。健康度不只是“系统有没有异常”，还包括“异常有没有被正确处理”。
| 指标 | 说明 | 建议观察方式 |
|---|---|---|
| 告警认领时间 MTTA | 从告警触发到有人负责用了多久。 | 按团队、系统、级别统计。 |
| 故障恢复时间 MTTR | 从故障发生到业务恢复用了多久。 | 按故障类型、区域、系统统计。 |
| 升级次数 | 是否存在无人处理、处理超时、跨团队卡住。 | 升级路径、升级原因。 |
| 重复故障率 | 同类问题是否反复出现。 | 规则、门店、供应商、系统维度。 |
| 低质量告警占比 | 告警是否可行动，是否有明确处理人。 | 噪声、误报、重复、漏报。 |
| 复盘改进完成率 | 复盘有没有真正变成规则、流程、配置。 | 改进项负责人、截止时间、验收状态。 |
AWS Well-Architected 的运营卓越支柱强调，运营能力包括组织团队、设计工作负载、规模化运行和持续演进。这个观点落到门店稳定性上，就是不要把监控看成“采集指标”，而要看成一套发现、响应、学习、改进的运营机制。
不建议把所有指标揉成一个分
门店健康度可以有总分，但总分必须可解释。
一个更合理的方式是五层健康度分别评分，再根据业务影响加权：
门店健康度 =
网络健康 × 权重
+ 设备健康 × 权重
+ 应用健康 × 权重
+ 业务健康 × 权重
+ 响应健康 × 权重
但要注意两点。
第一，不同行业权重不同。便利店、药房、餐饮、商超、汽车服务门店，关键链路不一样。药房可能更关注医保、处方、库存和会员；餐饮更关注点餐、支付、外卖、排队叫号；商超更关注收银、电子秤、支付、库存和价签。
第二，总分不能掩盖严重问题。一家门店网络、设备都正常，但支付成功率突然下降，总分不能因为其他项正常而仍然显示绿色。关键业务链路异常应该能直接拉高优先级。
推荐落地顺序
不要一开始就追求完整指标体系。建议按下面的顺序做。
第一步，先定义门店对象。门店要有区域、业态、系统、负责人、供应商、网络线路等基础标签。
第二步，先覆盖 3-5 条关键链路。通常是收银、支付、会员、库存同步、门店网络。
第三步，接入已有监控和告警源。Zabbix、Prometheus、云监控、日志平台、业务系统告警都可以先复用。
第四步，按门店和区域建立健康视图。让总部先看见异常门店和异常链路。
第五步，把健康异常接入告警响应。没有认领、升级、关闭和复盘，健康度只是看板。
第六步，用两周或一个月数据优化规则。看哪些指标真的有用，哪些指标只是噪声。
最后：健康度的价值是形成治理共识
门店健康度指标的价值，是把“IT 稳定性”翻译成多部门都能理解的语言。
管理层关心门店是否影响营业；信息化负责人关心总部是否可治理；运维团队关心监控和告警是否有效；业务系统负责人关心支付、会员、库存、订单链路是否稳定；区域支持关心哪些门店反复出问题。
一张好的健康度表，应该让这些人坐到同一张桌子上讨论同一个问题：哪些门店正在影响营业，问题集中在哪些链路，谁负责处理，哪些重复问题需要治理。否则，健康度就只是另一个看起来很漂亮、但无法改变响应效率的大屏指标。
